Any way to "flatten" a series of changes in git

Hello,

I have a branch with a whole series of commits. I want to export this work to be customer (to their svn repo if that has any bearing on it). All the stuff in the history is irrelevant to my customer ("committing now, going to bed" etc.) so I'd like to create a new branch that only has one commit.. the end point with a new message. Is this possible?

Thanks again!

On Thursday, October 22, 2009 at 21:03:44 (+0100) Howard Miller writes:

git rebase is your friend.

Bill

On Thursday, October 22, 2009 at 15:30:53 (-0500) Bill Lear writes:

Someone correct me if I'm wrong.

% git branch
* master
% git checkout -b my_work_branch
% [work work work, commit, commit, commit]
% git rebase -i master

You'll then get an editor buffer that looks like this:

pick 16730c6 baz 0 pick 2a844e7 baz 1 pick d6e71dc baz 2 pick d1a6995 baz 3 pick 157e675 baz 4

# Rebase ef0a89e..157e675 onto ef0a89e # # Commands: # p, pick = use commit # e, edit = use commit, but stop for amending # s, squash = use commit, but meld into previous commit # # If you remove a line here THAT COMMIT WILL BE LOST. # However, if you remove everything, the rebase will be aborted. #

Edit this to keep what you need: pick 16730c6 baz 0 squash 2a844e7 baz 1 squash d6e71dc baz 2 squash d1a6995 baz 3 squash 157e675 baz 4

then exit the editor. It'll pop you in another editor session to type in a commit message for these, just type in what you need and exit and you'll have the new commit with all the olds ones squashed into it.

Bill

On Thu, Oct 22, 2009 at 13:44, Bill Lear <rael@zopyra.com> wrote:

Alternatively, you could use git merge --squash

git checkout master git merge --squash topic

See git-merge(1) for details.

rebase --interactive it excellent for cleaning up history, especially if you want to end up with more than one commit at the end. merge --squash is usually sufficient if all you need is one commit at the end.

Brilliant, thanks everybody!! I'll go and back up my database and have a play with these options.

On Thu, Oct 22, 2009 at 9:58 PM, Howard Miller <howard@e-learndesign.co.uk> wrote:

I don't think you need it. when you rebase or squash git don't throw away your commits

when I do things like that I usually create a new branch to do my tests

if I'm happy with the result I can do

git checkout myRealBranch git reset --hard myTestBranch # do the push/svn dcommit/whatever

if I'm not happy I can start all over again just doing:

git checkout MyTestBranch git reset --hard myRealBranch

regards, Daniele

Howard Miller <howard@e-learndesign.co.uk> writes:

You can use either "git merge --squash" or "git rebase --interactive" (changing 'pick' to 'squash').

Actually thinking some more.... I don't understand something about this. I don't actually want to merge or rebase with anything. I just want to say "make those commits a series of commits on a branch into just one commit with a new message". I seriously suspect I'm missing the point somewhere but what has that got to do with merging or rebasing?

Thanks again

2009/10/22 Howard Miller <howard@e-learndesign.co.uk>:

Oh..... more reading of the help. It's this I take it...

" For example, if you want to reorder the last 5 commits, such that
what was HEAD~4 becomes the new HEAD. To achieve that, you
       would call git-rebase like this:

           $ git rebase -i HEAD~5"

Would it be ungrateful to suggest that the existence of that option isn't clear from the synopsis at the start of the help? :-) I guess I can put the SHA1 identifier of the first commit in my branch too? Anyway, I'll go and try it and see what happens.

On Thu, 22 Oct 2009, Howard Miller wrote:

Actually using "git merge --squash" is a bit different from using "git rebase --interactive".

1. "git merge --squash"

  --squash::
        Produce the working tree and index state as if a real
        merge happened (except for the merge information),
        but do not actually make a commit or
        move the `HEAD`, nor record `$GIT_DIR/MERGE_HEAD` to
        cause the next `git commit` command to create a merge
        commit.  This allows you to create a single commit on
        top of the current branch whose effect is the same as
        merging another branch (or more in case of an octopus).

This means for example if you did your changes on a separate topic branch, and you want to merge your changes into 'master' branch, you would do

  $ git checkout master
  $ git merge side-branch

which would result in the following history:

   ---*---*---*---*---*---*---*---M         <-- master
       \                         /
        \-.---.---.---.---.---.-/           <-- side-branch

If you used '--squash' option to git-merge, because changes were made in throwaway topic branch, and as you said only final result matter, you would get:

  $ git checkout master
  $ git merge --squash side-branch

   ---*---*---*---*---*---*---*---M'        <-- master
       \                         
        \-.---.---.---.---.---.             <-- side-branch

where commit M' has the same contents (the same tree) as commit M in previous example, but is not a merge commit.

If you simply want to squash last say 5 commits into one, you can use "git merge --squash" for it in the following way:

  $ git reset --hard HEAD~5
  $ git merge --squash --no-ff HEAD@{1}

which means basically: rewind to state 5 commits back, then merge in changes from before rewind, squashing them. The --no-ff is needed because otherwise it would be fast-forward and no commit would be created.

2. "git rebase --interactive"

The interactive rebase is meant to edit commits being rebased, but it can be used simply to edit commits. It includes 'squash' command that can be used to concatenate (squash) commits.

So to squash last say 5 commits into one, you would use

  $ git rebase --interactive HEAD~5

then edit provided list of commands and commits to read something like this:

   pick deadbee The oneline of this commit
   squash fa1afe1 The oneline of the next commit
   ...
   squash beedead The oneline of the that commit

i.e. replace 'pick' command by 'squash' command.

This is a very powerfull command, and can be used for example to turn series of say 5 commits into series of say 2 commits; not simply squashing to a single commit, but reducing number of commits (and presumably cleaning up those commits).

HTH (hope that helps)

2009/10/22 Jakub Narebski <jnareb@gmail.com>:

Hi Jakub,

Yes it helps a lot. What I *don't* care about (or want to do) is actually do a merge or a rebase I just want to change history. Well, that's what I thought I wanted. What I suppose I really want is the full history for *me* and a second branch with the 'reduced' history to push to my client. I suppose that's different yet again?

Howard

Actually, what I should have said in the first place is that this is specifically nothing to do with the main trunk. We are doing small custom developments for clients away from the main project development. So we specifically don't want to merge or rebase with the master - that's never going to happen. I want to keep the development branch in tact for my reference, but when I push (the custom development branch) to the client I need that sanitized. I think I finally have it clear in my own head now!

Howard

Howard Miller schrieb:

The easiest way (IMHO) to achieve this is certainly:

  # start a new branch at the tip of the series
  $ git checkout -b all-in-one the-series

  # squash 17 commits
  $ git reset --soft HEAD~17
  $ git commit

Now you have a new branch 'all-in-one' that has the same contents as the original series 'the-series', but with only one commit:

  $ git diff the-series..all-in-one  # must show no differences

-- Hannes

Johannes Sixt <j.sixt@viscovery.net> writes:

I think --squash "*merge*" is conceptually simpler to explain *and* has an added advantage that it helps preparing the consolidated log message.

    # start from the last customer dump
    $ git checkout -b customer-update last-release
    # give the customer the greatness in the series, content-wise
    $ git merge --squash the-series
    $ git commit

This will start the "customer-update" branch starting from the last dump you gave to the customer, merge in the changes made in the series without history, and when you make a commit, you will have access to all the individual log messages in the series to look at as reference, so that you can cut and paste from them to summarized message instead of typing everything anew.