Broken after pushing directly into subrepo

[Wandalen]

After pushing changes directly into subrepo
I'm trying to push

git subrepo push --all

And get only this

git-subrepo: Can't commit: 'subrepo/x' doesn't contain upstream HEAD:

Clean does not help :(
Any help?

[Wandalen]

Similar problem: #562

[admorgan]

This is likely to be a game of 21 questions, so I apologize in advance. First if you run git subrepo pull what is the result?

[djova-dolby]

I have the same issue. git subrepo pull will pull the latest changes properly, updating the .gitrepo file. But no matter what I cannot push the new changes getting this doesn't contain upstream HEAD issue.
I have tried fetching, cleaning, I have not tried deleting and recloning. I have git-subrepo 0.4.5.

[djova-dolby]

When I perform the pull it gets the latest changes from some "main" branch, I then am trying to push to a different branch which was created off of this "main" to accept the changes which were made in my repo which contains this subrepo.

[djova-dolby]

After removing the subrepo directory, cloning, fixing the parent hash in subrepo/.gitrepo file I was able to push my changes. But I am still unsure of what the actual issue was.

[djova-dolby]

But after this clone, when I revert things in my repo so I don't have this clonage history and just do a force pull of the "main" branch things seem to be back to normal. Like I am able to push without doing all these gymnastics. So it seems the deletion of the subrepo and then clone got things back on track.

[djova-dolby]

Nevermind, my apologies for the spam. I found the issue. Not an issue with gitsubrepo at all.
If it concerns anyone:

• I had a commit to the subrepo from my repo that I overlooked
• The upstream subrepo changed in the meantime, so pulling changes and then trying to push new changes caused an issue
• Doing force/pull or clone obviously worked because it got rid of these changes I had in my version of the subrepo
• Creating a branch in upstream subrepo which was at the previous commit hash in my subrepo/.gitrepo file, pushing my new changes atop of this, rebasing this upstream subrepo atop of main and force pulling got things back on track.
  Again my apologies for spamming.

[admorgan]

@djova-dolby this isn't spam, it is the honest musings of someone that is encountering unexpected behavior and is valuable. Just because it didn't end up being the same problem doesn't make it less valuable. It looks to me that the messages about being on the latest version of upstream were not effective and I would like some feedback as to what would have worked better to ensure the correct action of doing a non force pull then push would have made this experience more obvious..

I personally like your solution of branching to get your change upstream then fixing it there, it was creative. Maybe we should add something to the error message about that being a viable solution.

[Wandalen]

That's possible reason behind my problem is the same.

[Wandalen]

I have
MainRepo having SubRepo
One developer commits everything into MainRepo, and that work
Another developer can commit only to SubRepo
And after an attempt to pull changes from SubRepo problem happened.

Like for example, here:

-

Both screenshots represent SubRepo
But the second one after actually forcing push.
Because of some reason, it overwrote history :(
But without force, it didn't work. Clean didn't help at all.

I have

method = merge
git config --global pull.rebase false

So, I have no idea how history was rewritten.

Probably I misuse it ..?

[Wandalen]

I used command

git subrepo clean --all ; git subrepo pull --all ; git subrepo push --all

[djova-dolby]

@admorgan to be honest I am not sure what message improvement could have helped me find the problem sooner. The upstream subrepo we use only allows pushing rebased. So like once I realized I had a commit which was not upstreamed before new changes were pushed to the upstream subrepo it was clear where the problem lay.

However maybe something like when you perform the git-subrepo pull some message indicating that you have locally non-upstreamed commits for that subrepo? Not sure how feasible this is though.

And please note I am by no means an advanced git-subrepo user, for a while I was just copy-pasting commands to upstream/pull subrepo changes. Only when I started to run into issues did I start to think about how things actually worked.

[admorgan]

I think this may be fixed by #614