From: "Bence Ferdinandy" <bence@ferdinandy.com>
To: "Jeff King" <peff@peff.net>, "Caleb Cushing" <xenoterracide@gmail.com>
Cc: <git@vger.kernel.org>
Subject: Re: git remote set-head automatically
Date: Sat, 16 Nov 2024 16:01:59 +0100 [thread overview]
Message-ID: <D5NOZMMISX44.2PTTMY57J5EM6@ferdinandy.com> (raw)
In-Reply-To: <20241116033616.GB1782794@coredump.intra.peff.net>
On Sat Nov 16, 2024 at 04:36, Jeff King <peff@peff.net> wrote:
> On Fri, Nov 15, 2024 at 09:34:28AM -0500, Caleb Cushing wrote:
>
>> Context: recently I've been trying to develop a feature for my Gradle
>> plugin that derives a semantic version from git describe. In order to
>> achieve my next level of feature I need the HEAD Branch. Now, I can
>> get this branch using git remote show <remote> and parsing the output.
>> I'm a firm believer that it should be possible for me to write code,
>> long term even, without the internet; I did this once with my job when
>> I needed to go home to my parents who were very rural and didn't have
>> internet; I was able to keep working without access. I want that for
>> anyone that uses this tool.
>
> You should use the refs/remotes/<remote>/HEAD symref instead (or its
> alias, just "<remote>"), which is more convenient and doesn't hit the
> network. Which is exactly what...
>
>> Problem: I don't want to have to do a network request every time I do
>> a build, in fact I'd rather almost never have to do a network request.
>> Gradle makes reducing the network request to less than once per build
>> something ... unsupported. jgit doesn't expose support for fetching
>> this information. Then I found out that you could do `git remote
>> set-head <remote> <branch>` which appears to behave exactly how I'd
>> want and expect. It doesn't easily solve my problem though because I
>> want my solution to be generally applicable.
>
> ...set-head will set. So OK, but...
>
>> Ideal Long-Term Solution: git remote set-head happens automatically on
>> lone, and even fetch if it's not set. Explicit setting would override
>> any automatic setting; and it might be a good idea to automatically
>> unset if the HEAD branch disappears from the remote.
>
> We already do the equivalent of set-head on clone. If you do:
>
> git clone https://github.com/git/git
> cd git
> git symbolic-ref refs/remotes/origin/HEAD
>
> you should see it pointing to "refs/remotes/origin/master" (and like you
> can refer to "origin/HEAD" or "origin" from git-log, etc). Are you not
> seeing that?
>
> We don't update it on fetch. That has been discussed, but there are some
> questions about when it should overwrite what's available locally. E.g.
> this thread:
>
> https://lore.kernel.org/git/D3HBD7C1FR14.74FL1Q1S9UCB@ferdinandy.com/
That part we already have pinned down: fetch will only update remote/HEAD if it
doesn't already exist. So running "init && remote add && fetch" should end you
up in the same place as "clone" (although fetch will report if the remote has
changed HEAD compared to what you have for transparency). If you _always_ want
to have the latest head you'll need to run "fetch && remote set-head --auto
[remote]" every time.
Something like
git fetch --all && git remote | xargs -i git remote set-head -a {}
covers everything.
>
> There have been some patches in that direction but I have not kept up
> with the current state:
>
> https://lore.kernel.org/git/20241023153736.257733-2-bence@ferdinandy.com/
There's definitely going to be another round, but I think (hope :)) we're not
very far off from finishing.
Best,
Bence
next prev parent reply other threads:[~2024-11-16 15:02 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-15 14:34 git remote set-head automatically Caleb Cushing
2024-11-16 3:36 ` Jeff King
2024-11-16 15:01 ` Bence Ferdinandy [this message]
2024-11-19 15:40 ` Caleb Cushing
2024-11-19 17:06 ` Caleb Cushing
2024-11-19 18:44 ` Jeff King
2024-11-20 1:10 ` Junio C Hamano
2024-11-20 1:17 ` Junio C Hamano
2024-11-20 8:58 ` Bence Ferdinandy
2025-01-12 8:19 ` Bence Ferdinandy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=D5NOZMMISX44.2PTTMY57J5EM6@ferdinandy.com \
--to=bence@ferdinandy.com \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
--cc=xenoterracide@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox