From: Marko Poutiainen <regs@sofistes•net>
To: Jeff King <peff@peff•net>
Cc: git@vger•kernel.org
Subject: Re: Gitignore matching "git add" wildcard prevents operation
Date: Thu, 14 Jan 2010 23:07:44 +0200 [thread overview]
Message-ID: <4B4F87A0.2090301@sofistes.net> (raw)
In-Reply-To: <20100114195234.GA26684@coredump.intra.peff.net>
Jeff King wrote:
> On Thu, Jan 14, 2010 at 08:18:40PM +0200, Marko Poutiainen wrote:
>
>> It seems that that there is a bug related to how Git handles the add
>> command with wildcards if the wildcard also matches a file that is ignored.
>>
>> E.g (I activate the *.[ao] rule when editing .git/info/exclude):
>>
>> mep@Blackbird:~$ cd /tmp
>> mep@Blackbird:/tmp$ mkdir git
>> mep@Blackbird:/tmp$ cd git
>> mep@Blackbird:/tmp/git$ git init
>> Initialized empty Git repository in /tmp/git/.git/
>> mep@Blackbird:/tmp/git$ nano -w .git/info/exclude
>> mep@Blackbird:/tmp/git$ touch a.o a.c a.h
>> mep@Blackbird:/tmp/git$ git add a.*
>> The following paths are ignored by one of your .gitignore files:
>> a.o
>> Use -f if you really want to add them.
>> fatal: no files added
>
> It's not a bug. That is working as designed. If "git add" encounters a
> problem with any of the files you gave it on the command line (and
> remember, the shell expands the wildcard, so git literally sees the
> three files on the command line) then it aborts the entire operation.
>
> Now whether that is useful behavior in this case, I don't know. If you
> were truly manually specifying the files, then it would probably not be
> a big deal to simply remove the offending file. But there is no way to
> use the shell wildcard and get the behavior you want (not even a "git
> add --really-ignore-my-ignores a.*").
>
> I don't think it would be right to silently ignore them, because it may
> be the sign of an error. It could be downgraded to a warning, like:
>
> $ git add *.a
> warning: a.o is ignored, not adding
>
> The downside would be that somebody who really _did_ want to add such a
> file but forgot to use "-f" is going to be less likely to notice it, as
> the command does not barf. So maybe such behavior should be triggered
> with a command-line option. I dunno.
Well, it then the interface just isn't consistent, because if that's the
reason, then why does
$git add .
then work in this case? . is still just a type of wildcard, so it fail
in a similar way, shouldn't it?
Your idea of giving a warning is good as is the command-line option. In
any case, in my opinion this feature can make some operations more
complex than they should be. For instance, in my example I would have to
separately do git add to both files. What if there are more than two
files to add and I get this error every time I try to add the files?
next prev parent reply other threads:[~2010-01-14 21:08 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-14 18:18 Gitignore matching "git add" wildcard prevents operation Marko Poutiainen
2010-01-14 19:52 ` Jeff King
2010-01-14 20:21 ` Junio C Hamano
2010-01-14 20:39 ` Jeff King
2010-01-15 15:34 ` Nicolas Sebrecht
2010-01-15 15:48 ` Jeff King
2010-01-15 16:11 ` Nicolas Sebrecht
2010-01-15 16:30 ` Jeff King
2010-01-15 18:06 ` Nicolas Sebrecht
2010-01-15 18:17 ` Junio C Hamano
2010-01-14 21:07 ` Marko Poutiainen [this message]
2010-01-15 15:39 ` Nicolas Sebrecht
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=4B4F87A0.2090301@sofistes.net \
--to=regs@sofistes$(echo .)net \
--cc=git@vger$(echo .)kernel.org \
--cc=peff@peff$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox