Re: Trouble testing out a patch on a branch new scratch git.git repository

From: Brent Goodrick <bgoodr@gmail.com>
Date: Feb 9, 2009, 21:59 UTC
Message-ID: <e38bce640902091359j3f306839h9aeb699e18e420ab@mail.gmail.com>
In-Reply-To: <7vmycww6if.fsf@gitster.siamese.dyndns.org>

My changes should live on my bg/no-progress branch until which time as they are accepted so I don't want them plunked down onto the originating branch quite yet (rebasing is fine, but I don't want to disturb that originating branch).

To explain what I mean: Yesterday, I had this configuration on my bg/no-progress branch:

             A---B---C---D (bg/no-progress)
            /
----1-----2----3----4 (master)

B C and D commits are noisy, fix-the-white-space-and-conform-to-coding-guidelines type commits. I want to collapse A through D into one commit called E on that branch so that I can run git format-patch -M on the result and provide a nice patch email. I would end up with:

             E (bg/no-progress)
            /
----1-----2----3----4 (master)

I do have a way to do that, but it is cumbersome: I ended up doing:

1. git diff -p >saved_patch of A through D (I don't recall the exact
git diff command).
2. Use a form of git rebase similar to "git rebase --onto topicA~5
topicA~3 topicA" as explained in the git-rebase man page
3. Use git apply saved_patch
4. Reapply the commit with a new commit message
5. Use git format-patch -M --stdout .... > mail.txt

Again, all while staying on the bg/no-progress branch.

But that was tricky (at least the git rebase command was). Is there a shorter, cleaner way to compress multiple commits on a given branch using one rebase command and not saving off a patch?

Thanks, bg

On Sun, Feb 8, 2009 at 8:58 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 59 quoted lines

>
> Brent Goodrick <bgoodr@gmail.com> writes:
>
> > What I really want to do is simply replace the last two commits on the
> > branch with one commit, so that when I make my patch it will be just
> > the full set of changes and not a lot of noise. Is there a way to do
> > that? (note: I did try the git merge --squash command but it just
> > showed me the usage, as I was on my bg/no-progress branch).  Note that
> > I know that I would not be able to do this once some of my changes had
> > merged upstream.
>
> Suppose you have this topology.  You forked and built 2 commits, while the
> upstream advanced its tip (or not).
>
>                 1--2 your commits (master)
>                /
>        ---o---o---o upstream (origin)
>
> 1. Using "rebase -i"
>
>    ... on your "master"
>    $ git rebase -i origin
>    ... will give you an insn sheet for interactive rebase to edit.
>    ... you will see something like:
>
>        pick xxxxxx title of commit 1
>        pick yyyyyy title of commit 2
>
>    ... edit the second "pick" to "squash", save and exit the editor.
>    ... You are telling it to "first cherry-pick my 1, and then squash my
>    ... 2 on top of it.
>
>    ... it will do as it is told, and will give you another editor, with
>    ... messages from both commits in it.  Edit to formulate a log message
>    ... suitable for the combined commit, save and exit the editor.
>
>   You will end up with:
>
>        ---o---o---o---X
>
>   where rightmost 'o' is still origin, X is your two commits squashed
>   into one.
>
> 2. Using "mrege -s squash"
>
>    ... on your "master"
>    $ git merge --squash origin
>    ... this will stop without creating a commit.  Then you would
>    $ git commit
>    ... and the editor will give you the log message from all the
>    ... commits on the branch you just merged.  Come up with a single
>    ... log message to describe all, save and exit the editor.
>
>   You will end up with:
>
>        ---o---o---o---X
>
>   where rightmost 'o' is still origin, X is your two commits squashed
>   into one.