[PATCH] D57400: Add a .gitignore file to the root that ignores any files outside of the project directories.

[Kristina Brooks via Phabricator via llvm-commits]

kristina added a comment.

In D57400#1400495 <https://reviews.llvm.org/D57400#1400495>, @jyknight wrote:

> I still don't like it...It's different, unusual, and IMO surprising to have such a wildcard ignore.
>
> We haven't tended to have lots of random accidental file additions before, and while someone may surely mess up again, I don't think it likely to be a common occurrence.
>
> I'd much prefer simply the targeted ignore of "/build*", at least for starters.


IMHO the rate of someone messing up, may be higher than the rate of new toplevel projects being added, which is really not very often. Considering this has already happened at least once, and considering that  some people likely still use SVN for commits and may less familiar with Git (with it, IMO, being a lot less explicit than SVN as far as commits go). This isn't stopping people from adding new toplevel projects, it's simply more or less an additional step that needs to be taken as a safety measure to ensure the addition was intentional and not a result of accidentally committing something from a worktree. I think this may also provide more safety to anyone who has private directories that are not tracked and yet may accidentally be added to a commit. So I think aside from avoiding to predict every possible build directory imaginable, this will also stop the previous mentioned issue from ever happening as well as files like `.gn` or anything alike (such as `BUILD` or `WORKSPACE`) also being accidentally committed (it makes sense to have that in the root of the monorepo checkout for anyone actively using GN or other build systems, but it may not be desirable to *accidentally* commit them to the root of the repository). Same applies to any CI configuration or any other scripts that may end up in the root directory.

I think the reason for lack of accidental addition was partially to do with the fact that (IMO) it's much harder to accidentally do it with SVN than with Git and also meant that Git users still needed a separate SVN worktree to actually commit from. Which for some added an additional safety barrier ensuring that only intended patches were applied to the SVN worktree and committed as opposed to Git where one can use a single worktree (well eventually, after the full migration is complete) and commit/push directly from it.

Git allows a lot of flexibility for local work, which is definitely a good thing, however, I'm not entirely sure if that degree of flexibility is going to be good when actually pushing changes to upstream repository. So I simply think keeping a whitelist like that may be a better approach than blacklisting certain directories, which is pretty much more of a hit/miss approach.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57400/new/

https://reviews.llvm.org/D57400