Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Bigtop, mail # dev - Avoiding trivial merges: using rebase properly


Copy link to this message
-
Avoiding trivial merges: using rebase properly
Konstantin Boudnik 2013-05-03, 20:41
Guys,

some might have noticed in the master's branch history this commit:

*   commit 2218261eb70ca4f3ba3b4e1a7479273c09efe448
|\  Merge: 10fb276 38eafa0
| | Author: Konstantin Boudnik <[EMAIL PROTECTED]>
| | Date:   Thu May 2 18:45:47 2013 -0700
| |
| |     Merge remote-tracking branch 'public/master' into trunk

It was caused by me paying little attention while doing
  % git fetch
  % git merge
  % git push
on top of a commit that was ready to get pushed.

Generally speaking "merge commits" are only good if you want to indicate that
a feature branch's work has been completed and you are bringing it to the
main line (whatever it is).

If you are working on a branch and someone has committed something irrelevant
to your immediate work consider avoiding merges: use git rebase instead. It
helps to keep the history clean and avoid clattering and confusions
from coming from these clearly meaningless and "parasitic" merge-commits.
Also, be considerate and don't rebase branches that are shared among others -
rebases rewrite history and it might be real messy.

So far we were very good about it, and I want to make myself an example of an
'anti-pattern' in action.

--
Take care,
Cos