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

[Boyd Stephen Smith Jr.]

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.

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.

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!

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