Best-Practice "Merge vs. Rebase" searched...

[Kevin Bullock]

Here's some of the previous discussion that's happened on this list: <http://markmail.org/thread/7ubjqw7dhsvjps3t 
 >.

I think rebasing has an additional danger: even if the rebase  
completes successfully, you don't know that the program is correct. It  
could correctly re-apply all your changesets and still fail the test  
suite. You'd then have to fix up the program and either (a) commit a  
new fixup changeset, or (b) edit the history further to fix the  
breakage. (This danger also exists in Git's merge command, which auto- 
commits without review if the patches apply cleanly unless you pass -- 
no-commit.)

In general, my opinion is that Git users are far too comfortable with  
things like rewriting history and auto-merging. Witness the prevalence  
in the documentation of not just `git rebase`, but also `git reset`  
and `git commit --amend`, without much warning about what happens if  
the history you're editing has already been pushed. I don't have a  
problem with editing history, but Git's most-commonly-used command set  
seems to normalize history editing a bit too much for my comfort. It's  
not really a technical problem with Git, though, it's a fuzzy best- 
practices issue.

pacem in terris / mir / shanti / salaam / heiwa
Kevin R. Bullock