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

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 2, 2021, 02:18 UTC
Message-ID: <xmqq4kc8zj02.fsf@gitster.g>
In-Reply-To: <20210801082546.18543-1-oystwa@gmail.com>

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

Show 16 quoted lines

> 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.