----- "Marian Csontos" <mcsontos(a)redhat.com> wrote:
From: "Marian Csontos" <mcsontos(a)redhat.com>
To: "Bill Peck" <bpeck(a)redhat.com>
Cc: "List for the development of the Beaker project"
Sent: Wednesday, January 13, 2010 1:16:34 AM GMT +10:00 Brisbane
Subject: Re: [Beaker-devel] deleting branches after merge
On 01/12/2010 03:11 PM, Bill Peck wrote:
> On 01/12/2010 04:21 AM, Marian Csontos wrote:
>> On 01/11/2010 09:18 PM, Bill Peck wrote:
>>> Hello Everyone,
>>> FYI - Just to keep things clean I've been deleting RFE and bugfix
>>> branches after merging them into master. Obviously I won't delete
>>> stable branches (we only have master right now).
>> If anyone would like to keep branch's history, it is possible to
>> rebase instead of merge, just do:
>> git pull --merge
This should be
git pull --rebase
Another way to have a look at the history of a merged branch is to do a git log on the
branch's hash. So if you do a git log on say master branch and you see something like
Merge: d462dea 0f9363b
Author: Bill Peck <bpeck(a)redhat.com>
Date: Mon Jan 11 13:15:13 2010 -0500
Merge branch 'master' into ticket51
You can do 'git log d62dea' which will show you the log history of that branch
that was merged.
> Can you explain in more detail how this would work and what the
> differences are?
> I was told you should *NOT* use rebase if you are sharing your repo.
> In fact, I thought rebase removed history.
Partially correct. Before publishing changes, you can do pretty much
anything including rewriting history.
It is the history on the server which counts.
You can run
git pull --rebase
[ which applies changes between origin..HEAD on top of branch ]
and, after solving any conflicts, run
This way, one will get rid of the branch as well as keep all the
Sometimes it is undesirable to keep history as is, and
git rebase -i
allows you to split/join/reorder commits before pushing them.
I love it.
>> -- Marian
>>> Beaker-devel mailing list
Beaker-devel mailing list