On Fri, Mar 29, 2013 at 04:36:06PM -0700, 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?
This is noted (although not as strongly as it could be) in the Branch Merge Expectations page [1]: "The branch has been rebased against the latest version of master, so that the differences are limited to what's expected to merge (grab the master commit-sh, so that you can point to it in the merge email)." If we add it to the git page, then please update the branch merge page to point to the specific expectations over on the git page. BTW - I'm +1 on this. You can always do a diff between HEAD of master and the feature branch, but that's always going to have some confusing changes that would be sorted out via a rebase. -chip [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Branch+Merge+Expectations
