On Sat, 2012-08-18 at 13:33 -0700, Junio C Hamano wrote:
> Richard Purdie writes:
>
> > 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.
>
> OK.
Richard Purdie writes:
> 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.
OK.
As understand it, these "check various possibilities e.g. $name,
$nam
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
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 ver
4 matches
Mail list logo
