Re: [PATCH] builtin/clone: teach git-clone(1) the --ref= argument

From: Kristoffer Haugsbakk <kristofferhaugsbakk@fastmail.com>
Date: Sep 27, 2024, 20:10 UTC
Message-ID: <555169c4-beea-40cf-a542-f8a75bcb44e8@app.fastmail.com>
In-Reply-To: <ZvcHpd26te8TPacz@tapette.crustytoothpaste.net>

On Fri, Sep 27, 2024, at 21:29, brian m. carlson wrote:

Show 39 quoted lines

> On 2024-09-27 at 19:20:14, Junio C Hamano wrote:
>> Toon Claes <toon@iotcl.com> writes:
>>
>> > It's pretty similar to --branch and
>> > while --branch takes a branch name or tag name, it doesn't take a fully
>> > qualified reference. This allows the user to clone a reference that
>> > doesn't start with refs/heads or refs/tags. This can be useful when the
>> > server uses custom references.
>>
>> "when the server uses custom references" is a rather weak
>> explanation.
>>
>> The answer to "Doctor, it hurts when I turn my elbow in this
>> unnatural direction" is usually "Well, do not do it then".  The
>> answer to "Doctor, I cannot use the --branch option because I use
>> non branches to keep track of some histories" should be the same.
>> Why do you want to turn your elbow in an unnatural angle in the
>> first place?
>
> I can't speak for what Toon intended here, but GitHub uses some
> references under `refs/pull` that are used for tracking pull requests.
> We even have some in the Git repository on GitHub:
>
>   % git ls-remote upstream refs/pull/* | head -n 5
>   f0d0fd3a5985d5e588da1e1d11c85fba0ae132f8        refs/pull/10/head
>   c8198f6c2c9fc529b25988dfaf5865bae5320cb5        refs/pull/10/merge
>   d604669e32e847c2ba5010c89895dd707ba45f55        refs/pull/100/head
>   55ab0c9399879683b4cc6e1baea5dc41484ca52f        refs/pull/100/merge
>   08d39e0bb5b9dbd16e9e4c2250e75848718c453b        refs/pull/1000/head
>
> These are not kept under `refs/heads` because `refs/heads` belongs to
> the user, but it is generally useful to check them out in case of very
> large changes or changes with complex binary files which don't render
> well in the web interface (among other reasons) that might need to be
> inspected for code review.  So I think this is a generally useful
> feature, although I agree that perhaps the commit message might explain
> the benefits in a more concrete way for those who don't already
> understand the utility of the feature (such as our illustrious
> maintainer).

I’ve seen a few times that a change is proposed with a commit message that says that it allows you to do X. And plenty of motivation is provided in a narrow (technical) sense of how X makes things nicer. But without explaining why you’d want to do X. Then someone needs to ask the the submitter why. Then they say that they need it at <organization> to do something specific.

It’s certainly nice to have all that information in the commit message.

-- 
Kristoffer Haugsbakk