[Kde-scm-interest] Re: Usage of pull rebasing and merges

[Boyd Stephen Smith Jr.]

In <20110209085437.GA28152 at ugly.local>, Oswald Buddenhagen wrote:
>On Wed, Feb 09, 2011 at 02:27:31AM -0600, Boyd Stephen Smith Jr. wrote:
>> I agree with your definition of a good history, but git does no favors by
>> automatically committing merges.  The merge is another state and needs to
>> be tested before it is actually committed.
>
>you can amend a merge like any other commit.

You can also use the --no-commit option to git merge.  Still, I'm pretty sure 
I prefer the bazaar behavior of requiring a explicit commit after a merge, 
even a clean/trivial one.

>but i don't agree with the definition in 99% of the cases, because
>rebasing is usually a trivial operation, and there is no reason to
>believe the rebased commits would behave differently than the original
>ones when the end result is still correct.

While that's true in 99% of the cases, it's the cases where that's not true 
where rebase gets you in trouble.  Same thing is true about trivial merge 
commits.  Both ensure that the textual changes are consistent, but they don't 
say anything about the semantic changes that may have happened in either set 
of commits.

>when the rebasing causes
>non-trivial conflicts, you have a point. other than that, merges of
>short branches are only useful as "markers" (which is utterly pointless
>in the by far most cases, as the branches are just one or two commits
>long after they have been properly reshaped).

Having the correct branch points, even for branches that are one or two 
commits long, can be useful both for automated tools like git bisect and for 
users that may want to use "just enough development code" for a critical (to 
them) feature their stable software is missing.  In both cases, it is only an 
incremental improvement, true.

Using a merge-based workflow instead of a rebase-based workflow makes it 
easier to share changes.  (Since SHA1s rarely change.)  It is also good 
practice for when your branch suddenly becomes long-lived or contains sub-
branches and rebase becomes troublesome or downright unworkable.

If you want Git to behave like CVS or SVN, then by all means, rebase all the 
time.  If you want to benefit from some of the features of distributed 
development, it is best to avoid rebase when possible.  (It can be quite a 
good tool for rewriting bad commits.)
-- 
Boyd Stephen Smith Jr.                   ,= ,-_-. =.
bss at iguanasuicide.net                   ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy         `-'(. .)`-'
http://iguanasuicide.net/                    \_/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-scm-interest/attachments/20110209/3f86c604/attachment.sig