{"thread":{"id":"31278","subject":"Problems with git fetch confusing foo and foo.git repos","startedAt":"2012-08-18T14:25:04Z","lastAt":"2012-08-18T22:06:05Z","messageCount":4,"participants":["Richard Purdie","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"197239","messageId":"1345299904.27428.50.camel@ted","threadId":"31278","inReplyTo":null,"subject":"Problems with git fetch confusing foo and foo.git repos","fromName":"Richard Purdie","fromEmail":"richard.purdie@linuxfoundation.org","sentAt":"2012-08-18T14:25:04Z","receivedAt":"2012-08-18T14:25:04Z","isPatch":false,"sender":{"key":"richard.purdie@linuxfoundation.org","avatar":null},"body":"A while ago I reported a problem[1] where having:\n\n/somewhere/foo\nand\n/somewhere/foo.git\n\nas bare repositories and trying to clone them using alternates could\ncause git to confuse them.\n\nThe \"conclusion\" was that I needed to do:\n\ngit clone -s -n /somewhere/foo/ x\n\nto stop it looking at the .git version. Ok, fine. Ugly but I can live\nwith it and we added the workaround[2].\n\nI've now discovered we only half solved the problem. Whilst the\nalternates might get setup correctly, the branch names and revisions get\nfetched from the .git version still.\n\nIt appears that even if you have a repository setup with an origin url\nof \"/somewhere/foo/\", when you run git fetch origin -f  refs/*:refs/*,\nit will look at foo.git if it exists.\n\nThe problem is the trailing slash is stripped off by the code in\ngit-fetch itself. It appears to have done this since it was converted\nfrom a .sh function. It means it appears impossible to fetch the\nbranchnames/revisions from foo when foo.git exists.\n\nI work with build systems that build complete linux systems and we're\nrunning into failures caused by this. I really need pre-existing\nversions of git to work so I can't even patch git to work around the\nproblem without significant cost. So far the only way I've figured out\nto avoid this is to create a symlink to /somewhere/foo/ and then set url\nto point at the symlink. This way I can prevent it from finding the\nother directory.\n\nI thought I'd mention this in the hopes git can be fixed to behave\nbetter in this situation and perhaps I can drop the hacks I'm going to\nhave to add sometime in the future.\n\nIf anyone has any ideas for better workarounds I'd love to hear about\nthem...\n\n[1] \"Alternates corruption issue\", 2012/1/31\n[2] http://git.yoctoproject.org/cgit.cgi/poky/commit/bitbake/lib/bb/fetch2/git.py?id=64662290d3e7deb0b6093b3959c3f3eddb873893\n\nCheers,\n\nRichard\n"},{"id":"197241","messageId":"1345301383.27428.55.camel@ted","threadId":"31278","inReplyTo":"1345299904.27428.50.camel@ted","subject":"Re: Problems with git fetch confusing foo and foo.git repos","fromName":"Richard Purdie","fromEmail":"richard.purdie@linuxfoundation.org","sentAt":"2012-08-18T14:49:43Z","receivedAt":"2012-08-18T14:49:43Z","isPatch":false,"sender":{"key":"richard.purdie@linuxfoundation.org","avatar":null},"body":"On Sat, 2012-08-18 at 15:25 +0100, Richard Purdie wrote:\n> A while ago I reported a problem[1] where having:\n> \n> /somewhere/foo\n> and\n> /somewhere/foo.git\n> \n> as bare repositories and trying to clone them using alternates could\n> cause git to confuse them.\n> \n> The \"conclusion\" was that I needed to do:\n> \n> git clone -s -n /somewhere/foo/ x\n> \n> to stop it looking at the .git version. Ok, fine. Ugly but I can live\n> with it and we added the workaround[2].\n> \n> I've now discovered we only half solved the problem. Whilst the\n> alternates might get setup correctly, the branch names and revisions get\n> fetched from the .git version still.\n> \n> It appears that even if you have a repository setup with an origin url\n> of \"/somewhere/foo/\", when you run git fetch origin -f  refs/*:refs/*,\n> it will look at foo.git if it exists.\n> \n> The problem is the trailing slash is stripped off by the code in\n> git-fetch itself. It appears to have done this since it was converted\n> from a .sh function. It means it appears impossible to fetch the\n> branchnames/revisions from foo when foo.git exists.\n> \n> I work with build systems that build complete linux systems and we're\n> running into failures caused by this. I really need pre-existing\n> versions of git to work so I can't even patch git to work around the\n> problem without significant cost. So far the only way I've figured out\n> to avoid this is to create a symlink to /somewhere/foo/ and then set url\n> to point at the symlink. This way I can prevent it from finding the\n> other directory.\n> \n> I thought I'd mention this in the hopes git can be fixed to behave\n> better in this situation and perhaps I can drop the hacks I'm going to\n> have to add sometime in the future.\n\nI'd add that I think the commit made for the original problem[1] has\nfixed this scenario since it now will prefer foo over foo.git also in\nthe fetch case even if the / is removed from the url. My test machines\ndon't have that version yet though and I'm left with a problem where git\nis older than 1.7.9.2. \n\n[1]http://git.kernel.org/?p=git/git.git;a=commit;h=b3256eb8b35937192e85725d0c2bcb422295790c\n\nCheers,\n\nRichard\n"},{"id":"197260","messageId":"7vk3wwrlc9.fsf@alter.siamese.dyndns.org","threadId":"31278","inReplyTo":"1345301383.27428.55.camel@ted","subject":"Re: Problems with git fetch confusing foo and foo.git repos","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-08-18T20:33:58Z","receivedAt":"2012-08-18T20:33:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Richard Purdie <richard.purdie@linuxfoundation.org> writes:\n\n> I'd add that I think the commit made for the original problem[1] has\n> fixed this scenario since it now will prefer foo over foo.git also in\n> the fetch case even if the / is removed from the url.\n\nOK.\n\nAs understand it, these \"check various possibilities e.g. $name,\n$name.git $name/.git\" were never meant to be a way to encourage\nusers to have multiple repositories next to each other under\nconfusing names in the first place.  It was merely to allow users to\nhave one of them (some may prefer $name/ that is with working tree,\nso we allow $name/.git to be discovered, while some may want to have\na bare repository at $name.git that is bare, so we also allow it to\nbe discovered).  The recent tweak was to favor the case where the\nname asked explicitly by the user is matched first, and it does not\nfundamentally change the intent of the basic design in any way.\n\nThanks for confirming that the tweak works well for you.\n\n> My test machines\n> don't have that version yet though and I'm left with a problem where git\n> is older than 1.7.9.2. \n\nSo what do you want to see happen next?\n"},{"id":"197269","messageId":"1345327565.27428.75.camel@ted","threadId":"31278","inReplyTo":"7vk3wwrlc9.fsf@alter.siamese.dyndns.org","subject":"Re: Problems with git fetch confusing foo and foo.git repos","fromName":"Richard Purdie","fromEmail":"richard.purdie@linuxfoundation.org","sentAt":"2012-08-18T22:06:05Z","receivedAt":"2012-08-18T22:06:05Z","isPatch":false,"sender":{"key":"richard.purdie@linuxfoundation.org","avatar":null},"body":"On Sat, 2012-08-18 at 13:33 -0700, Junio C Hamano wrote:\n> Richard Purdie <richard.purdie@linuxfoundation.org> writes:\n> \n> > I'd add that I think the commit made for the original problem[1] has\n> > fixed this scenario since it now will prefer foo over foo.git also in\n> > the fetch case even if the / is removed from the url.\n> \n> OK.\n> \n> As understand it, these \"check various possibilities e.g. $name,\n> $name.git $name/.git\" were never meant to be a way to encourage\n> users to have multiple repositories next to each other under\n> confusing names in the first place.  It was merely to allow users to\n> have one of them (some may prefer $name/ that is with working tree,\n> so we allow $name/.git to be discovered, while some may want to have\n> a bare repository at $name.git that is bare, so we also allow it to\n> be discovered).  The recent tweak was to favor the case where the\n> name asked explicitly by the user is matched first, and it does not\n> fundamentally change the intent of the basic design in any way.\n> \n> Thanks for confirming that the tweak works well for you.\n\nI'm responsible for \"generic\" source fetching infrastructure and\nunfortunately I haven't been able to prevent users ending up with\n\"repositories next to each other under confusing names\" much as I might\nlike to. Users tend to manage to find all the corner cases in something\nlike this :)\n\n> > My test machines\n> > don't have that version yet though and I'm left with a problem where git\n> > is older than 1.7.9.2. \n> \n> So what do you want to see happen next?\n\nI was a bit confused earlier whether there was any remaining issue. With\nthe recent versions I've now confirmed there isn't and the bug is fixed\n(which I really appreciate). Sorry for the noise.\n\nMy remaining question was whether there was any better way to work\naround this in older versions of git. I've ended up implementing the\nsymlink solution I mentioned which whilst ugly, will hopefully put this\nissue to rest for me.\n\n(http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=a86bd422641ce083ba0cdb4efe2a4c307eb36f7e in case anyone cares)\n\nCheers,\n\nRichard\n"}]}