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 <toon@xxxxxxxxx> 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
