Junio C Hamano wrote:
Side note. I think the above "Until..." is an overstatement,
and maybe the readers of the tutorial can be taught a lot
earlier how the index can help them. Maybe the following
sequence can be added to an early part of the tutorial sequence?
$ edit hello.c
$ make test
$ git diff
$ git update-index hello.c; # ok, that is good so far.
$ edit hello.c; # hack more
$ make test; # oops, does not work
$ git diff; # ah, that overeager edit broken what was good
$ git checkout hello.c; # get the last good one back
That actually points out one of the things I think isn't so hot about
using update-index for checkpointing your work. Here's a longer
development session:
$ edit hello.c
$ make test
$ git update-index hello.c; # so far so good
$ edit hello.c
$ make test
$ git update-index hello.c; # looks good too
$ edit hello.c
$ make test
$ git update-index hello.c; # sure, seems okay
$ edit hello.c
$ make test; # oops! design flaw in the second edit uncovered!
$ ???; # how do I back out the last three edits but not the first?
If you know for certain that you will only ever want to back out the
most recent edit during your development, or back out all the way to
HEAD, then update-index is fine, but if (like me) you want to checkpoint
your work frequently so you can step back in a very fine-grained
fashion, then it's less than ideal to have only one checkpoint that
keeps getting overwritten.
For frequent checkpointing, as far as I can tell I pretty much need to
commit (to a development branch, of course) every time. I do that
because I never know beforehand whether I'll need to go back by more
than one step later on; 99% of the time I don't have to, of course, but
the remaining 1% is pretty painful if I can't.
Am I missing some magic index command that would support multi-level
backing out? Obviously StGIT is an option as well, but that seems like
overkill when all I want is to checkpoint my work. The above is why,
even though (I think) I know enough about the index to use it as you
describe, I often don't bother and just run "commit -a" during
development instead. When I merge, I usually fold all my checkpoint
commits together and merge the change as a logical unit.
But I'm still a relative n00b and would appreciate knowing if I'm just
missing some big obvious technique.
-Steve
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html