From: Kristoffer Haugsbakk Date: Fri, 27 Sep 2024 20:10:28 GMT Subject: Re: [PATCH] builtin/clone: teach git-clone(1) the --ref= argument Message-ID: <555169c4-beea-40cf-a542-f8a75bcb44e8@app.fastmail.com> In-Reply-To: On Fri, Sep 27, 2024, at 21:29, brian m. carlson wrote: > On 2024-09-27 at 19:20:14, Junio C Hamano wrote: >> Toon Claes 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 to do something specific. It’s certainly nice to have all that information in the commit message. -- Kristoffer Haugsbakk