On 3/30/13 3:00 AM, "Wido den Hollander" <w...@widodh.nl> wrote:
>Hi, > >On 03/30/2013 12:36 AM, Edison Su wrote: >> 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? > >Yes, I'd vote for rebase, a couple of reasons: >- You can track changes more easy >- The feature can be committed to master in one single patch > >When stuff gets into master after a rebase in the feature branch (and >even a squash) you can see which feature came in with which commit. > >A feature can be easily reverted, but also one patch can be reviewed to >verify if it's OK. > >I just don't like merges, I think they make a mess of the repos. > >Wido +1 on rebase -0 on squash Sometimes features need to modify core components. Squashing loses the history /reasoning behind that modification. I would leave the decision of selective squashing to the committer.
