Older versions ( at least, 2.3.40-r1 is "good" ) synchronized repos using git pull The current version for some reason is trying to execute git fetch remotes However, the syntax for git fetch takes a specific remote name. And there are no remotes called "remotes" >>> Syncing repository 'gentoo' into '/usr/portage'... /usr/bin/git fetch remotes fatal: 'remotes' does not appear to be a git repository fatal: Could not read from remote repository. Its likely that portage is confused by there being multiple remotes, and having no idea which ones to fetch. [remote "origin"] url = https://github.com/gentoo/gentoo.git fetch = +refs/heads/master:refs/remotes/heads/master [branch "master"] remote = origin merge = refs/heads/master [pull] rebase = true [remote "gentoo-perl"] url = https://github.com/gentoo-perl/gentoo.git fetch = +refs/heads/*:refs/remotes/gentoo-perl/* However, whatever the cause, as of 2.3.49, "emerge --sync" is entirely broken for me.
The input for the git fetch comes from this command: git rev-parse --abbrev-ref --symbolic-full-name '@{upstream}' So apparently it's outputing remotes/something.
(In reply to Zac Medico from comment #1) > The input for the git fetch comes from this command: > > git rev-parse --abbrev-ref --symbolic-full-name '@{upstream}' > > So apparently it's outputing remotes/something. git rev-parse --abbrev-ref --symbolic-full-name '@{upstream}' remotes/heads/master
For the purposes of bug 660372, the goal of the git rev-parse command is to identify the remote corresponding the upstream of the current branch. Are you aware of some way that we can do that in your checkout?
(In reply to Zac Medico from comment #3) > For the purposes of bug 660372, the goal of the git rev-parse command is to > identify the remote corresponding the upstream of the current branch. Are > you aware of some way that we can do that in your checkout? I'm not sure there is such a way that's reliable, other than trusting git. ( for instance, there may not *be* a corresponding remote upstream ) Other than that, the data seems clear: branch.master.remote=origin branch.master.merge=refs/heads/master and refs/heads/master is from remote.origin
I guess the problem is you're relying on the convention that remotes are often provided via the syntax: remotes/${remotename}/heads/* But its just that, a convention. Git configuration drives the actual mechanics. As for why its in a different place, I don't know why that is here. I just know it is, and I suspect some 3rd party stuff by hasufel made it that way. But all the same, you really shouldn't rely on that convention.
Maybe this can serve as a general approach: LOCAL_BRANCH=$(git name-rev --name-only HEAD) REMOTE_BRANCH=$(git config branch.${LOCAL_BRANCH}.merge) REMOTE_NAME=$(git config branch.${LOCAL_BRANCH}.remote) REMOTE_BRANCH_REF="refs/remotes/${REMOTE_NAME}/${REMOTE_BRANCH#refs/heads/}" git fetch "${REMOTE_NAME}" # Before merge, check signature of ${REMOTE_BRANCH_REF} and abort if necessary git merge "${REMOTE_BRANCH_REF}"
(In reply to Zac Medico from comment #6) > REMOTE_BRANCH_REF="refs/remotes/${REMOTE_NAME}/${REMOTE_BRANCH#refs/heads/}" Can you explain what this logic is here? I don't see why you're doing substitution with the "refs/heads" thing. Also, just realised something extra odd with my config: [branch "master"] remote = origin merge = refs/heads/master Clearly, that's saying "my upstream is myself", due to the absence of "remotes" in the "merge = " target. So either I've misunderstood the documentation, or something else is potentially out of whack with my config ( though it really shouldn't affect anything you're doing )
(In reply to Kent Fredric (IRC: kent\n) from comment #7) > (In reply to Zac Medico from comment #6) > > REMOTE_BRANCH_REF="refs/remotes/${REMOTE_NAME}/${REMOTE_BRANCH#refs/heads/}" > > Can you explain what this logic is here? I don't see why you're doing > substitution > with the "refs/heads" thing. > > Also, just realised something extra odd with my config: > > > [branch "master"] > remote = origin > merge = refs/heads/master > > Clearly, that's saying "my upstream is myself", due to the absence of > "remotes" in the "merge = " target. Yeah "my upstream is myself" makes no sense, so I assume it means, "my upstream is refs/remotes/origin/master". This is the remote branch value based on my assumption: REMOTE_BRANCH_REF="refs/remotes/${REMOTE_NAME}/${REMOTE_BRANCH#refs/heads/}"
(In reply to Zac Medico from comment #8) > The value is handled like the remote part of a refspec, and must match a ref > which is fetched from the remote given by "branch.<name>.remote" I'm guessing this means there's some magic inside and it matches that against the *left* side of the "fetch = " stanza in "remote.origin", and then conjugates where it is stored. Just have to working out how to verify this assumption and get git to expose data when <src>:<dest> don't share a basename.
