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:jburw...@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 <alex.hu...@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:jburw...@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 <alex.hu...@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...@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?