Re: [FAQ?] Rationale for git's way to manage the index

[Daniel Barkalow <barkalow@iabervon.org>]

On Wed, 9 May 2007, Linus Torvalds wrote:

> Many people seem to enjoy per-hunk commits, but I seldom do that. Maybe 
> it's just because I'm *so* comfortable with diffs, that when I clean up an 
> ugly sequence of commits, what I do is literally:
> 
>  - I make sure that my ugly sequence of commits is on some temporary 
>    branch, but that the _end_result_ is good and clean (ie I will have 
>    tested the end result fairly well, and made sure that there are no 
>    debug statements etc crud left).
> 
>    I would call this branch something like "target", because the end 
>    result of that branch is what I'm looking for - even if the commits in 
>    the sequence that gets me there are individually ugly!
> 
>  - I just switch back to my starting point (and now I'm usually on 
>    "master"), and do
> 
> 	git diff -R target > diff
> 
>    to create a diff of my current tree (which is initially the starting 
>    point) to the good result.
> 
>  - I actually edit the "diff" file by hand, and edit it down to the part I 
>    actually want to commit as the first in the series. And then I just do 
>    a "git-apply diff" to actually apply that part to my working tree.
> 
>  - I then edit any missing parts in the actual working tree (for example, 
>    if there were mixed hunks that I want to get to in later commits, and I 
>    edited out above, or that I need to partially undo), to do any 
>    finishing touches.
> 
>  - I now have a tree I can compile and test, and has the "first part" of 
>    the journey towards the final "target" state. If compiling/testing 
>    shows that I missed something, I can still fix things, and/or go back 
>    to doing another "git diff -R target" to see if I missed something).
> 
>  - I commit that first case, and repeat the sequence from step 2 (and 
>    at every step, the "diff" file ends up shrinking and shrinking).
> 
> The above sounds like it's a complicated sequence, but it really isn't. 
> Partly because I just am very comfortable with diffs indeed (probably more 
> than most people), but partly because at all times "git diff" works fine 
> to see what I've done, and what the diff to "target" is.

It only sounds like a complicated sequence because you didn't write a 
script to do it...

$ git checkout -b clean origin
$ git-refine target
  (edit the patch in the editor that pops up)
$ git-refine
Test changes and commit
$ make test
...
$ git commit
  (write message)
$ git-refine
  (edit the patch, etc)
  ...
$ git commit
$ git-refine
All done.

I actually wrote it years ago, but I couldn't describe my workflow well 
enough, so I didn't submit it. If everybody seems to be doing the same 
thing, I can submit my script...

	-Daniel
*This .sig left intentionally blank*