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@xxxxxxxxx> wrote:
>
> Brent Goodrick <bgoodr@xxxxxxxxx> 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.
--
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
