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

On 5/9/07, Linus Torvalds [off-list ref] wrote:

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

Geez,  this is similar [in nature, not scale] to what I've been doing.
After reading about people "right-clicking on hunks in git-gui",
I was convinced I needed to force myself to do more manipulations
inside git itself.  Hmm...

Maybe, in addition to [or in] the User Manual, git should have some
workflow examples, which have been cribbed from various emails
on this list?

Thanks,
-- 
Dana L. How  danahow@gmail.com  +1 650 804 5991 cell