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
-
Re: Avoiding trivial merges: using rebase properly
+1 - I'm a big fan of `git pull --rebase` for just fetching remote changes
and moving my local commits ahead of them.

On Fri, May 3, 2013 at 1:41 PM, Konstantin Boudnik <[EMAIL PROTECTED]> wrote:

> 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
>
>