"git cl land" errors

[Xiaohan Wang (王消寒)]

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

[Jeremy Roman]

Isn't "git drover" the recommended way to merge to release branches?

http://commondatastorage.googleapis.com/chrome-infra-docs/flat/depot_tools/docs/html/git-drover.html

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

[Xiaohan Wang (王消寒)]

Yes, but I made a merge error so I had to work on the branch directly.

Also, I think I got similar error when I use "git drover":

Failed to push. If this persists, please file a bug.

Error: Command 'cl land --bypass-hooks' failed: Command '['git', 'cl', 'land', '--bypass-hooks']' returned non-zero exit status 1

[Jeremy Roman]

Assuming you had also done "gclient sync --with_branch_heads", I'm out of ideas. :(

[Ken Rockot]

Maybe I'm stating the obvious, but the only ever time I've seen that message is when my local checkout is not up to date with the remote branch head, and pulling+rebasing/merging has always resolved it.

[Ken Rockot]

Oh, nevermind - now I see "even after I just synced"... Uh. Yeah. *disappears*

[Tommy Nyquist]

Could your .gclient file happen to have some pinned revision of a specific repository by any chance? Or that there's a config somewhere in a DEPS file you've checked out that pins src/ ? I don't know how that would affect release branches though.

[Xianzhu Wang]

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'.

--

[Varun]

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'.

[Paweł Hajdan, Jr.]

+infra-dev

[Kai]

I had this issue as well. I was able to fix it by removing a broken cookie from .gitcookies. I think you'll probably have to remove the cookie and then set it up again. (see instructions on landing changes to release branches)

[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