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?
