Stuck on push after pushed to another remote url: "There are new changes upstream, you need to pull first."

[jcalfee]

I recently successfully pushed this subrepo to a different remote url ("$prod"). Now I'm trying to come back to the original URL ("$origin") and push there to update that repository as well.

# This is what I need to do:
$ git subrepo push --remote=$origin $repo
git-subrepo: There are new changes upstream, you need to pull first.

# Just to show the details:
$ git subrepo pull --remote=$origin $repo
git-subrepo: Local repository does not contain de7e6f8f329b649a1049c8578cf89bee3744bbc1. Try to 'git subrepo fetch $repo' or add the '-F' flag to always fetch the latest content.

# Because the last push was $prod, the local repo **does** contain the commit changes, but the hash is different.
# In other words: $origin does not have this hash, but $prod does.  So, attempting to pull from $prod seams to work:
$ git subrepo pull --remote=$prod $repo
Subrepo '$repo' is up to date.
$ git subrepo fetch --remote=$prod $repo
Fetched '$repo' from '$prod' (master).

# Just for good measure:
$ git subrepo pull --remote=$origin $repo
git-subrepo: Local repository does not contain de7e6f8f329b649a1049c8578cf89bee3744bbc1. Try to 'git subrepo fetch $repo' or add the '-F' flag to always fetch the latest content.
$ git subrepo fetch --remote=$origin $repo
Fetched '$repo' from '$origin' (master).

# And I'll retry the desired command:
$ git subrepo push --remote=$origin $repo
git-subrepo: There are new changes upstream, you need to pull first.

I did push to a different remote and now I'm coming back to the original upstream. The default method is rebase. Possibly related #541 (comment), but I did not do any cherry picking or force push and clean did not change anything.

[jcalfee]

I already tried the -F above (fetch). Why does force push not disable this check? ("Local repository does not contain de7e6f8")

$ git subrepo push $repo -r "$origin" --force
git-subrepo: Local repository does not contain de7e6f8f329b649a1049c8578cf89bee3744bbc1. Try to 'git subrepo fetch $repo' or add the '-F' flag to always fetch the latest content.

If I can't save it, I believe I recall correctly: I can delete $repo/.gitrepo, commit that delete, then use git subrepo init to recreate the repo and push it to the correct place, then not try this again.

[admorgan]

The create a commit on push is feeling more like an anit-feature to me. The reason it behaves that way makes sense, it makes future operations faster, but I use a lot of services such as Gerrit where the pushed patch doesn't just go into a repo, it gets reviewed and updated so it doesn't contain the same SHA. This breaks the interaction. Also doing a git subrepo pull after a push would accomplish the same goal. I have been sitting on it because it is a big change to how things work. I think your use case makes my case stronger. I will make a patch for removing the push commit to the next released version.