In <[email protected]>, 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. ,= ,-_-. =. [email protected] ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-scm-interest mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-scm-interest
