Re: [RFC] Two conceptually distinct commit commands

From: Junio C Hamano <junkio@cox.net>
Date: Dec 5, 2006, 06:33 UTC
Message-ID: <7virgqj1hh.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20061205035123.GA8831@thunk.org>

Theodore Tso <tytso@mit.edu> writes:

Show 16 quoted lines

> A second issue which you left unspecified is what should
> commit-working-tree-content do if the index != HEAD.  In particular,
> in this case:
>
> edit foo.c
> git update-index
> edit foo.c
> git commit-working-tree-content foo.c
>
> What should happen to foo.c in the index?  Should it be stay the same?
> Should the contents be replaced with version of foo.c that has just
> been commited?  The latter seems to make sense, but runs the risk of
> losing the data (what was in the index).  The former has the downside
> that the index might have a version of foo.c which is older than what
> has been just commited, which could be confusing.  Or should git
> commit-working-tree abort with an error message if index != HEAD?

That is exactly the "'commit --only' jumps the index" issue.

Updating the index with what is committed makes sense because the commit after this --only commit happens builds on top of it, and not doing so would mean the change to foo.c would be reverted. As you mentioned above, updating the index with the committed version of foo.c means information loss of what was staged earliser, and the traditional behaviour has been to "abort with an error if index != HEAD" at that path, which was a safety valve.

However, In the recent discussion, everybody (Linus, Nico, and I included) seems to think this information loss is acceptable and in fact is even useful. I've sent a patch to remove the obsolete safety valve for comments today, but haven't applied it to any of my public branches yet, but most likely I will, and it will happen sooner with encouragement from the list.