git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Matthieu Moy <Matthieu.Moy@imag.fr>
Cc: "Paolo Ciarrocchi" <paolo.ciarrocchi@gmail.com>,
	"Junio C Hamano" <gitster@pobox.com>,
	"git mailing list" <git@vger.kernel.org>
Subject: Re: How to split a patch
Date: Mon, 28 Jan 2008 02:40:38 -0800	[thread overview]
Message-ID: <7vr6g2teqh.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <7vy7aatfck.fsf@gitster.siamese.dyndns.org> (Junio C. Hamano's message of "Mon, 28 Jan 2008 02:27:23 -0800")

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

  reply	other threads:[~2008-01-28 10:41 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-28  9:05 How to split a patch Paolo Ciarrocchi
2008-01-28  9:25 ` Junio C Hamano
2008-01-28  9:32   ` Paolo Ciarrocchi
2008-01-28  9:47     ` Matthieu Moy
2008-01-28 10:27       ` Junio C Hamano
2008-01-28 10:40         ` Junio C Hamano [this message]
2008-01-28 10:49           ` Mike Hommey
2008-01-28 10:44         ` Wincent Colaiuta
2008-01-28 12:47         ` Johannes Schindelin
2008-01-28 10:27       ` Wincent Colaiuta
2008-01-28 10:37     ` Boaz Harrosh

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7vr6g2teqh.fsf@gitster.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=Matthieu.Moy@imag.fr \
    --cc=git@vger.kernel.org \
    --cc=paolo.ciarrocchi@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).