Alex, I think we need concern ourselves with both to maximize the clarity of the history that will eventually be merged into master. Therefore, we need to make sure that the master to feature branch syncs are done properly as well.
Thanks, -John On Mar 30, 2013, at 5:07 PM, Alex Huang <alex.hu...@citrix.com> wrote: > +1. I think we're specifically talking about merging into master, not > syncing from master. > > --Alex > >> -----Original Message----- >> From: John Burwell [mailto:jburw...@basho.com] >> Sent: Saturday, March 30, 2013 2:04 PM >> To: dev@cloudstack.apache.org >> Subject: Re: [DISCUSS] git rebase vs git merge in your feature branch? >> >> 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. >> >> 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?
