hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anoop John <anoop.hb...@gmail.com>
Subject Re: [DISCUSSION] Avoiding merge commits
Date Fri, 23 May 2014 17:49:19 GMT
+1

-Anoop-

On Fri, May 23, 2014 at 11:16 PM, Jesse Yates <jesse.k.yates@gmail.com>wrote:

> +1 that's how I do all my git development and what I advocate at salesforce
> as well.
>  On May 23, 2014 10:39 AM, "Andrew Purtell" <apurtell@apache.org> wrote:
>
> > I recommend we do not push merge commits upstream. I suppose it is easy
> > enough to filter them out when looking at history but there is no need to
> > be merging upstream branches into your local tracking branch when you can
> > rebase instead. In this way we can avoid polluting the history in the
> > master repository with unnecessary merge commit entries. (And maybe some
> > devs will be merging upstream into tracking branches or merging commits
> > from local feature branches several times per day, and these will all
> > accumulate...)
> >
> > When updating your local tracking branch from upstream, use git fetch
> > upstream && git rebase upstream/branch instead of 'git merge'.
> >
> > When developing features on a local branch it's possible to do a squash
> > commit from the feature branch to the tracking branch using 'git rebase'
> > instead of 'git merge', then a push of the single squashed commit from
> the
> > tracking branch to the upstream branch.
> >
> > If these workflow choices are acceptable by consensus we can update the
> > 'how to commit' document with an illustration of the workflow with
> example
> > commands.
> >
> >
> > --
> > Best regards,
> >
> >    - Andy
> >
> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
> > (via Tom White)
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message