----- "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"
<beaker-devel(a)lists.fedorahosted.org>
Sent: Thursday, January 14, 2010 9:10:05 AM GMT +10:00 Brisbane
Subject: Re: [Beaker-devel] deleting branches after merge
On 01/12/2010 04:19 PM, Bill Peck wrote:
> On 01/12/2010 10:16 AM, Marian Csontos wrote:
>> 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
>>>>> any
>>>>> stable branches (we only have master right now).
>>>> If anyone would like to keep branch's history, it is possible to
>>>> use rebase instead of merge, just do:
>>>> git pull --merge
>> ^^^^^
>> This should be
>> git pull --rebase
>> of course.
>>
>>>>
>>> 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
>> git push
>> This way, one will get rid of the branch as well as keep all the
>> history.
>> See
>> man git-rebase
>> for details.
>>
>> <Advertising-message>
>> 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.
>>
>
> I'm pretty sure this only works if you are working on a branch by
> yourself! If you do this while sharing with others git doesn't have
> the info needed to resolve conflicts! I think this is dangerous.
We do work on local branches though. When you do a
git fetch
git checkout -b master origin/master
You are on a local branch and you should be able to rebase your local master
from the origin/master until the cows come home. What you DONT want to do
is somehow rebase the branch that origin/master refers to. That is when you are rebasing
a non local branch (i.e one that others pull from)
In fact this makes much more sense to rebase on master.
If you do a git log on master you'll see how there are various
merges with master...i.e merges onto itself (well technically not itself, merges from
rmancy onto the master branch, both
happen to have the same name).
We should be able to do a rebase when working on master, thus we preserve a clear
and linear history of master.
Just before I did a bug fix commit directly to master. Since I had last updated master
though, a commit had been
made to it. So something like this went down
git add <file>
git commit
git push origin master:master
*opps non fast forward error*
git pull --merge
git push origin master:master
now the last three entries in the git log are this
commit 1f5f2590d13c04efbb77200d2f70079d028e5e3d
Merge: 6315b2b b60a4b9
Author: Raymond Mancy <rmancy(a)redhat.com>
Date: Thu Jan 14 10:01:02 2010 +1000
Merge branch 'master' of ssh://rmancy@git.fedoraproject.org/git/beaker
commit 6315b2bf863e1edc0840d5235e58f3cf41299140
Author: Raymond Mancy <rmancy(a)redhat.com>
Date: Thu Jan 14 09:17:39 2010 +1000
bz555184 - ISE when creating new system
commit b60a4b94eb903fc9380bcc7d8f951031ba79a2ea
Author: Bill Peck <bpeck(a)redhat.com>
Date: Tue Jan 12 20:20:41 2010 -0500
minor fix
So the top merge is a merge of my master into the current master.It merged the previous
two commits.
Kinda seems unecessary huh ?
if I had done a rebase instead that merge commit would not need to be there.
Of course it is! And people do like dangerous things! ;-)
RULE1:
One should never do a rebase of shared branch anyone might have pulled
from.
I'm pretty sure none of us are working directly on a shared branch.
Or at least we shouldnt be. Working on local branches of shared branches
is what we do.
One thus always pulls from upstream to merge changes into such a
branch.
But, every rule has an exception, and may be following is one:
EXCEPTION1:
In theory, a "closed" branch (or more precisley the branch to be
merged
upstream and deleted), might be a good candidate for rebase.
I have done a little homework, and it might work, if we wanted to keep
more-linear history.
May be not worth all the effort, but I wanted to learn more about git,
and now I have to. :-)
Let's have a development branch DevBranch and target branch Master,
then
git checkout DevBranch
git checkout -b TempRebaseBranch
git rebase Master
I've found that rebasing a branch with another branch that is significantly
different code wise is hard. I found there was a lot of manual conflict resolving
involved.
It seemed to me kind of error prone with all the manual merges I had to do. In these
instances I found a git pull --merge easier.
The history looked 'prettier' with a merge but it was also a very long history. If
I have been working on a
branch for 2 months and I have 100 commits to it, those commit logs are going to end up in
master.
Perhaps I'd rather see in the master log that my branch was merged into master, and if
I want to look
further at the commits of that branch I can do so myself. Different people have different
opinions about this
I'm relatively new to git, but this has been my experience and understanding. If
you're interested in what
Linus said about git in response to our redhat colleague here in Brisbane, see this
http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html
I don't think there is anything patently wrong with the way we've been doing
things. At the end of the day I guess it's
just a tool to help us do our job, so whatever works for us.
Raymond
will create new private branch TempRebaseBranch, containing all
changes
from DevBranch, but based on Master, while DevBranch will not be
affected.
-- Marian
_______________________________________________
Beaker-devel mailing list
Beaker-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/beaker-devel