[dev] Fwd: Rebase vs. Merge

[Michael M Slusarz]

Quoting Ben Klang <ben at alkaloid.net>:

>>> 1) When working on major code changes, we should create a topic  
>>> branch and push it to a remote branch that we track locally.  The  
>>> motivator behind this is to have a place where our changesets are  
>>> backed up.
>>
>> Sure, agreed. Though I usually wait until my code is at least  
>> somewhat pretty before sharing it with everyone ;)

Agree with Mike R. here.  Understand the backup motivation, but  
realize that once you push to the master repo that commit messages are  
generated and it is quite possible that people may eyeball these  
messages or even the code itself.  Probably shouldn't waste people's  
time unless the code is at least potentially somewhat useful to  
someone besides yourself.

>>> 2) If possible, complete the work and merge it back into master  
>>> without ever rebasing or merging *from* master.  That keeps the  
>>> history clean.
>>
>> I don't agree here.  Well, partially. We should *never* merge from  
>> master onto a topic branch...that caused me hours and hours having  
>> to resolve conflicts for every singe commit that occured on master  
>> since I branched. We should rather rebase.  I think the point of a  
>> topic branch is to contain _only_ the changes that are different  
>> from master. If we don't keep an _active_ topic branch up to date,  
>> that's no longer true. Obviously the impact of not having it up to  
>> date would be less for branches that are probably going to be short  
>> lived, for branches that are not actively being worked on, or  
>> (obviously) for branches that will never be pushed to  
>> git.horde.org, but in general, I feel that if share our branches  
>> with others, it should be kept up to date when feasible.

Again, agree with Mike R.  I personally want my topic branches to only  
contain the differences to master.  And every local topic branch I  
create, I always do a 'git rebase master' whenever I come back to it  
to ensure that whatever changes I make going forward in the topic  
branch will be able to be cleanly applied to master.

>>> But that's only an ideal case, where no (or few) conflicts are  
>>> generated and the topic branch doesn't rely on changesets from  
>>> master after the branch creation.
>>
>> Hopefully, if you don't merge, but rebase, there shouldn't be any  
>> conflicts with master.
>>
>>> To handle this non-ideal case, I propose this:
>>>
>>> 1.5) When changes from master are necessary in a topic branch,  
>>> delete the remote branch.  Next rebase your local topic branch.   
>>> Finally, push the local branch to the origin and set it up to  
>>> track again.
>>
>> I'd be fairly strongly against this. What happens if someone has it  
>> checked out, and also has local changes they intend to share? The  
>> remote should only be deleted once it's no longer relevant, or has  
>> been merged into master.

Agree with Mike R. (sorry Ben :) ).

>>> Deleting a remote branch can be done like this:
>>> git push origin :some-branch
>>>
>>> Now, I don't think deleting branches all the time is ideal.  The  
>>> main drawback to this is when multiple developers are working  
>>> in/tracking the remote branch.  They would all have to fetch down  
>>> the changes and check out the new branch.  But hopefully, this  
>>> won't happen frequently.
>>>
>>> What do you think?
>>
>> I think that:
>>
>> git rebase origin/master
>> git pull --rebase
>> git push
>>
>> should work for remote branches, then when it's time to merge into master:
>>
>> git checkout master
>> git merge [topic]
>> git pull --rebase
>> git push
>>
>> should work.

This all sounds good to me.  I would vote for putting up these  
instructions on horde.org Git page.

michael

-- 
___________________________________
Michael Slusarz [slusarz at horde.org]