From: Junio C Hamano <junkio@cox.net>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 5/5] git-add: add ignored files when asked explicitly.
Date: Mon, 25 Dec 2006 09:27:15 -0800 [thread overview]
Message-ID: <7vslf3khsc.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <Pine.LNX.4.63.0612251443230.19693@wbgn013.biozentrum.uni-wuerzburg.de> (Johannes Schindelin's message of "Mon, 25 Dec 2006 14:47:13 +0100 (CET)")
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Mon, 25 Dec 2006, Junio C Hamano wrote:
>
>> $ git add foo.o
>> $ git add '*.o'
>
> Most people do
>
> $ git add *.o
>
> instead, where bash expands the expression. Maybe this new behaviour
> should be hidden between a "-f" option?
When would anybody do "git add *.o"?
A more plausible situation is that you have '*.o' in .gitignore
because you do not want to keep track of object files generated
from your source, but your project needs to keep track of one
third-party object file that you do not have the source to, and
helping that situation is what this patch is about.
An alternative is to use the mechanism I added here to _detect_
the attempt to add an ignored file with explicitly spelled out
pathspec, and issue an info message that says something like:
Path 'xyzzy/filfre.o' is not being ignored by one of
your .gitignore files. If you really want to add it,
please add this entry to .gitignore file:
!/xyzzy/filfre.o
One advantage of this is that it would help guiding the user in
the right direction, giving a reusable piece of knowledge,
without changing the behaviour of the command (what is refused
is refused). But I can already see people's complaints: if the
tool knows how to fix that situation why forces the user to do
so?
Although the reason why the alternative does not do so is "The
user earlier said *.o files are uninteresting but came back with
a conflicting request to add xyzzy/filfre.o, which could be a
mistake. We ask for a confirmation", which is very sensible,
another alternative would be to add the path anyway and issue an
warning, like this:
$ ls xyzzy
filfre.c filfre.o
$ git add xyzzy/filfre.?
added ignored path xyzzy/filfre.o
next prev parent reply other threads:[~2006-12-25 17:27 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-25 11:13 [PATCH 5/5] git-add: add ignored files when asked explicitly Junio C Hamano
2006-12-25 13:47 ` Johannes Schindelin
2006-12-25 17:27 ` Junio C Hamano [this message]
2006-12-25 18:39 ` [PATCH] git-add: warn when adding an ignored file with an explicit request Junio C Hamano
2006-12-25 22:24 ` Jakub Narebski
2006-12-26 16:19 ` Johannes Schindelin
2006-12-25 19:57 ` [PATCH 5/5] git-add: add ignored files when asked explicitly Nicolas Pitre
2006-12-26 15:34 ` Johannes Schindelin
2006-12-26 19:05 ` Junio C Hamano
2006-12-26 22:48 ` Johannes Schindelin
2007-01-04 13:58 ` Andreas Ericsson
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=7vslf3khsc.fsf@assigned-by-dhcp.cox.net \
--to=junkio@cox.net \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
/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.