Re: [PATCH] git-fetch should not strip off ".git" extension
- From
Andreas Ericsson <ae@op5.se>
- Date
- Oct 22, 2008, 07:55 UTC
- Message-ID
- <48FEDC63.8090104@op5.se>
- In-Reply-To
- <81b0412b0810211543p6cb8c4ej49fb7fe70c3e2917@mail.gmail.com>
Alex Riesen wrote:
Show 14 quoted lines
> 2008/10/22 Junio C Hamano <gitster@pobox.com>: >> "Alex Riesen" <raa.lkml@gmail.com> writes: >>> FWIW, I support Leo on that. The "established" behavior is stupid. >> I am not inclined to respond to such an emotional argument. On the other >> hand, it is fair to say that the existing behaviour is established, >> because it is backed by a long history, which you can objectively verify. > > I found it illogical (well, stupid) and inconvinient > >> *1* It would be a different matter if the patch at the same time removed >> the fetch/clone DWIMmery. At least such a patch would be internally self >> consistent. > > Good idea.
No. Bad idea. That would not only break people's fetch configurations if they've done clone on repos without passing .git, but also mean users would have to remember if a particular server names their bare repos "project.git".
If you remove *all* DWIMmery from fetch/clone, you'd also break people's expectations when they're fetching from each other, as they'd have to pass "git://devpeer/project/.git" instead of just "git://devpeer/project", which is what *looks* sane.
A good idea would be to always report the name the user used. 'git clone' already does that, recording the non-DWIMmed URL in the remotes config.
-- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231