Junio C Hamano wrote:
quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html