patchAdd git format-patch produced patches to .gitignore

Change Git's own .gitignore so that patches produced with git format-patch don't show up as untracked.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
---
 .gitignore |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

Generally I use the format-patch command as:

git format-patch -M origin/master -o outgoing/

So, my patches will be in subdirectory outgoing. But the regex rule in this patch won't be able to hide them.

What do u want to do in that case ?

- Pavan

On Sun, May 16, 2010 at 2:52 AM, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:

Pavan Kumar Sunkara wrote:

[...]

Try it out.

In fact, I was worried that this patch would trigger a similar problem: maybe some test data directory contains format-patch output? In fact none do, so I like the patch.

Thanks, Jonathan

On Sun, May 16, 2010 at 07:52, Jonathan Nieder <jrnieder@gmail.com> wrote:

Right, patches in outgoing/ will be ignored too because the rule isn't prefixed with /, so it works regardless of whether the file is in a subdirectory or not.

None do, there's no file that matches '????-*.patch' in Git. Even if there was you could still 'git add -f' it, which wouldn't be that big of a problem because it would be part of some rarely touched test suite in t/*.

Ævar Arnfjörð Bjarmason venit, vidit, dixit 15.05.2010 23:22:

Does the git build process call format-patch? No! The .gitignore we distribute is meant for things the build process creates, not for imposing a specific workflow on developers.

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.

Cheers, Michael

Michael J Gruber wrote:

Ah, true. I seem to remember a thread long ago about whether to include editor droppings in .gitignore, but I can’t find it in the git or lkml archive.

git’s .gitignore does not include .*.swp, \#*#, *~, indeed.

So nack from me as well. It is nice that the .gitignore file we track does not have to change with fashions, and this way each user can set up a personal excludesfile according to choice of tools without interference.

Maybe there should be a reasonable "default" .gitexcludes file in gitignore.5 as an example, but that is a different topic[1].

Thanks for the reminder, Jonathan

[1] http://thread.gmane.org/gmane.comp.version-control.git/96220/focus=96289

Git's own .gitignore files should only contain things created by Git's build systems, not editor-specific droppings.

See the discussion following the "[PATCH] Add git format-patch produced patches to .gitignore" thread (<1273958566-7328-1-git-send-email-avarab@gmail.com>). ---

On Mon, May 17, 2010 at 01:35, Jonathan Nieder <jrnieder@gmail.com> wrote:

Thanks both of you, I stand corrected. Anyway, I guess this is a bug then. It's the only thing ignored by Git's various .gitignore files that isn't created by the build system.

 git-gui/po/.gitignore |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

Michael J Gruber wrote:

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

Jonathan Nieder venit, vidit, dixit 17.05.2010 04:22:

I think I meant to object back then but concluded it made no difference. My mathematically deformed^Weducated mind tells me that "do we... contents" means we should put everything in .gitignore except what we expect to track. So, here the literal understanding certainly differs from the intended definition ;)

I haven't found the rambling part in your post yet but agree everything is clearer now :)

Michael

P.S.: I'm fine with Ævar's revised patch, of course. ACK