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

Øystein Walle [off-list ref] 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 <redacted>
---

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.