Re: [chromium-dev] "git cl land" errors

[Paweł Hajdan, Jr.]

+infra-dev

On Fri, Feb 10, 2017 at 1:59 AM, Varun <va...@chromium.org> wrote:

Not sure if this is related but I am seeing the same error. See: http://crbug.com/690658

I did git pull and then git cl land --bypass-hooks but the git cl land continued to fail.

On Thursday, February 9, 2017 at 4:28:18 PM UTC-8, Xianzhu Wang wrote:

Fwiw, when I see the error message, I run 'git pull -rebase' and retry 'git cl land', sometimes multiple times to succeed. I guess it's because there are new commits landed by others in the remote repository after 'git pull --rebase' before 'git cl land'.

On Thu, Feb 9, 2017 at 1:49 PM, Xiaohan Wang (王消寒) <__...@chromium.org> wrote:

Recently it seems pretty hard to use "git cl land" to land changes. When I use it, most of time I'll get an error like the following, even after I just synced. This happened to me on trunk and release branches:

error: failed to push some refs to 'https://chromium.googlesource.com/chromium/src.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
Failed to push. If this persists, please file a bug.

Clicking the CQ box in the CL on release branches seems to work (I do need "NOTRY=true"), even though the documentation recommend against it.

So what's the best way of land CLs manually now?

Best,

Xiaohan

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

[Aaron Gable]

+Andrii Shyshkalov 

This has become more prevalent due to the change in how git-cl and Cr-Commit-Position numbers interact. It used to be that git-cl would create an invisible ref, copy your change there, and push it (rebasing and retrying multiple times if necessary) to the "pending ref" so that the Git Number Daemon could add the Cr-Commit-Position footer. Now that Gerrit itself does that last step, git-cl just pushes your actual commit directly to master and lets all the magic happen there. This means that git-cl has lost its "rapid rebase and retry" logic/loop, and so failures to push like this are more common.

Andrii: we thought this might happen, but that it wouldn't be a problem. Seems like it is a bigger problem than we though. You should add the rebase+retry loop back to git-cl somehow.

Aaron

--
You received this message because you are subscribed to the Google Groups "infra-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to infra-dev+...@chromium.org.
To post to this group, send email to infr...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/infra-dev/CAATLsPZKsUqNy6NxjKGA8vjmHCNiwmPO2EjzrZ47hA5BzX7bqw%40mail.gmail.com.

[Andrii Shyshkalov]

Sorry, I missed this email before. As Aaron said, I filed a bug http://crbug.com/682934 but at the time we decided against spending time on it.

On Fri, Feb 10, 2017 at 7:09 PM Aaron Gable <aga...@chromium.org> wrote:

+Andrii Shyshkalov 

This has become more prevalent due to the change in how git-cl and Cr-Commit-Position numbers interact. It used to be that git-cl would create an invisible ref, copy your change there, and push it (rebasing and retrying multiple times if necessary) to the "pending ref" so that the Git Number Daemon could add the Cr-Commit-Position footer.

 

Now that Gerrit itself does that last step, git-cl just pushes your actual commit directly to master and lets all the magic happen there.

Correction: for Rietveld CLs, Gerrit doesn't generate Cr-Commit-Position numbers. git cl does it on the fly and pushes already correct commit description to the master.

This means that git-cl has lost its "rapid rebase and retry" logic/loop, and so failures to push like this are more common. 

TBH, I deleted that loop together with prior "refs/pending" logic, because refactoring that loop into non-refs/pending flow was substantial work, and in fact that's what http://crbug.com/682934 is asking for.

[Scott Hess]

On Wed, Mar 22, 2017 at 10:02 AM, Andrii Shyshkalov <tan...@chromium.org> wrote:

On Fri, Feb 10, 2017 at 7:09 PM Aaron Gable <aga...@chromium.org> wrote:

This means that git-cl has lost its "rapid rebase and retry" logic/loop, and so failures to push like this are more common. 

TBH, I deleted that loop together with prior "refs/pending" logic, because refactoring that loop into non-refs/pending flow was substantial work, and in fact that's what http://crbug.com/682934 is asking for.

Protip from a recent manual land:

git fetch origin && git rebase origin/master && git cl land

It is a little less convenient, but I will admit that with the previous automatic-retry logic, I often wondered whether what was going on behind the scenes was going to end well.  Based on my past experiences scripting git.

-scott