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

[Thiago Macieira]

On Wednesday, 9 de February de 2011 03:41:32 Boyd Stephen Smith Jr. wrote:
> 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.

Or a detriment. Git bisect doesn't perform as efficiently in the presence of 
merges, since it can't find a middle point to bisect at.

If someone wants to merge a branch to use, that's fine. But since they are not 
pushing that to the server, we don't really care what they do. If it doesn't 
affect others, they can do whatever they want.

> 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.

You don't rebase someone else's commits. You only to do that to your own, 
before you push them.

If you're pulling from someone, you have a merge and you keep it that way. 
Like I said, if you're not affecting others, you do it however you want.

If you're both pulling and being puilled from, then you need to keep the 
SHA-1s stable. That's something that affects others.

But that doesn't mean that the final push to the server, when the code that the 
collaboration produced is done needs to be a history mess. In fact, it's 
entirely possible for someone to rebase the work and clean up the history into 
nice small and working commits, getting rid of "fix the compilation that the 
previous fix didn't fix" (which I had to do yesterday for Qt).

> If you want Git to behave like CVS or SVN, then by all means, rebase all the

We don't.

> 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.)

I don't agree either. Rebasing is a very powerful tool and should be used 
wisely, when it makes sense. It does not impede collaboration.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Development Frameworks
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-scm-interest/attachments/20110209/46a47c6f/attachment-0001.sig