cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chiradeep Vittal <>
Subject Re: [DISCUSS] git rebase vs git merge in your feature branch?
Date Mon, 01 Apr 2013 17:08:52 GMT

On 3/30/13 3:00 AM, "Wido den Hollander" <> wrote:

>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
>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.

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

View raw message