From: Junio C Hamano <gitster@pobox.com>
Date: Mon, 28 Jan 2008 10:40:38 GMT
Subject: Re: How to split a patch
Message-ID: <7vr6g2teqh.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <7vy7aatfck.fsf@gitster.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:

> Yes, and you can do the same with "git add -i".  These tools are
> not quite nice, as they encourage a wrong workflow of committing
> what you haven't had as a whole in the work tree.  By
> definition, you are making untested commits between your base
> commit (that presumably was tested well) and your final commit
> (that would also be tested well).
> ...
> There is no such tool yet, though.
> 
> The splitting you can do with "rebase -i" instead walks
> forwards.  That also lets you test before you make commits in
> each step.

Having said all that, what I tend to do in practice is something
like this:

 (1) Prepare a perfect state (i.e. what to become the final
     commit in the series) in work tree.  Make a commit.  Let's
     say I was working on 'master' branch.

 (2) Checkout the state before the series.  If I currently have
     a three commit series that I want to split further, that
     would be HEAD~3.  If I just made a huge change without
     making intermediate commits, that would be HEAD~1:

     $ git checkout HEAD~3

 (3) Get the final state in the work tree, to decide what to put
     in and what to omit from the first in the series:

     $ git diff -R master | git apply --index

 (4) Use "git-add -i" to prepare what I want in the first
     commit.

     $ git add -i

 (5) When the index is in a good shape, drop all other changes
     from the work tree.  This is what I thought would be a good
     first commit:

     $ git diff -R | git apply

 (6) Test it.  Make corrections.  Perfect it.  Then commit.

     $ git commit

 (7) Go back to step (3), until the commit that I make in step
     (6) matches 'master'.

 (8) Reset 'master' with HEAD:

    $ git branch -f master HEAD
    $ git checkout master