Re: [PATCH] clone: Remove constraint on --bare and --origin

[Junio C Hamano <gitster@pobox.com>]

Øystein Walle <oystwa@gmail.com> writes:

> This test has been present since long before clone was ported to C. Now
> there is no need for it, and since df61c88979 (clone: also configure url
> for bare clones, 2010-03-29) it's especially useful to allow both
> options.
>
> Signed-off-by: Øystein Walle <oystwa@gmail.com>
> ---
>
> A question on this constraint popped up on #git the other day. I
> investigated a bit and found no particular reason for its existence. All
> tests still pass (except the one removed here) and the behavior is as
> expected. I realize it might have gone under the radar for 11 years but
> it's still worth the noise to remove it, in my opinion.
>
> I wanted to include a bit on the reasoning for the original check in the
> commit message but I couldn't find it. 

I suspect that this originally was because "git clone --bare" does
not use any remote-tracking branch (i.e. no refs/remotes/origin/*)
and the only expected way to update a "git clone --bare" repository
was to run "git fetch --mirror [--prune]", so there was no need to
make the nickname "origin" to be configurable.

I do not offhand know what other features in "git clone --bare" that
were added since then affect the resulting repository so that the
name "origin" it leaves there (perhaps in its configuration, if not
names in ref hierarchy) is visible to the end user and deserves to
be customizable.

In short, I think the "don't use --origin in a bare repository" was
not because "doing so will break X and Y", but because "doing so
does not make any practical difference".  So I am OK to lift this
check.  It is a small enough change that is easy to revert if there
were some valid reasons we failed to consider.

Thanks.