You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bigtop.apache.org by Konstantin Boudnik <co...@apache.org> on 2013/05/03 22:41:49 UTC
Avoiding trivial merges: using rebase properly
Guys,
some might have noticed in the master's branch history this commit:
* commit 2218261eb70ca4f3ba3b4e1a7479273c09efe448
|\ Merge: 10fb276 38eafa0
| | Author: Konstantin Boudnik <co...@apache.org>
| | 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
Re: Avoiding trivial merges: using rebase properly
Posted by Anatoli Fomenko <af...@yahoo.com>.
Confirmed: extremely furious.
Anatoli
________________________________
From: Konstantin Boudnik <co...@apache.org>
To: dev@bigtop.apache.org
Sent: Friday, May 3, 2013 2:00 PM
Subject: 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 <co...@apache.org> wrote:
>
> > Guys,
> >
> > some might have noticed in the master's branch history this commit:
> >
> > * commit 2218261eb70ca4f3ba3b4e1a7479273c09efe448
> > |\ Merge: 10fb276 38eafa0
> > | | Author: Konstantin Boudnik <co...@apache.org>
> > | | 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
> >
> >
Re: Avoiding trivial merges: using rebase properly
Posted by Konstantin Boudnik <co...@apache.org>.
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 <co...@apache.org> wrote:
>
> > Guys,
> >
> > some might have noticed in the master's branch history this commit:
> >
> > * commit 2218261eb70ca4f3ba3b4e1a7479273c09efe448
> > |\ Merge: 10fb276 38eafa0
> > | | Author: Konstantin Boudnik <co...@apache.org>
> > | | 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
> >
> >
Re: Avoiding trivial merges: using rebase properly
Posted by Sean Mackrory <ma...@gmail.com>.
+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 <co...@apache.org> wrote:
> Guys,
>
> some might have noticed in the master's branch history this commit:
>
> * commit 2218261eb70ca4f3ba3b4e1a7479273c09efe448
> |\ Merge: 10fb276 38eafa0
> | | Author: Konstantin Boudnik <co...@apache.org>
> | | 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
>
>