All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Baudis <pasky@suse.cz>
To: Junio C Hamano <gitster@pobox.com>
Cc: Kirill Smelkov <kirr@landau.phys.spbu.ru>,
	Daniel Barkalow <barkalow@iabervon.org>,
	Bert Wesarg <bert.wesarg@googlemail.com>,
	Git Mailing List <git@vger.kernel.org>
Subject: Re: Default exclude rules for Git
Date: Fri, 19 Sep 2008 18:33:12 +0200	[thread overview]
Message-ID: <20080919163311.GH10544@machine.or.cz> (raw)
In-Reply-To: <7v8wtouoit.fsf@gitster.siamese.dyndns.org>

On Fri, Sep 19, 2008 at 08:46:34AM -0700, Junio C Hamano wrote:
> I do not see a need to change any canned template shipped with git.  I
> actually think it is a grave regression to add anything arbitrary, even if
> one person happens to think the choice is conservative, to the set of
> tool-wide ignore patterns.  And here is why.
> 
> I haven't personally seen any project that wants its users to _edit_ a
> file whose names end with ".a" or ".o" and track it.  That does not
> however mean that there can be no project and/or environment that validly
> wants to track files with ".o" suffix (isn't it the case that windows shop
> use ".obj" for object files and ".o" suffix do not have any particular
> meaning to them?)  By placing "*.o" to tool-wide ignore file, your version
> of git is making life for participants in such a project harder because
> they can now easily forget to add a newly created "*.o" files (status
> won't show them).  The tool should be extremely conservative not to
> encourage such mistakes.
> 
> The best place to express such a project wide policy (e.g. "in this
> project, '*.o' files will never, or rarely if ever, be tracked and we
> expect our developers to appreciate not seeing them in status output by
> default") is a tracked .gitignore file.

Yes, but the idea here is to give both the projects and the users
sensible default to work on, in case of users even one that might change
system to system based on tools behavior. It is that VAST MAJORITY of
projects won't care about object or (most kinds of) hidden files, so to
me it makes sense to make people opt out instead of opt in.

If a particular policy is unsuitable for some (rare) project, it can
still undo the ignore rules by adding !*.o to its .gitignore file. The
only issue is that this gets noticed first time a particular new ignore
pattern appears, and I admit I don't have a good solution here.

-- 
				Petr "Pasky" Baudis
The next generation of interesting software will be done
on the Macintosh, not the IBM PC.  -- Bill Gates

  reply	other threads:[~2008-09-19 16:34 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-18 16:29 A couple of TopGit tweaks Kirill Smelkov
2008-09-18 16:29 ` [TopGit PATCH] .gitignore += vim swap files Kirill Smelkov
2008-09-18 17:24   ` martin f krafft
2008-09-18 17:30     ` Kirill Smelkov
2008-09-18 17:38   ` Bert Wesarg
2008-09-18 17:43     ` Kirill Smelkov
2008-09-18 17:56       ` Bert Wesarg
2008-09-18 17:50         ` Kirill Smelkov
2008-09-18 17:54     ` martin f krafft
2008-09-18 19:30     ` Daniel Barkalow
2008-09-19  5:06       ` Kirill Smelkov
2008-09-19  7:10         ` Bert Wesarg
2008-09-19  7:28           ` Kirill Smelkov
2008-09-19  7:51             ` Andreas Ericsson
2008-09-19  7:52               ` Kirill Smelkov
2008-09-19 10:50             ` Bert Wesarg
2008-09-19 14:22         ` Default exclude rules for Git Petr Baudis
2008-09-19 15:46           ` Junio C Hamano
2008-09-19 16:33             ` Petr Baudis [this message]
2008-09-19 16:42               ` Avery Pennarun
2008-09-18 16:29 ` [TopGit PATCH] tg help: <something>: improve readability Kirill Smelkov
2008-09-18 16:29 ` [TopGit PATCH] tg import: fix + make more robust Kirill Smelkov

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

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

  git send-email \
    --in-reply-to=20080919163311.GH10544@machine.or.cz \
    --to=pasky@suse.cz \
    --cc=barkalow@iabervon.org \
    --cc=bert.wesarg@googlemail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=kirr@landau.phys.spbu.ru \
    /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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.