On 5/9/07, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxx +1 650 804 5991 cell
-
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
