The background behind this is around beginning of February 2006,
the thread "Two ideas" by Carl Worth. And the current behaviour
is defined by this commit. I'll talk about a possible
improvement but first, here is what it does:
commit 130fcca63fe8e7e087e7419907e018cbbaf434a3
Author: Junio C Hamano [off-list ref]
Date: Sun Feb 5 00:07:44 2006 -0800
...
- "git commit paths..." acquires a new semantics. This is an
incompatible change that needs user training, which I am
still a bit reluctant to swallow, but enough people seem to
have complained that it is confusing to them. It
1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds
trained git users that the traditional semantics now needs
-i flag.
2. refuses to run if named paths... are different in HEAD and
the index (ditto about reminding). Added paths are OK.
3. reads HEAD commit into a temporary index file.
4. updates named paths... from the working tree in this
temporary index.
5. does the same updates of the paths... from the working
tree to the real index.
6. makes a commit using the temporary index that has the
current HEAD as the parent, and updates the HEAD with this
new commit.
...
The check that prevents you from doing
$ edit A B
$ git update-index A B
$ git commit -o B
is the rule #2, which I think could use further improvement. It
is to address the "committing skewed files" issue Carl brought
up in that thread.
It might be better to further check if the working tree file is
the same as the index, and to allow a commit in such a case.
The intent of rule #2 is to prevent this from happening:
$ edit A B
$ git update-index A B
$ edit B again
$ git commit -o B
When this happens, the real index will have _old_ contents of B
that never was committed, and does not match what is in the
index. But after the commit, we will match the real index to
what was committed, so we will _lose_ the index entry for B
before the second edit you explicitly told git to remember by
saying 'update-index'.
On the other hand, in your original sequence:
$ edit A B
$ git update-index A B
$ git commit -o B
B being committed would be different between HEAD and index, but
that is what we are going to commit anyway, so after this
commit, B will be in sync with the updated HEAD.
To put it in another way, "commit -o" is a short-hand for people
who do not want to run update-index themselves (IOW, people who
just want to use git without worrying about the index file). If
you use update-index to mark "this is what I want to commit"
yourself, you should do so consistently. If you are not ready
to commit A but you want to commit B, do not mark both of them
and expect "commit -o" to do magic fixups.
On Tue, 14 Mar 2006, Junio C Hamano wrote:
<snip - interesting, thanks>
It might be better to further check if the working tree file is the
same as the index, and to allow a commit in such a case.
That would be a nice improvement.
The intent of rule #2 is to prevent this from happening:
$ edit A B
$ git update-index A B
$ edit B again
$ git commit -o B
When this happens, the real index will have _old_ contents of B
that never was committed, and does not match what is in the index.
But after the commit, we will match the real index to what was
committed, so we will _lose_ the index entry for B before the
second edit you explicitly told git to remember by saying
'update-index'.
That would indeed be annoying, and I'd obviously prefer to have to
run 'git reset' than have the above happen!
However, I'd have expected that any porcelain command would
synchronise index with HEAD after a commit. See below for my (still
newbie-ish ;) ) user-level mental model of git.
On the other hand, in your original sequence:
$ edit A B
$ git update-index A B
$ git commit -o B
B being committed would be different between HEAD and index, but
that is what we are going to commit anyway, so after this commit, B
will be in sync with the updated HEAD.
Right. So if the file in the index and working tree are the same
(hey, i just ran update-index after all), then that check could be
loosened. The only thing the commit can do is bring the /3rd/ piece
of the puzzle (HEAD) in sync :).
To put it in another way, "commit -o" is a short-hand for people
who do not want to run update-index themselves (IOW, people who
just want to use git without worrying about the index file). If
you use update-index to mark "this is what I want to commit"
yourself, you should do so consistently. If you are not ready to
commit A but you want to commit B, do not mark both of them and
expect "commit -o" to do magic fixups.
I guess my problem here is that I consider the index to be a 'weak'
cache.
I like to use it for intermediate way-points or "weak commits",
however if I commit to HEAD I /really/ want what (I consider to be)
the two /strong/ sources of file information (HEAD and working file)
to be synchronised, and the 'weak' cache updated then to match.
I wasn't expecting the 'weak' cache of the index to prevent me
synchronising my 'strong' sources (HEAD and working file). I was
expecting the 'weak' cache to be updated to the 'strong' ones.
If I want to synchronise this 'weak' cache, I'll do so explicitely
(though, there isn't a user-obvious distinction in commands for this,
there's no obvious "git-commit-index"). Maybe part of the problem
here is that git-commit tries to hide the index/working-tree/HEAD
distinction? I don't know.
Anyway, if git-commit can lift "Rule 2" where file in working tree
and index match, that'd be great - but I can easily live with
git-reset till then. ;)
Thanks for the informative email!
regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
Fortune:
A violent man will die a violent death.
-- Lao Tsu
Junio C Hamano wrote:
The background behind this is around beginning of February 2006,
the thread "Two ideas" by Carl Worth. And the current behaviour
is defined by this commit. I'll talk about a possible
improvement but first, here is what it does:
commit 130fcca63fe8e7e087e7419907e018cbbaf434a3
Author: Junio C Hamano [off-list ref]
Date: Sun Feb 5 00:07:44 2006 -0800
2. refuses to run if named paths... are different in HEAD and
the index (ditto about reminding). Added paths are OK.
The check that prevents you from doing
$ edit A B
$ git update-index A B
$ git commit -o B
is the rule #2, which I think could use further improvement. It
is to address the "committing skewed files" issue Carl brought
up in that thread.
It might be better to further check if the working tree file is
the same as the index, and to allow a commit in such a case.
The intent of rule #2 is to prevent this from happening:
$ edit A B
$ git update-index A B
$ edit B again
$ git commit -o B
When this happens, the real index will have _old_ contents of B
that never was committed, and does not match what is in the
index. But after the commit, we will match the real index to
what was committed, so we will _lose_ the index entry for B
before the second edit you explicitly told git to remember by
saying 'update-index'.
Can't this be done by updating .git/index first and then use the
temporary index to commit? Then .git/index would match the current tree
and everybody would be happy with very little tweaking. Doing the
temporary index commit first could cause data-loss as described above if
the updating of .git/index somehow fails and the user is unaware of it
(or what to do to fix it).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231