Confirmed: extremely furious. Anatoli
________________________________ From: Konstantin Boudnik <[email protected]> To: [email protected] 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 <[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 > > > >
