On Wed, 1 Feb 2006, Linus Torvalds wrote:

quoted text
> 
> 
> On Wed, 1 Feb 2006, Junio C Hamano wrote:
> > 
> > How about this:
> > 
> >  - "git commit --also fileA..." means: update index at listed
> >    paths (add/remove if necessary) and then commit the tree
> >    described in index (the current behaviour with explicit paths).
> 
> I'd suggest "--incremental" instead of "--also".
> 
> >  - "git commit fileA..." means: create a temporary index from the
> >    current HEAD commit (or empty index if there is none), update
> >    it at listed paths (add/remove if necessary) and commit the
> >    resulting tree.  Also update the real index at the listed
> >    paths (add/remove if necessary).  In the original index file,
> >    the paths listed must be either empty or match exactly the
> >    HEAD commit -- otherwise we error out (Linus' suggestion).
> 
> Yes.

Agreed.

quoted text
> >  - "git commit" means: update index with all local changes and
> >    then commit the tree described in index (current "-a"
> >    behaviour).
> 
> No. Please no. "git commit" should continue to do what it does now. 
> Otherwise you can't do the two-stage thing in any sane way.
> 
> Requiring "--incremental"/"--also" is very confusing.
> 
> If somebody doesn't know about the index, he normally will never have 
> index changes _anyway_, except for the "git add" case. In which case "git 
> commit" does the right thing for him: it will either commit the added 
> files, or it will say "nothing to commit".

Sensible.  As long as "commit files..." actually commits _only_ those 
files unless --index (or something) is specified to also explicitly 
include the index changes.

What is really counter-intuitive is to have index changes merged by 
default when a single file is specified as argument to commit.


Nicolas
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html