If you're using git, I typically do: git cl patch -b <newbranchname> 12345 where the number is the CL number. This patches in the change and makes the new branch use up the CL number of the original review, which will then be included in your commit. (If you want to fix the issue mapping of a branch later due to something going wrong, "git cl issue 12345" will do that.)
Then when you commit: git cl dcommit -c 'Full Name <[email protected]>' I typically paste that in from the AUTHORS file (which is a good extra check on whether someone has filed the CLA). Caveats: - I really ought to make it pull the author's name from the change description. I forget this sometimes. :( - When this attempts to close the code review after the commit goes through, it will fail (since it's not yours). This would be a one-liner fix in Rietveld that I've also been putting off. On Sun, May 3, 2009 at 7:47 AM, Peter Kasting <[email protected]> wrote: > If you check in patches for someone else, please do the following: > * Mention the person who wrote the patch. > * Since your gcl change is not the same Rietveld issue as the original > review, put a link to the original review in your change description. > * Put a BUG= or http://crbug.com/... line in so the bug gets updated > correctly. > * Either you or the original author should mark the original issue "closed" > and the bug "fixed". > We've had a number of people not doing the last couple steps, which means > that bugs have been patched, but the bug is open with no indication of fixes > on it. This hinders testing, merging, triage, etc. Try not to be sloppy! > PK > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
