Changes between Version 11 and Version 12 of Moving to Git


Ignore:
Timestamp:
Jun 26, 2009, 2:01:32 PM (15 years ago)
Author:
treat@kde.org
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • Moving to Git

    v11 v12  
    2626
    2727    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.
     28
     29    Another possibility is to "git revert" the patch and all patches it depends upon.  The author could then cherry-pick the change, modify it to match the reviewers comments, and commit it again as a separate version.
     30
     31    The best way to answer this question is likely to try a test install of GitHub or Gitorious or one of the other web based hosting tools for Git and begin trying out these scenarios to see what works best.
    2832
    2933    evmar's doc describing [http://neugierig.org/software/git/?url=git-cl/tree/README.codereview Chrome's git/reitveld workflow] discusses some of these issues in more depth