+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?
