[Kde-scm-interest] Re: Usage of pull rebasing and merges
Boyd Stephen Smith Jr.
bss at iguanasuicide.net
Wed Feb 9 10:41:32 CET 2011
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
>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 `-'(. .)`-'
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
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
More information about the Kde-scm-interest