Hi,

On 03/30/2013 10:03 PM, John Burwell wrote:
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.


+1, with the note that it might be useful to squash the feature branch first to make life a bit easier.

So you don't get all these "short fix commits" in the master branch.

Features should be merged in cleanly so they can be traced back.

Wido

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?

Reply via email to