Git-subrepo: fatal: Not a valid object name: ''.

[brianjmurrell]

So, per #345 and #346 I'm trying some pretty simple workflows with release/0.4.0 and still seem to still be running into some problems.

I did a git subrep clone with 0.4.0 and then subsequently the subrepo I cloned got a new commit pushed to it so I thought it would be simple to get that new code into my subrepo:

$ git subrepo -v pull include
* Assert that working copy is clean: /home/brian/iml/python-django
* Check for worktree with branch subrepo/include
  * Fetch the upstream: [email protected]:intel-hpdd/module-tools.git (master).
  * Get the upstream subrepo HEAD commit.
  * Create ref 'refs/subrepo/include/fetch'.
* Deleting old 'subrepo/include' branch.
* Remove worktree: 
* Create subrepo branch 'subrepo/include'.
  * Check if the 'subrepo/include' branch already exists.
  * Subrepo parent: d9025bcbee964fa14385a69d83f3986e29964105
  * Create new commits with parents into the subrepo fetch
  * Create branch 'subrepo/include' for this new commit set .
git-subrepo: Command failed: 'git branch subrepo/include '.
fatal: Not a valid object name: ''.

But as you can see, not so much. What am I doing wrong?

[grimmySwe]

From the log it looks like you don't get any commits to work on. Most probable cause is that the git rev-list --reverse --ancestry-path "$subrepo_parent..HEAD" command returns an empty list.

Can you try to git rev-list --reverse --ancestry-path d9025bcbee964fa14385a69d83f3986e29964105..HEAD in your main repo for the current branch?

It can be a fact that you have done some rebase that the d9025bcbee964fa14385a69d83f3986e29964105 is no longer part of your current history.

If that is the case, you might need to reclone the subrepo if you have no local changes.

I have a work in progress branch where there is a "-s" squash flag for this case, then you ignore previous history and only care about the last parent.

[brianjmurrell]

Ahh. So to be clear, I cannot rebase (i.e. and reorder patches) once I have done the git subrepo clone such that the hash of the subrepo commit changes.

Of course that makes total sense now that I say it out loud.

I'll keep this in mind in the future and just make I do my subrepo clone operation where I need it in the order of commits.

So to correct this I need to rm -rf include/; git subrepo clone ... include? Or should I git rm include/ before I redo the git subrepo clone? Or something else?

[grimmySwe]

In the .gitrepo file we store the previous parent hash, if that hash doesn't exist we don't have anything to work with.

As you say, you need to pay a little attention to this when/if you rebase.

[vjpr]

@grimmySwe Should add a check after git rev-list --reverse --ancestry-path to let the user know about possible fixes. I just ran into this.

---

Just including this for my understanding of the problem:

So in subdir/.gitrepo,

• commit points to the latest commit in the subrepo "split" branch (this branch contains all commits that modified something in subdir).
• parent points to the HEAD of the repo before git subrepo push was run.

If you git subrepo push on a dev branch, then master changes, then you do git rebase master, the hash in subdir/.gitrepo#parent will be have been rewritten.

And when subrepo tries to get the commits since you last scanned your commit history for subdir-modifying commits, it will fail because the parent is non-existent (because it was rewritten).

Error like so:

>>> git rev-list --reverse --ancestry-path 342f6f319c07ecf843c8a84064f6fa1d92a35d0b..HEAD
  * Create branch 'subrepo/packages/public' for this new commit set .
>>> git branch subrepo/packages/public
git-subrepo: Command failed: 'git branch subrepo/packages/public '.
fatal: Not a valid object name: ''.

Easy way out

The easy way out is to delete subdir/.gitrepo, and run git subrepo init ... again, and then git subrepo push --force --remote <REMOTE>.

What if my subrepo remote is shared and others have made changes to it?

I don't know how to recover from this. Maybe @grimmySwe has an idea?

If, before we did git checkout dev; git rebase master, master introduced a change to a file in subdir, we need to make sure that subrepo finds this. So parent would have to be at least set to that I guess. But then we would be duplicated any commits that we had in our dev branch that are already in the subtree branch.

[dperetti]

I just fixed the problem like this:

1. Usegit reflog to find the most recent "rebase commit".
2. Set the parent in .gitrepoto that commit.