Changes between Version 8 and Version 9 of Moving to Git


Ignore:
Timestamp:
Jun 22, 2009 3:31:51 PM (15 years ago)
Author:
joe.mason@torchmobile.com
Comment:

Discussion of patch review branches

Legend:

Unmodified
Added
Removed
Modified
  • Moving to Git

    v8 v9  
    2020
    2121    For more see here: [http://benjamin-meyer.blogspot.com/2008/08/code-review-should-be-free.html Code Review Should Be Free]
     22
     23    ''As a patch author, what would I do if the reviewer asks for a change in a patch which I already have committed to a branch, with more patches on top of it?''
     24
     25    We would want to work out a full strategy for handling patch branches.  The easiest way to handle this is to treat patch branches as temporary.  The author can rewrite an earlier patch in a series using "git rebase -i", and then notify the reviewers that the branch has changed.  The reviewers would then re-download the branch.  Unfortunately they couldn't simply pull to their existing copy of the branch since the history has changed - this is a drawback.  (However, if they were just looking at the code on the web instead of downloading and building their own copy, this wouldn't affect them, and reviewing directly through gitweb would be pretty common.)  Another drawback is that this would overwrite the history of changes to the patch and leave only the final result.
     26
     27    Another option is to copy your existing branch (which is very cheap) and then make the changes to the new branch, again with git-rebase, then publish the new branch.  For this we would probably want to define a standard naming scheme for patch review branches, such as including an iteration number or the date in the branch name, to avoid a confusing mess of names.
    2228
    2329 * Would allow us to do away with manually editing/resolving ChangeLog files: