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

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

[Howard Miller]

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!

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

[Bill Lear]

On Thursday, October 22, 2009 at 21:03:44 (+0100) Howard Miller writes:
>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?

git rebase is your friend.


Bill

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

[Bill Lear]

On Thursday, October 22, 2009 at 15:30:53 (-0500) Bill Lear writes:
>On Thursday, October 22, 2009 at 21:03:44 (+0100) Howard Miller writes:
>>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?
>
>git rebase is your friend.

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

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

[Jacob Helwig]

On Thu, Oct 22, 2009 at 13:44, Bill Lear <rael@zopyra.com> wrote:
> On Thursday, October 22, 2009 at 15:30:53 (-0500) Bill Lear writes:
>>On Thursday, October 22, 2009 at 21:03:44 (+0100) Howard Miller writes:
>>>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?
>>
>>git rebase is your friend.
>
> 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
>

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.

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

[Howard Miller]

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

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

[Daniele Segato]

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

>> rebase --interactive it excellent for cleaning up history, especially [...]

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


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

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

[Jakub Narebski]

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

> 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?

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

-- 
Jakub Narebski
Poland
ShadeHawk on #git

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

[Howard Miller]

> 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

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

[Howard Miller]

2009/10/22 Howard Miller <howard@e-learndesign.co.uk>:
>> 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
>

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.

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

[Jakub Narebski]

On Thu, 22 Oct 2009, Howard Miller wrote:

> > 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?

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


1. "git merge --squash"

>From documentation:

  --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)
-- 
Jakub Narebski
Poland

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

[Howard Miller]

2009/10/22 Jakub Narebski <jnareb@gmail.com>:
> On Thu, 22 Oct 2009, Howard Miller wrote:
>
>> > 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?
>
> Actually using "git merge --squash" is a bit different from using
> "git rebase --interactive".
>
>
> 1. "git merge --squash"
>
> From documentation:
>
>  --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)
> --
> Jakub Narebski
> Poland
>

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

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

[Howard Miller]

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

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

[Johannes Sixt]

Howard Miller schrieb:
> 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?

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

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

[Junio C Hamano]

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

> 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

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.