A little more progress on what I'm going to have to do, github action,
without set-head the ref/HEAD isn't present
- uses: actions/checkout@v4
with:
ref: ${{ github.event.workflow_run.head_branch}}
filter: "blob:none"
fetch-depth: 0
- run: git remote set-head origin --auto # fixes otherwise the cat
will not find a file
- run: cat .git/refs/remotes/origin/HEAD
https://github.com/xenoterracide/gradle-convention/actions/runs/11917790368/job/33213687888
My problem of course isn't what *I* have to do, it's explaining to
other people what to do and why; as it feels like this could set-head
implicitly.
/usr/bin/git -c protocol.version=2 fetch --prune
--no-recurse-submodules --filter=blob:none origin
+refs/heads/*:refs/remotes/origin/* +refs/tags/*:refs/tags/*
+e1f39782ea2c90f5a9657ae88369599518b22a51:refs/remotes/pull/57/merge
On Tue, Nov 19, 2024 at 10:40 AM Caleb Cushing <xenoterracide@xxxxxxxxx> wrote:
>
> sounds great. I think I realized why I didn't have it. It's not done
> by `git remote add <origin> https://...` my experiment was `git
> remote rm origin` and then `git remote add origin ... ; git fetch
> --all --prune` I think I also tried without the prune option. git
> version 2.46.1
>
> What I want mostly is for that HEAD ref to always exist. As far as
> there being ways to configure it, that's all good but I don't want to
> explain doing that to consumers of my code. I'd rather it just work
> for them, on clones, and add remotes or fetch if it's missing.
>
> I'm not super worried about it being updated as I feel like if that
> ever happens it's something loudly communicated, and I'm more willing
> to find it ok to make that an FAQ, if this breaks because that changed
> you can manually update that. Mostly I'm of the opinion that what I'm
> doing needs to work in various CI environments out of the box.
>
> Thanks for the info, hopefully soon (tm).
>
> On Sat, Nov 16, 2024 at 10:02 AM Bence Ferdinandy <bence@xxxxxxxxxxxxxx> wrote:
> >
> >
> > On Sat Nov 16, 2024 at 04:36, Jeff King <peff@xxxxxxxx> 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@xxxxxxxxxxxxxx/
> >
> > 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@xxxxxxxxxxxxxx/
> >
> > There's definitely going to be another round, but I think (hope :)) we're not
> > very far off from finishing.
> >
> > Best,
> > Bence
>
>
>
> --
> Caleb Cushing
>
> Appointments https://calendly.com/caleb-cushing
> https://xenoterracide.com
--
Caleb Cushing
Appointments https://calendly.com/caleb-cushing
https://xenoterracide.com
