From: Junio C Hamano <gitster@pobox.com>
To: Andrew Ardill <andrew.ardill@gmail.com>
Cc: alex@bellandwhistle.net, Jonathan Nieder <jrnieder@gmail.com>,
"git\@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: gitignore vs. exclude vs assume-unchanged?
Date: Tue, 22 Apr 2014 10:54:28 -0700 [thread overview]
Message-ID: <xmqqtx9l5jxn.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <CAH5451k+GGGdHXkwne2O-h2m2AyWg7K+5reNRG64+eF891pVUA@mail.gmail.com> (Andrew Ardill's message of "Tue, 22 Apr 2014 10:40:43 +1000")
Andrew Ardill <andrew.ardill@gmail.com> writes:
> As a data point, I have seen people add ".gitignore" to their
> .gitignore file, as they don't want to share the file.
Interesting. It will break immediately when the project starts
wanting to distribute its "canonical" ignore list, but until that
time, it would "work" (for some definition of "working").
> It would be possible to check for this antipattern during normal use
> and provide a hint to the user, but that is probably too heavy handed
> and might annoy people with a legitimate use case. For that matter, if
> the gitignore file is easier to use for the 'private ignore' use case
> we have a bigger problem and shouldn't dictate to users what to use.
Very true.
> ... The introduction does specifically mention 'gitignore'
> files, but that seems to be due to all the ignore files
> ($HOME/.config/git/ignore, $GIT_DIR/info/exclude, .gitignore) being
> classified as 'gitignore' files.
Yes. Notice that that the blanket term used is not "dot-gitignore",
but "gitignore". The difference may be too subtle, and your
suggestion to introduce a new phrase "git ignore files" as the
blanket term might be one way to make it less subtle. I would
actually think "ignore files" (without Git, as all readers know we
are talking about _our_ ignore mechanism in our documentation) may
even be a better idea.
> We could reference the multiple ignore locations earlier, for people
> who don't read past the first paragraph of to documentation.
>
> "Git ignore files specify intentionally untracked files that Git
> should ignore. A git ignore file can be specified for all local
> repositories, a specific local repository, or shared with other users
> of a repository. Files already tracked by Git are not affected; see
> the NOTES below for details."
Sounds good, with or without s/git ignore/ignore/.
> Finally, it's a little confusing that one of the files is called 'exclude'.
>
> It would be great to rename it to 'ignore'; $GIT_DIR/info/exclude ->
> $GIT_DIR/info/ignore. Is there any reason this shouldn't be done?
If we were starting Git from scratch, we may have called it
info/ignore, but we do not live in an ideal world, so we need to
worry about people's existing repositories, scripts and templates.
That does not mean we cannot transition over time, aiming to flip
the default in a future big version bump (no, not in 2.0), along the
lines of (note: I haven't thought this thru, and do not take this as
an authoritative and correct plan):
Step 1.
- Check if info/ignore exists, and read it without reading or
even checking the existence of info/exclude;
- Check if info/exclude exists, and read it. Warn about future
default change and tell the user to rename (or if we are
absolutely sure that we are interactive, we can offer to do the
rename for the user by prompting).
Step 2.
- Wait for several major releases, until major distros catch up
with step 1.
Step 3.
- Drop the support for info/exclude altogether, without even
warning about our stopping to read it.
next prev parent reply other threads:[~2014-04-22 17:54 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-16 16:33 gitignore vs. exclude vs assume-unchanged? alex
2014-04-16 17:51 ` Junio C Hamano
2014-04-16 23:07 ` alex
2014-04-16 23:45 ` Jonathan Nieder
2014-04-18 0:36 ` alex
2014-04-22 0:40 ` Andrew Ardill
2014-04-22 17:54 ` Junio C Hamano [this message]
2014-04-25 23:09 ` alex
2014-04-26 7:52 ` luc.linux
2014-04-26 12:26 ` Zé
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=xmqqtx9l5jxn.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=alex@bellandwhistle.net \
--cc=andrew.ardill@gmail.com \
--cc=git@vger.kernel.org \
--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.
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.