From: Dana How Date: Wed, 09 May 2007 16:33:40 GMT Subject: Re: [FAQ?] Rationale for git's way to manage the index Message-ID: <56b7f5510705090933t261e414es9e3cc63b28b60546@mail.gmail.com> In-Reply-To: On 5/9/07, Linus Torvalds 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