You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Alex Huang <Al...@citrix.com> on 2013/04/01 01:44:17 UTC

RE: [DISCUSS] git rebase vs git merge in your feature branch?

John,

I was only referring to the conversation David and I had on IRC.  Agreed that in this thread we should clearly define both sides for others to follow.

--Alex

> -----Original Message-----
> From: John Burwell [mailto:jburwell@basho.com]
> Sent: Saturday, March 30, 2013 6:01 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] git rebase vs git merge in your feature branch?
> 
> Alex,
> 
> I think we need concern ourselves with both to maximize the clarity of the
> history that will eventually be merged into master.  Therefore, we need to
> make sure that the master to feature branch syncs are done properly as well.
> 
> Thanks,
> -John
> 
> 
> On Mar 30, 2013, at 5:07 PM, Alex Huang <Al...@citrix.com> wrote:
> 
> > +1.  I think we're specifically talking about merging into master, not syncing
> from master.
> >
> > --Alex
> >
> >> -----Original Message-----
> >> From: John Burwell [mailto:jburwell@basho.com]
> >> Sent: Saturday, March 30, 2013 2:04 PM
> >> To: dev@cloudstack.apache.org
> >> Subject: Re: [DISCUSS] git rebase vs git merge in your feature branch?
> >>
> >> Alex,
> >>
> >> It seems appropriate to me to use both rebase and squashed commits.
> >> To my way of thinking, we should rebase when syncing features
> >> branches with master (or the eventual target branch) to keep the
> >> revision history of the eventual patch as concise as possible.  We
> >> should merge from feature branches to master (or the appropriate
> >> target branch) using a squashed commit to properly record the history
> >> if adding the feature to the branch in a coherent manner.
> >>
> >> Those are my thoughts,
> >> -John
> >>
> >>
> >>
> >> On Mar 30, 2013, at 11:21 AM, Alex Huang <Al...@citrix.com>
> wrote:
> >>
> >>> Dave and I have talked on IRC at one point about this.  We both
> >>> thought
> >> feature branch merges should come in as a squashed commit because
> >> it's easier to see exactly what the changes that merge branch brought
> >> in were and easier to revert.  Something to consider when talking about
> this.
> >>>
> >>> --Alex
> >>>
> >>>> -----Original Message-----
> >>>> From: Edison Su [mailto:Edison.su@citrix.com]
> >>>> Sent: Friday, March 29, 2013 4:36 PM
> >>>> To: dev@cloudstack.apache.org
> >>>> Subject: [DISCUSS] git rebase vs git merge in your feature branch?
> >>>>
> >>>> Hi all,
> >>>>    I am trying to review some feature branches, when I see merge
> >>>> requests coming from mailing list, one thing that makes code review
> >>>> almost unrealistic is that, developers tend to use "git merge" to
> >>>> master branch whenever rebase is needed. I don't know other people
> >>>> really do review feature branch or not, if so, how to review a
> >>>> feature branch, with several "merge branch "master""  on the
> >>>> feature
> >> branch. I really don't find a better way to do that.
> >>>>   If, all we use "git rebase" to master branch, then the code
> >>>> review will be much easier, at least, what kind of commits you did
> >>>> on the feature branch can be easily identified. For example, I
> >>>> worked on storage_refactor branch for a few months, with a lot of
> >>>> changes, before sending out merge request, there are only less than
> >>>> 10 commits on the branch, reviewer can use "git diff since..HEAD"
> >>>> to get all the
> >> changes.
> >>>>  Should we advocate "git rebase" in
> >>>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git?