Issue metadata
Sign in to add a comment
|
I can`t figure out how to `git cl land` after `git cl patch` with gerrit |
||||||||||||||||||||||
Issue descriptionAffected Version: What steps will reproduce the problem? I tried to manually land https://chromium-review.googlesource.com/c/570007 First, I tried (since `git cl patch` advertises --force heavily): thakis@thakis:~/src/chrome/src$ git cl patch --force -b land https://chromium-review.googlesource.com/c/570007 Switched to branch land. canonical issue/change URL: https://chromium-review.googlesource.com/570007 (type: gerrit) remote: Counting objects: 264516, done remote: Finding sources: 100% (62/62) remote: Total 62 (delta 13), reused 39 (delta 13) Unpacking objects: 100% (62/62), done. From https://chromium.googlesource.com/chromium/src * branch refs/changes/07/570007/8 -> FETCH_HEAD Checked out commit for change 570007 patchset 8 locally thakis@thakis:~/src/chrome/src$ git cl land It seems this repository has a Commit Queue, which can test and land changes for you. Are you sure you wish to bypass it? Press Enter to bypass CQ, or Ctrl+C to abort Running presubmit commit checks ... ** Presubmit ERRORS ** Missing LGTM from an OWNER for these files: ios/chrome/app/resources/EarlGreyAddition+Info.plist ios/chrome/app/resources/Info.plist ios/web/web_state/ui/wk_web_view_configuration_provider.mm testing/variations/fieldtrial_testing_config.json Presubmit checks took 4.6s to calculate. This gave me "missing LGTM" lines for a bunch of files not touched in the CL, so something went wrong somewhere. I then tried again without --force: $ git checkout -f master $ git pull thakis@thakis:~/src/chrome/src$ git cl patch -b land2 https://chromium-review.googlesource.com/c/570007 Switched to branch land2. canonical issue/change URL: https://chromium-review.googlesource.com/570007 (type: gerrit) From https://chromium.googlesource.com/chromium/src * branch refs/changes/07/570007/8 -> FETCH_HEAD Committed patch for change 570007 patchset 8 locally. Note: this created a local commit which does not have the same hash as the one uploaded for review. This will make uploading changes based on top of this branch difficult. If you want to do that, use "git cl patch --force" instead. thakis@thakis:~/src/chrome/src$ git cl land It seems this repository has a Commit Queue, which can test and land changes for you. Are you sure you wish to bypass it? Press Enter to bypass CQ, or Ctrl+C to abort WARNING: Some changes from local branch haven't been uploaded. Do you want to submit latest Gerrit patchset and bypass hooks? Press Enter to submit, or Ctrl+C to abortinterrupted The "WARNING: Some changes from local branch haven't been uploaded." scared me enough that I didn't want to submit. I'm not sure what would be different locally since I just patched in the change. Maybe because I didn't use --force? But using that didn't work either. What is the expected output? Patching in a CL and `git cl land`ing it should be possible somehow. What do you see instead? It isn't easy. Luckily, this wasn't a "world is broken, must land this now" situation, but if it was this would've been a significant source of stress. Please provide any additional information below.
,
Jul 13 2017
,
Jul 13 2017
The important thing to note here is that, with Gerrit, "git cl land" just clicks the "Submit" button on the change. It does basically nothing with whatever is in your local checkout. This is part of our efforts to make sure that everything which lands in the tree has an appropriate review audit log. (Contrast with Rietveld, where you could upload a change for review, get it approved, make another local commit which changes the nature of the CL entirely, and then 'git cl land' that with no update to the review.) So with that in mind, I'll address the second case: Since you ran "git cl patch" without --force, what you had in your local checkout was effectively a rebase of the actual change. That rebase hadn't been uploaded for review, so it wasn't what was going to be submitted, so "git cl land" warned you about it. That's all working as intended. For the first case, the error was reported by PRESUBMIT.py. So PRESUBMIT thought those files had been modified. My guess is that those files are new, and were introduced between the base of the change you patched in and the commit you were at previously. When git-cl-patch ran "git reset --hard", they became untracked files.
,
Aug 25 2017
,
Aug 28 2017
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by logan@google.com
, Jul 13 2017Labels: Proj-Gerrit-Migration