Wido, I intended my recommendation to be that the commit merged to master be squashed.
Thanks, -John On Mar 31, 2013, at 6:55 AM, Wido den Hollander <w...@widodh.nl> wrote: > Hi, > > On 03/30/2013 10:03 PM, John Burwell wrote: >> 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. > > +1, with the note that it might be useful to squash the feature branch first > to make life a bit easier. > > So you don't get all these "short fix commits" in the master branch. > > Features should be merged in cleanly so they can be traced back. > > Wido > >> 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?
