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
On Fri, May 03, 2013 at 01:56PM, Sean Mackrory wrote:
> +1 - I'm a big fan of `git pull --rebase` for just fetching remote changes
> and moving my local commits ahead of them.

Believe me - me too. You might ask Anatoli how furious I was at my previous company
haunting developers doing the junk merges all the time ;)

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