Problems with git fetch confusing foo and foo.git repos

A while ago I reported a problem[1] where having:

/somewhere/foo
and
/somewhere/foo.git

as bare repositories and trying to clone them using alternates could
cause git to confuse them.

The "conclusion" was that I needed to do:

git clone -s -n /somewhere/foo/ x

to stop it looking at the .git version. Ok, fine. Ugly but I can live
with it and we added the workaround[2].

I've now discovered we only half solved the problem. Whilst the
alternates might get setup correctly, the branch names and revisions get
fetched from the .git version still.

It appears that even if you have a repository setup with an origin url
of "/somewhere/foo/", when you run git fetch origin -f  refs/*:refs/*,
it will look at foo.git if it exists.

The problem is the trailing slash is stripped off by the code in
git-fetch itself. It appears to have done this since it was converted
from a .sh function. It means it appears impossible to fetch the
branchnames/revisions from foo when foo.git exists.

I work with build systems that build complete linux systems and we're
running into failures caused by this. I really need pre-existing
versions of git to work so I can't even patch git to work around the
problem without significant cost. So far the only way I've figured out
to avoid this is to create a symlink to /somewhere/foo/ and then set url
to point at the symlink. This way I can prevent it from finding the
other directory.

I thought I'd mention this in the hopes git can be fixed to behave
better in this situation and perhaps I can drop the hacks I'm going to
have to add sometime in the future.

If anyone has any ideas for better workarounds I'd love to hear about
them...

[1] "Alternates corruption issue", 2012/1/31
[2] http://git.yoctoproject.org/cgit.cgi/poky/commit/bitbake/lib/bb/fetch2/git.py?id=64662290d3e7deb0b6093b3959c3f3eddb873893

Cheers,

Richard

On Sat, 2012-08-18 at 15:25 +0100, Richard Purdie wrote:

A while ago I reported a problem[1] where having:

/somewhere/foo
and
/somewhere/foo.git

as bare repositories and trying to clone them using alternates could
cause git to confuse them.

The "conclusion" was that I needed to do:

git clone -s -n /somewhere/foo/ x

to stop it looking at the .git version. Ok, fine. Ugly but I can live
with it and we added the workaround[2].

I've now discovered we only half solved the problem. Whilst the
alternates might get setup correctly, the branch names and revisions get
fetched from the .git version still.

It appears that even if you have a repository setup with an origin url
of "/somewhere/foo/", when you run git fetch origin -f  refs/*:refs/*,
it will look at foo.git if it exists.

The problem is the trailing slash is stripped off by the code in
git-fetch itself. It appears to have done this since it was converted
from a .sh function. It means it appears impossible to fetch the
branchnames/revisions from foo when foo.git exists.

I work with build systems that build complete linux systems and we're
running into failures caused by this. I really need pre-existing
versions of git to work so I can't even patch git to work around the
problem without significant cost. So far the only way I've figured out
to avoid this is to create a symlink to /somewhere/foo/ and then set url
to point at the symlink. This way I can prevent it from finding the
other directory.

I thought I'd mention this in the hopes git can be fixed to behave
better in this situation and perhaps I can drop the hacks I'm going to
have to add sometime in the future.

I'd add that I think the commit made for the original problem[1] has
fixed this scenario since it now will prefer foo over foo.git also in
the fetch case even if the / is removed from the url. My test machines
don't have that version yet though and I'm left with a problem where git
is older than 1.7.9.2. 

[1]http://git.kernel.org/?p=git/git.git;a=commit;h=b3256eb8b35937192e85725d0c2bcb422295790c

Cheers,

Richard