ingydotnet / git-subrepo

MIT License
3.27k stars 270 forks source link

subrepo clean, pull: Command failed: 'git rev-list --reverse --ancestry-path --topo-order #524

Open bbros-dev opened 3 years ago

bbros-dev commented 3 years ago

Thank you again for all the effort put into such a great tool and for making this opensource.

$ git subrepo pull -vd developer-cookbooks/hashicorp                                        [2/89]
>>> git rev-parse --verify HEAD
* Assert that working copy is clean: /home/hedge/chef
* Check for worktree with branch subrepo/developer-cookbooks/hashicorp
  * Fetch the upstream: https://github.com/bbros-dev/hashicorp.chef (main).
>>> git fetch --no-tags --quiet https://github.com/bbros-dev/hashicorp.chef main
  * Get the upstream subrepo HEAD commit.
>>> git rev-parse FETCH_HEAD^0
  * Create ref 'refs/subrepo/developer-cookbooks/hashicorp/fetch'.
>>> git update-ref refs/subrepo/developer-cookbooks/hashicorp/fetch 34651fcb9ee093850f5371f74e850d42f7a5
4b82
* Deleting old 'subrepo/developer-cookbooks/hashicorp' branch.
* Remove worktree:
>>> git branch -D subrepo/developer-cookbooks/hashicorp
* Create subrepo branch 'subrepo/developer-cookbooks/hashicorp'.
  * Check if the 'subrepo/developer-cookbooks/hashicorp' branch already exists.
  * Subrepo parent: 433e7b5a4db57965af8feb1035d7ff416cbb3ddc
  * Create new commits with parents into the subrepo fetch
>>> git rev-list --reverse --ancestry-path --topo-order 433e7b5a4db57965af8feb1035d7ff416cbb3ddc..HEAD
git-subrepo: Command failed: 'git rev-list --reverse --ancestry-path --topo-order 433e7b5a4db57965af8feb
1035d7ff416cbb3ddc..HEAD'.

Cleaning does not seem to help:

$ git subrepo clean -vd developer-cookbooks/hashicorp 
>>> git rev-parse --verify HEAD
* Check for worktree with branch subrepo/developer-cookbooks/hashicorp
* Clean developer-cookbooks/hashicorp
* Remove worktree: .git/tmp/subrepo/developer-cookbooks/hashicorp

We see the same error again:

$ git subrepo pull -vd developer-cookbooks/hashicorp
>>> git rev-parse --verify HEAD
* Assert that working copy is clean: /home/hedge/chef
* Check for worktree with branch subrepo/developer-cookbooks/hashicorp  * Fetch the upstream: https://github.com/bbros-dev/hashicorp.chef (main).
>>> git fetch --no-tags --quiet https://github.com/bbros-dev/hashicorp.chef main
  * Get the upstream subrepo HEAD commit.
>>> git rev-parse FETCH_HEAD^0
  * Create ref 'refs/subrepo/developer-cookbooks/hashicorp/fetch'.
>>> git update-ref refs/subrepo/developer-cookbooks/hashicorp/fetch 34651fcb9ee093850f5371f74e850d42f7a54b82
* Deleting old 'subrepo/developer-cookbooks/hashicorp' branch.
* Remove worktree:
>>> git branch -D subrepo/developer-cookbooks/hashicorp* Create subrepo branch 'subrepo/developer-cookbooks/hashicorp'.
  * Check if the 'subrepo/developer-cookbooks/hashicorp' branch already exists.
  * Subrepo parent: 433e7b5a4db57965af8feb1035d7ff416cbb3ddc
  * Create new commits with parents into the subrepo fetch
>>> git rev-list --reverse --ancestry-path --topo-order 433e7b5a4db57965af8feb1035d7ff416cbb3ddc..HEAD
git-subrepo: Command failed: 'git rev-list --reverse --ancestry-path --topo-order 433e7b5a4db57965af8feb1035d7ff416cbb3ddc..HEAD'.
admorgan commented 3 years ago

Please verify that the SHA in the parent entry in your .gitrepo file exists. This is usually caused by a rebase or a squash merge and the parent no longer points to a valid SHA.

jonatansberg commented 3 years ago

@admorgan We have the exact same issue and it seems to be caused by and upstream rebase or squash. Whats the best way to recover from that in the downstream repo? (cc @alfredringstad)

admorgan commented 3 years ago

If the parent repo no longer has the SHA in commit entry in the .gitrepo the only thing you can do is a forced pull (otherwise known as a clone). Unfortunately this will loose any local changes you have to those files.

jonatansberg commented 3 years ago

Thank you for replying @admorgan! I'm not familiar enough with subrepos and git internals to see how, but surely there must be some kind of way to preserve those changes?

Loosing your local changes and/or history due to external factors that are potentially outside of your control seems very unfortunate, and makes wider adoption much much harder.

admorgan commented 3 years ago

Unfortunately this is caused by the upstream. Git is really cranky when someone rewrites the history out from underneath it. Git is basically a block chain of changes to the source. Everyone has to agree to what the history is or no one what the truth is.

You basically have to reset what the new truth is.

I see two options in this situation

  1. If you need the individual changes a. git subrepo branch b. clone that branch into another repo c. git subrepo clone -f d. cherry-pick commits from branch repo on top of new history
  2. If you don't need individual changes a. git subrepo branch b. cd into branch dir c. git fetch external repo info d. merge external repo into branch e. git subrepo commit

With option one if you were to push to the upstream repo you would get individual commits just like normal. With option two if you were to push to the upstream repo you would get a single squashed commit with all local changes.

No matter what someone up stream broke the rules of public repos and you should consider if they are good source in the future.

loganpowell commented 7 months ago

👋 (thank you for putting this together and I'm really hoping it can scratch the itch we have)

I'm having this issue on a brand new repo stubbed out with subrepos. After working on the subrepos and the main repo for a while (solo, i.e., no other contributors and no other commits other than the ones I made myself through the downstream repo). I'm getting the same error

git-subrepo: Command failed: 'git rev-list --reverse --ancestry-path --topo-order 1be6235e20e48f6baa913013076e46d7938c2b1b..HEAD'.

I really don't want to loose all the work I've done in the subrepo directory since I stubbed out the subrepo. Is there any other workaround?

Btw, is there a preferred workflow for doing most of the work in the downstream repo and just pushing to the upstreams?