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

[Thiago Macieira]

Em quarta-feira, 9 de fevereiro de 2011, às 04:21:03, Boyd Stephen Smith Jr. 
escreveu:
> In <20110209100027.BE91573EC at nargothrond.macieira.info>, Thiago Macieira
> 
> wrote:
> >You don't rebase someone else's commits. You only to do that to your own.
> >
> >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.
> 
> These two points sound like a contradiction to me.  Please explain.

If someone is pulling from you, you don't rebase. If you're pulling from 
someone, that other person doesn't rebase.

The code that goes to the server when you're done doesn't have to be the merge 
mess that you made. You *can* clean up before finishing the collaboration.

> Side note: When a commit is "bad", for whatever reason (doesn't compile on X
> supported architecture, doesn't pass automated tests, doesn't follow code
> formatting standards, whatever), it should be rewritten.  Sometimes rebase
> is the best tool for this, sometimes it is not.

Agreed.

> If I author a branch, then contributor X puts two commits on it to fix
> compilation errors on m68k, contributor Y puts a commit on it adding the
> doxygen documentation I forgot, and contributor Z provides a new test case
> for my code that is broken with a separate commit to fix it, I should
> rebase, yes? Some of those commits aren't mine!

No. But there's no reason why there needs to be merge commits in-between.

> Good commits should not be rewritten, so that they can be more easily
> shared. Remember, each time you rebase, everyone that has used your commits
> must do "RECOVERING FROM UPSTREAM REBASE" in the git manual pages.

Right. Which is why you don't rebase during the collaboration phase.

-- 
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/f390efe3/attachment.sig