Re: [PATCH v2 07/18] build: introduce rust
- From
- Eric Sunshine <ericsunshine@gmail.com>
- Date
- Sep 18, 2025, 07:06 UTC
- Message-ID
- <CAPig+cTHtxwr6TRJOmLj9ktaaRdQFLXDewfQU0zxZ0m8ADmMnA@mail.gmail.com>
- In-Reply-To
- <xmqqh5x1f7tz.fsf@gitster.g>
On Wed, Sep 17, 2025 at 10:54 AM Junio C Hamano <gitster@pobox.com> wrote:
Show 51 quoted lines
> Eric Sunshine <sunshine@sunshineco.com> writes: > >> +.idea/ > > > > Is ".idea" directory detritus from your chosen editor? If so, it > > probably ought not be added to this list since we don't otherwise > > ignore detritus from foreign tools such as that. > > I knew that the above was our official stance but somehow thought > that we loosened at some point to add common ones like *~ and > *.sw[op] to make life simpler for majority of developers. But I was > wrong. We do not even have *~, which means we haven't officially > loosened. > > But there are oddballs that violate this policy like ".cache" > introduced by a5c01603 (gitignore: ignore clangd .cache directory, > 2023-08-04). Three are many other that are *not* our droppings, > between /.vscode/ to /contrib/buildsystems/out in .gitignore file. > > /.vscode/ > /tags > /TAGS > /cscope* > /compile_commands.json > /.cache/ > *.hcc > *.obj > *.lib > *.sln > *.sp > *.suo > *.ncb > *.vcproj > *.user > *.idb > *.pdb > *.ilk > *.iobj > *.ipdb > *.dll > .vs/ > Debug/ > Release/ > /UpgradeLog*.htm > /git.VC.VC.opendb > /git.VC.db > *.dSYM > > Some (like TAGS and *.hcc) are our droppings (in other words, what > "make" with some build targets may produce), but most of these are > tool specific and according to our original official stance, they > should never have been added, but there they are.
It's been a while since I had to build code with Visual Studio (the proprietary Microsoft product, not the open-source VScode), but if I recall correctly, all the entries from ".obj" through "Release/" are build detritus from compiling with that tool. Assuming we still support building Git with Visual Studio (which I believe is the case), then those entries all fall within the same categorization as "our droppings" similar to the `make` case, so having these in ".gitignore" is probably in line with the project's official stance.
Others, such as "/.vscode/", on the other hand, fall into the other category of "someone's favorite editor or handy tool", which has thus far been frowned upon.
Show 7 quoted lines
> I actually do not mind having common ones to the project .gitignore > as long as it does not get bloated too much with droppings from > esoteric tools that majority of us have never heard of. It seems > that we have been punishing needlessly Emacs and vim users while > being sloppy about others' droppings. A #leftoverbit may be to > have a brief discussion to gain consensus and add a few common ones > and/or remove too esoteric ones? I dunno.
I don't have a strong opinion aside from avoiding bloat; I've seen (and inherited at $DAYJOBS) far too many projects which grab some overly bloated .gitignore template from somewhere in which most of the entries are meaningless for the project at hand, yet which is used as-is rather than pruning out the unneeded entries (typically >95% of them). As with dead code, those unneeded .gitignore entries tend to be a source of potential confusion, which is rarely or never the case with a well-curated .gitignore (or with well-curated code).
That said, I also probably do not mind having the common ones in Git's .gitignore. A few which come to mind include:
* editor-specific droppings (Emacs, vi / vim, VScode) * .DS_Store files which macOS's Finder drops into *every* directory it visits, thus which litter the filesystem