From: Junio C Hamano <hidden> Date: 2016-06-15 22:45:31
"Alex Riesen" [off-list ref] writes:
2008/10/21 Junio C Hamano [off-list ref]:
quoted
"Leo Razoumov" [off-list ref] writes:
quoted
Even though the old behavior is "long established", it introduces
unnecessary ambiguity. If I have two repos
...
Of course. Now you know why people don't name such a pair of repositories
like that ;-).
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.
If you think about it deeper, you will realize that it is not even clear
if it is "stupid".
More importantly, the behaviour is consistent with the way how "git fetch"
and "git clone" DWIMs the repository name by suffixing .git when the input
lacks it. And this DWIMmery comes from the expectations that:
(1) people name their repository project.git; and
(2) people like using and seeing short names (iow, "clone
git://$somewhere/project" is preferred over "clone
git://$somewhere/project.git");
If a repository whose real location is git://$somewhere/project.git is
cloned/fetched as git://$somewhere/project by people, recording the merge
source using the shorter name used by people to fetch from it is more
consistent. The patch breaks this consistency [*1*].
What is clear is that you would confuse yourself if you have two
repositories A and A.git next to each other, and that is primarily because
it breaks the above expectation.
git core-level rarely imposes such policies, but what Porcelains do is a
different matter.
Hence the suggestion: don't do it.
[Footnote]
*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.
From: Alex Riesen <hidden> Date: 2016-06-15 22:45:31
2008/10/22 Junio C Hamano [off-list ref]:
"Alex Riesen" [off-list ref] writes:
quoted
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.
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:45:31
Alex Riesen wrote:
2008/10/22 Junio C Hamano [off-list ref]:
quoted
"Alex Riesen" [off-list ref] writes:
quoted
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
quoted
*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
From: Leo Razoumov <hidden> Date: 2016-06-15 22:45:31
On 10/21/08, Junio C Hamano [off-list ref] wrote:
"Alex Riesen" [off-list ref] writes:
> 2008/10/21 Junio C Hamano [off-list ref]:
>> "Leo Razoumov" [off-list ref] writes:
>>
>>> Even though the old behavior is "long established", it introduces
>>> unnecessary ambiguity. If I have two repos
>>> ...
>>
>> Of course. Now you know why people don't name such a pair of repositories
>> like that ;-).
>
> 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.
If you think about it deeper, you will realize that it is not even clear
if it is "stupid".
More importantly, the behaviour is consistent with the way how "git fetch"
and "git clone" DWIMs the repository name by suffixing .git when the input
lacks it. And this DWIMmery comes from the expectations that:
(1) people name their repository project.git; and
(2) people like using and seeing short names (iow, "clone
git://$somewhere/project" is preferred over "clone
git://$somewhere/project.git");
If a repository whose real location is git://$somewhere/project.git is
cloned/fetched as git://$somewhere/project by people, recording the merge
source using the shorter name used by people to fetch from it is more
consistent. The patch breaks this consistency [*1*].
What is clear is that you would confuse yourself if you have two
repositories A and A.git next to each other, and that is primarily because
it breaks the above expectation.
git core-level rarely imposes such policies, but what Porcelains do is a
different matter.
Hence the suggestion: don't do it.
[Footnote]
*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.
I think this discussion went in the direction of "correct" versus
"convent". I, personally, will choose correct over convenient any
time. Different people use git for different projects and their
expectations differ in this regard. In my case
after I do "git clone Foo.git" I get "Foo" repo side-by-side with
"Foo.git" and the ambiguity becomes apparent.
Regarding your footnote *1*. I agree with your suggestions and I can
improve the patch in the following way:
(1) Fetch/clone messages/comments will refer to the source/destination
repos by their complete names without stripping off any parts
(2) Searching for a source repo, clone/fetch will first try an exact
match and if it fails it will remove/add ".git" suffix and
From: Leo Razoumov <hidden> Date: 2016-06-15 22:45:31
My apologies!! I hit send button by mistake before message was
complete. Please, see below a completed version.
--Leo--
On 10/21/08, Junio C Hamano [off-list ref] wrote:
"Alex Riesen" [off-list ref] writes:
> 2008/10/21 Junio C Hamano [off-list ref]:
>> "Leo Razoumov" [off-list ref] writes:
>>
>>> Even though the old behavior is "long established", it introduces
>>> unnecessary ambiguity. If I have two repos
>>> ...
>>
>> Of course. Now you know why people don't name such a pair of repositories
>> like that ;-).
>
> 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.
If you think about it deeper, you will realize that it is not even clear
if it is "stupid".
More importantly, the behaviour is consistent with the way how "git fetch"
and "git clone" DWIMs the repository name by suffixing .git when the input
lacks it. And this DWIMmery comes from the expectations that:
(1) people name their repository project.git; and
(2) people like using and seeing short names (iow, "clone
git://$somewhere/project" is preferred over "clone
git://$somewhere/project.git");
If a repository whose real location is git://$somewhere/project.git is
cloned/fetched as git://$somewhere/project by people, recording the merge
source using the shorter name used by people to fetch from it is more
consistent. The patch breaks this consistency [*1*].
What is clear is that you would confuse yourself if you have two
repositories A and A.git next to each other, and that is primarily because
it breaks the above expectation.
git core-level rarely imposes such policies, but what Porcelains do is a
different matter.
Hence the suggestion: don't do it.
[Footnote]
*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.
I think this discussion went in the direction of "correct" versus
"convent". I, personally, will choose correct over convenient any
time. Different people use git for different projects and their
expectations differ in this regard. In my case
after I do "git clone Foo.git" I get "Foo" repo side-by-side with
"Foo.git" and the ambiguity becomes apparent.
Regarding your footnote *1*. I agree with your suggestions and I can
improve the patch in the following way:
(P1) Fetch/clone messages/records will refer to the source/destination
repos by their complete names without stripping off any parts of the name.
(P2) Searching for a source repo, clone/fetch will first try an exact
match and if it fails it will remove/add ".git" suffix as needed and retry.
Item (P2) will provide the convenience, while item (P1) still
guarantees correctness.
Please, let me know if such approach is more satisfactory.
--Leo--