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

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Nov 19, 2008, 09:41 UTC
Message-ID: <alpine.DEB.1.00.0811191036340.30769@pacific.mpi-cbg.de>
In-Reply-To: <buomyfwmldj.fsf@dhapc248.dev.necel.com>

Hi,

On Wed, 19 Nov 2008, Miles Bader wrote:

Show 14 quoted lines

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >> I agree, but it would kinda handy to have an exception for files 
> >> explicitly named on the command line.
> >
> > Only if you do not have a clear picture of what the staging area is 
> > about, IMHO.
> 
> That's such a vague statement, I've not sure how to take it.
> 
> I use the staging area a lot, so I think I have a pretty clear idea of 
> what it's "about", but I also often use "commit FILE" or "commit -a" for 
> simple cases; even when splitting a change into multiple commits, it's 
> often more convenient to do "commit FILE..." instead of "add FILE; 
> commit".

What I meant was this: the "commit <file>" paradigm is not what you should do most of the time. In order to work with the staging area efficiently, you should make staging and committing two separate steps.

I regularly encounter people who never call "git diff --cached" before committing, and guess who introduces all kinds of debug statements and other cruft into their commits? Exactly.

So my point is this: stage first, verify, then commit. That saves you a lot of embarrassment.

Ciao, Dscho