git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] Add git format-patch produced patches to .gitignore

From
Jonathan Nieder <jrnieder@gmail.com>
Date
May 17, 2010, 02:22 UTC
Message-ID
<20100517022244.GA19141@progeny.tock>
In-Reply-To
<4BEFFBB5.7010808@drmicha.warpmail.net>
Michael J Gruber wrote:
> If you want to ignore format patch output, simply use .git/info/excludes
> or a global excludes file, but please don't force everyone else to live
> with that or work around it.

Side note: I said with similar intent that this allows developers to work “without interference”. This was a poor choice of words on my part: a too-long .gitignore only prevents me from noticing and tracking files that others considered not worth tracking.

From the thread I faintly remembered and then linked to[1]: ;-)
  I earlier said that "*~" should not be in project-wide .gitignore
  file because use of Emacs vs vi is a matter of personal taste, and
  Emacs specific "*~" pattern does not belong to a project policy,
  just like vim "*.swp" pattern doesn't.
  But I think that reasoning is flawed.  The right criteria should not
  be about "use of Emacs vs vi", but about "do we in this project ever
  want to track files that match *~ or *.swp as legitimate contents".
  If a project expects not to have a tracked file whose name ends with
  ".swp", even if it does _not_ mean to encourage use of vim over
  Emacs or any other editor, I think it is fine to add such to its
  tracked .gitignore file for its developer's benefit.

This does not change my conclusion: there are many other reasons to leave files produced outside the build process unlisted:

 . consistency: to keep the file intuitive and avoid a lot of
   patch churn, it is nicest to choose one rule and stick to it
 . simplicity: shorter .gitignore.  Making the appropriate content
   of .gitignore depend on the behavior of too many text editors
   (and IDEs, and foreign VCSes, and debugging tools, and ...)
   makes it hard to maintain.  See qt’s .gitignore for an example
   of this.
 . correctness: for the case of format-patch, it is hard to say
   "we will never want to track files that match ????-*.patch as
   legitimate contents".  In fact, it is likely such files may need
   to be added to the test suite.

And unlike .o files and company, it does not seem likely that formatted patches need to be kept around during development.

I hope that is a little clearer. Sorry for the ramble. Jonathan

[1] http://thread.gmane.org/gmane.comp.version-control.git/96220/focus=96294
Previous: Ævar Arnfjörð BjarmasonNext: Michael J Gruber
Message 8 of 9 in “Add git format-patch produced patches to .gitignore”
  1. Add git format-patch produced patches to .gitignoreÆvar Arnfjörð Bjarmason, May 15, 2010
  2. Pavan Kumar SunkaraMay 16, 2010
  3. Jonathan NiederMay 16, 2010
  4. Ævar Arnfjörð BjarmasonMay 16, 2010
  5. Michael J GruberMay 16, 2010
  6. Jonathan NiederMay 17, 2010
  7. Remove editor-specific droppings from .gitignoreÆvar Arnfjörð Bjarmason, May 17, 2010
  8. Jonathan NiederMay 17, 2010
  9. Michael J GruberMay 17, 2010

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.