-
Aaron Gable authored
This CL changes the way that "git cl patch" behaves for Gerrit changes. Previously, git-cl-patch behaved just like it did for Rietveld: make sure you're on a branch, download the diff, apply it on top of your branch. However, this causes problems with Gerrit. Namely, when you upload a change to Gerrit, git-cl has to make sure that all parents of your local change have previously been uploaded as well, either as other changes or as commits already landed on the target branch. But the method for "applying a patch" from Gerrit was to cherry-pick it, and that changes the commit hash. So the resulting commit would *not* have been uploaded to Gerrit. Thus, the following routine didn't work with Gerrit: $ git checkout -t origin/master -b your-work $ git cl patch 123456 $ git checkout -tb my-work $ #hack and commit $ git cl upload This would fail during the upload with a message saying that the contents of 'your-work' hadn't been uploaded. This CL fixes the situation by replacing the cherry-pick with a hard reset. This means that the contents of the 'your-work' branch will be *exactly* what was downloaded from Gerrit. Uploads based on top of that commit will work just fine. Finally, in a concession to some people who want 'git cl patch' to actually apply a patch instead of performing a hard reset, if the current branch contains local work, then rather than leaving that work behind with a hard reset, we fall back to the old cherry-pick behavior with a confirmation dialog and warning that uploading will be hard. Bug: 723787 Change-Id: I3ad164f6d3078bff00139d446bb8ce97738a1344 Reviewed-on: https://chromium-review.googlesource.com/527345 Commit-Queue: Aaron Gable <agable@chromium.org> Reviewed-by: Andrii Shyshkalov <tandrii@chromium.org>
9387b4f0