Re: [RFC] Two conceptually distinct commit commands

[Junio C Hamano <junkio@cox.net>]

Theodore Tso <tytso@mit.edu> writes:

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