From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Junio C Hamano <gitster@pobox.com>
Cc: GIT Mailing-list <git@vger.kernel.org>,
"Ashfield, Bruce" <Bruce.Ashfield@windriver.com>,
"saul.wold" <saul.wold@intel.com>
Subject: Re: Problems with git fetch confusing foo and foo.git repos
Date: Sat, 18 Aug 2012 23:06:05 +0100 [thread overview]
Message-ID: <1345327565.27428.75.camel@ted> (raw)
In-Reply-To: <7vk3wwrlc9.fsf@alter.siamese.dyndns.org>
On Sat, 2012-08-18 at 13:33 -0700, Junio C Hamano wrote:
> Richard Purdie <richard.purdie@linuxfoundation.org> 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,
> $name.git $name/.git" were never meant to be a way to encourage
> users to have multiple repositories next to each other under
> confusing names in the first place. It was merely to allow users to
> have one of them (some may prefer $name/ that is with working tree,
> so we allow $name/.git to be discovered, while some may want to have
> a bare repository at $name.git that is bare, so we also allow it to
> be discovered). The recent tweak was to favor the case where the
> name asked explicitly by the user is matched first, and it does not
> fundamentally change the intent of the basic design in any way.
>
> Thanks for confirming that the tweak works well for you.
I'm responsible for "generic" source fetching infrastructure and
unfortunately I haven't been able to prevent users ending up with
"repositories next to each other under confusing names" much as I might
like to. Users tend to manage to find all the corner cases in something
like this :)
> > 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.
>
> So what do you want to see happen next?
I was a bit confused earlier whether there was any remaining issue. With
the recent versions I've now confirmed there isn't and the bug is fixed
(which I really appreciate). Sorry for the noise.
My remaining question was whether there was any better way to work
around this in older versions of git. I've ended up implementing the
symlink solution I mentioned which whilst ugly, will hopefully put this
issue to rest for me.
(http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=a86bd422641ce083ba0cdb4efe2a4c307eb36f7e in case anyone cares)
Cheers,
Richard
prev parent reply other threads:[~2012-08-18 22:06 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-18 14:25 Problems with git fetch confusing foo and foo.git repos Richard Purdie
2012-08-18 14:49 ` Richard Purdie
2012-08-18 20:33 ` Junio C Hamano
2012-08-18 22:06 ` Richard Purdie [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1345327565.27428.75.camel@ted \
--to=richard.purdie@linuxfoundation.org \
--cc=Bruce.Ashfield@windriver.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=saul.wold@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).