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

[Brent Goodrick <bgoodr@gmail.com>]

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:
>
> 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.