Changes between Version 11 and Version 12 of Moving to Git
- Timestamp:
- Jun 26, 2009, 2:01:32 PM (15 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Moving to Git
v11 v12 26 26 27 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. 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. 28 32 29 33 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