git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Michael J Gruber <git@drmicha.warpmail.net>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	git@vger.kernel.org, "Junio C Hamano" <gitster@pobox.com>
Subject: Re: [PATCH] Add git format-patch produced patches to .gitignore
Date: Mon, 17 May 2010 09:52:33 +0200	[thread overview]
Message-ID: <4BF0F5C1.1060309@drmicha.warpmail.net> (raw)
In-Reply-To: <20100517022244.GA19141@progeny.tock>

Jonathan Nieder venit, vidit, dixit 17.05.2010 04:22:
> 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.

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 ;)

> 
> 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

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
> 
> [1] http://thread.gmane.org/gmane.comp.version-control.git/96220/focus=96294

      reply	other threads:[~2010-05-17  7:52 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-15 21:22 [PATCH] Add git format-patch produced patches to .gitignore Ævar Arnfjörð Bjarmason
2010-05-16  6:27 ` Pavan Kumar Sunkara
2010-05-16  7:52   ` Jonathan Nieder
2010-05-16 13:06     ` Ævar Arnfjörð Bjarmason
2010-05-16 14:05 ` Michael J Gruber
2010-05-17  1:35   ` Jonathan Nieder
2010-05-17  2:04     ` [PATCH] Remove editor-specific droppings from .gitignore Ævar Arnfjörð Bjarmason
2010-05-17  2:22   ` [PATCH] Add git format-patch produced patches to .gitignore Jonathan Nieder
2010-05-17  7:52     ` Michael J Gruber [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4BF0F5C1.1060309@drmicha.warpmail.net \
    --to=git@drmicha.warpmail.net \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jrnieder@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).