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

[Miles Bader <miles@gnu.org>]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> 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.
>
> So my point is this: stage first, verify, then commit.  That saves you a 
> lot of embarrassment.

You seem to be saying that you think that using staging area explicitly
is necessary or somehow "more efficient" for making good commits, but on
the face of it, that's simply not true.

I'm extremely careful about committing clean changes, and do a lot of
testing and pre-commit diffing.  For complex changes which need to be
split, the staging area is indeed a very useful tool, and I'm very glad
git has it -- but it's hardly necessary for _all_ commits, and my
experience is that in practice, many commits are indeed the simple sort
which for which it's superfluous.  My goal is not to "work with the
staging area efficiently", it's to "make good/clean/tested commits,
efficiently".

Obviously this depends on work style, and subject matter.  Sometimes one
_needs_ to make biggish changes and split them for commiting, and some
people like to use that work style even when it's not strictly
necessary.  Other times, changes are more obviously independent, and can
be done, tested, and commited in a serial fashion without any splitting.

Perhaps, given your work style or the type of work you, you use the
staging area 99% of the time.  For your case, maybe any git features
which bypass the staging area are simply unneeded complexity.  However,
my own experience suggests that this is not universally true.  I'd say I
use the staging area for maybe 50% of commits.

One of the nice thing about git is the way that it tries to cater to
multiple work styles, so it seems wrong to reject a useful feature
simply because you want to "encourage" people to use your preferred work
style, when that work style is not obviously better.  [Of course there
can be other good reasons to reject this feature -- maybe it's too
dangerous or mucks up the code.]

> 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.

[I'm not sure what the point of that was... for the record, no I'm not
one of "those people".  When I use the staging area, I use "git diff
--cached"; when I don't use the staging area, I "git diff" instead...]

-Miles

-- 
Bacchus, n. A convenient deity invented by the ancients as an excuse for
getting drunk.