git-subrepo: Command failed: 'git rev-parse FETCH_HEAD^0'.

[ktomk]

Here is another one that does not work with git:

$ git subrepo fetch shared
git-subrepo: Command failed: 'git rev-parse FETCH_HEAD^0'.

I was on master and tried issue/142 as well.

When I visit the repository (I have it on disk) and try the command there I get:

$ git rev-parse FETCH_HEAD^0
8e616f79c946eb04ea4f3c8e4061b586c8f9f16d

Which looks great. Immediatly switching back to the other directory:

 $ git rev-parse FETCH_HEAD^0
FETCH_HEAD^0
fatal: ambiguous argument 'FETCH_HEAD^0': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'

My subrepo is a local directory (non-bare git repo) with a relative pathname to remote.

I might not be that responsive the next days, but I'll catch up when I'm online again.

[grimmySwe]

FETCH_HEAD is a short lived reference created by the git fetch. So moving between repositories will reference different FETCH_HEADs.

Can you run git subrepo -v -d fetch shared that will output some verbose and debug information.
I will try to reproduce it but haven't succeeded yet.

[grimmySwe]

From the code:

  o "Fetch '$subrepo_remote' ($subrepo_branch)."
  RUN git fetch --quiet "$subrepo_remote" "$subrepo_branch"
  OK || return

  o "Get the upstream subrepo HEAD commit."
  OUT=true RUN git rev-parse FETCH_HEAD^0

For this to fail something needs to happen in the git fetch step that aren't considered an error.

[ktomk]

Output of the verbose command:

$ git subrepo -v -d fetch shared
>>> git rev-parse --verify HEAD
* Fetch '../mr-shared' (master).
>>> git fetch --quiet ../mr-shared master
* Get the upstream subrepo HEAD commit.
>>> git rev-parse FETCH_HEAD^0
git-subrepo: Command failed: 'git rev-parse FETCH_HEAD^0'.

Removing the --quiet switch in the code does not give more output.

[grimmySwe]

I can't reproduce this so I will need some more input:

1. What version of git are you running?
2. Do you have other subrepos that work?
   If yes: is there something special about this subrepo?
   If no: Can you create an example and see if you can reproduce it?
3. Are the repos public so I can try it out myself?

[ktomk]

1. What version of git are you running?

$ git --version
git version 1.9.1

1. Do you have other subrepos that work?

No, this is my first project with a sub-repo

1. Are the repos public so I can try it out myself?

Not yet, right now I use a local repository as shared. If you can give me a hint on how I can change (the remote URL?) from local (file) to Github (http/ssh) I can easily share this. This might be worth to do anyway, b/c I have the feeling there might be an issue because of using a local, relative remote URL.

[ktomk]

Just as additional information, this is how in one of the subrepo-using repositories has the remotes configured:

$ git remote -v
origin  git@github.com:netz98/n98-magerun2 (fetch)
origin  git@github.com:netz98/n98-magerun2 (push)
private git@github.com:ktomk/n98-magerun2.git (fetch)
private git@github.com:ktomk/n98-magerun2.git (push)
subrepo/shared  ../mr-shared (fetch)
subrepo/shared  ../mr-shared (push)

As you can see, this is partially public already, I've just started to play around with subrepos.

[ktomk]

I switched the repository URL from "../mr-shared" to "git@github.com:ktomk/mr-shared" and I don't see the error any longer. Changing it back to the relative URL brings back the error.

As the local repository is non-bare I would assume this is just not compatible with git subrepo. I also had errors earlier (due to having a branch checked out) for which I could workaround but now with this finding, I should just accept it's not practicable with a non-bare repository. It might even be that I over-read this in the existing docs.

[ktomk]

To verify this assumption I create a local bare repository via:

$ git clone --mirror  "git@github.com:ktomk/mr-shared"

and changed the remote to it:

../../bares/mr-shared.git

The error is still gone so this is another indication that git subrepo works with bare repositories as remotes.

[grimmySwe]

@ktomk Closing this issue, please reopen and add more information to work with for further investigation.

[ktomk]

@grimmySwe: I think all is fine, it's just that I was unaware in the beginning that the remote repository must be a bare repository.