Re: Git commit won't add an untracked file given on the command line

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 19, 2008, 23:07 UTC
Message-ID: <7v7i6zs4ay.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <alpine.LNX.1.00.0811191247560.19665@iabervon.org>

Daniel Barkalow <barkalow@iabervon.org> writes:

> I don't think that's what Mark wants, in this case. He's looking for the 
> ability to have "git commit" act on a temporary index created by adding to 
> the parent commit explicitly named files which aren't in the non-temporary 
> index.

Ah, I think that it would not be an entirely unreasonable thing to do (cf. Message-Id: <7vtza4trdp.fsf@gitster.siamese.dyndns.org>).

You can say "git add that/directory" and .gitignore mechanism protects you from crufts in that/directory, so fearing "git commit that/directory" to add random junk to the next commit is not a reason to fear it.

But that is a huge behaviour change. For example, I have a handful test scripts in my t/ directory (all named following the usual t????-*.sh naming convention) that I do not want to commit. Today, after making changes to the tracked test scripts, I can rely on "git commit t/" not to include them in the commit, and I've _learned_ to trust that behaviour. I'd be surprised if others who have used git for more than a few months haven't done so as well.

Allowing what Mark wants without any explicit user customization will be a disaster to the end user experience.