Junio C Hamano <gitster@xxxxxxxxx> 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
-
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
