Best way to collapse a bunch of git commits into one?

[Greg Spencer]

Say I have a local branch with a bunch of things committed to it (lots of checkpoints, for instance), and I want to rebase it to trunk without having to merge each change separately, because I know it touches the same file the whole way through, and I'll have to merge it 10 times instead of just that final merge.

What's the best way to collapse all those changes into one with git?  I have been doing the following, and it just seems clunky:

1) Open up gitk, select trunk and my top revision and make a patch of the diff between the two revisions (yes, I could probably do this on the command line somehow, but this way I don't have to look up hashes)

2) switch to trunk

3) create a new branch

4) git apply the patch.

5) rebase the new branch to trunk and merge that one commit

6) delete the old branch and rename the new branch with the old name.

I'm sure there's got to be some simple way to do this in git, but it doesn't appear so from the help that I've looked at.

-Greg.

[Steven Bennetts]

git checkout trunk

git checkout -b new_branch

git merge --squash old_branch

--
Chromium OS Developers mailing list: chromiu...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en

[Vince Laviano]

On Fri, Apr 15, 2011 at 2:09 PM, Greg Spencer <gspe...@chromium.org> wrote:

http://progit.org/book/ch6-4.html

Check out the "squashing a commit" section in particular.

[Zdenek Behan]

http://cheat.errtheblog.com/s/git/

Squashing
---------
WARNING: "git rebase" changes history. Be careful. Google it.

git rebase --interactive HEAD~10
  (then change all but the first "pick" to "squash")
  squash the last 10 commits into one big commit

--

[Greg Spencer]

Thanks, that helps a lot!

-Greg.

[Zdenek Behan]

That works, but interactive rebase preserves all of your log messages and gives you the option to compose a new one made of the old ones. There's many many ways to juggle with patches and recommit.

On Sat, Apr 16, 2011 at 9:15 AM, Dominic Battre <bat...@google.com> wrote:

Just for the record.

I would do:

git checkout my_branch

git reset --soft trunk

git commit -a

It does not require the creation of a second branch nor the manual process of an interactive rebase.

git reset --soft keeps your working copy unchanged but makes my_branch point to the same revision as trunk. In other words, it looks like you had just created my_branch from trunk and did all the changes that are contained in trunk...my_branch).

Best regards,

Dominic

[Mandeep Singh Baines]

I agree with zbehan. git rebase -i is the way to go. But I'd like to highlight
an alternative workflow (what I use). I use git commit --amend when amending
a change I'm working on. I still get the checkpoint functionality via
git reflog.