{"thread":{"id":"62499","subject":"git remote set-head automatically","startedAt":"2024-11-15T14:35:04Z","lastAt":"2025-01-12T08:25:12Z","messageCount":10,"participants":["Caleb Cushing","Jeff King","Bence Ferdinandy","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"507371","messageId":"CAAHKNRGv19rhnqCkJMpE2FomNQBHvSS36aC=fh0UwO+9-6RRfA@mail.gmail.com","threadId":"62499","inReplyTo":null,"subject":"git remote set-head automatically","fromName":"Caleb Cushing","fromEmail":"xenoterracide@gmail.com","sentAt":"2024-11-15T14:34:28Z","receivedAt":"2024-11-15T14:35:04Z","isPatch":false,"sender":{"key":"xenoterracide@gmail.com","avatar":"https://gravatar.com/avatar/af3f0745dfa0ea9c4ee551d7d0a3cfe7ba8d229754c11678ab2ed23c3fa57065?d=mp&s=160"},"body":"Context: recently I've been trying to develop a feature for my Gradle\nplugin that derives a semantic version from git describe. In order to\nachieve my next level of feature I need the HEAD Branch. Now, I can\nget this branch using git remote show and parsing the output.\nI'm a firm believer that it should be possible for me to write code,\nlong term even, without the internet; I did this once with my job when\nI needed to go home to my parents who were very rural and didn't have\ninternet; I was able to keep working without access. I want that for\nanyone that uses this tool.\n\nProblem: I don't want to have to do a network request every time I do\na build, in fact I'd rather almost never have to do a network request.\nGradle makes reducing the network request to less than once per build\nsomething ... unsupported. jgit doesn't expose support for fetching\nthis information. Then I found out that you could do `git remote\nset-head ` which appears to behave exactly how I'd\nwant and expect. It doesn't easily solve my problem though because I\nwant my solution to be generally applicable.\n\nIdeal Long-Term Solution: git remote set-head happens automatically on\nlone, and even fetch if it's not set. Explicit setting would override\nany automatic setting; and it might be a good idea to automatically\nunset if the HEAD branch disappears from the remote.\n\nCould this change be made? is there a reason not to?\n\nPlease cc, I'm not on the list.\n\n-- \nCaleb Cushing\n\nAppointments https://calendly.com/caleb-cushing\nhttps://xenoterracide.com\n"},{"id":"507392","messageId":"20241116033616.GB1782794@coredump.intra.peff.net","threadId":"62499","inReplyTo":"CAAHKNRGv19rhnqCkJMpE2FomNQBHvSS36aC=fh0UwO+9-6RRfA@mail.gmail.com","subject":"Re: git remote set-head automatically","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2024-11-16T03:36:16Z","receivedAt":"2024-11-16T03:36:17Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Nov 15, 2024 at 09:34:28AM -0500, Caleb Cushing wrote:\n\n> Context: recently I've been trying to develop a feature for my Gradle\n> plugin that derives a semantic version from git describe. In order to\n> achieve my next level of feature I need the HEAD Branch. Now, I can\n> get this branch using git remote show and parsing the output.\n> I'm a firm believer that it should be possible for me to write code,\n> long term even, without the internet; I did this once with my job when\n> I needed to go home to my parents who were very rural and didn't have\n> internet; I was able to keep working without access. I want that for\n> anyone that uses this tool.\n\nYou should use the refs/remotes//HEAD symref instead (or its\nalias, just \"\"), which is more convenient and doesn't hit the\nnetwork. Which is exactly what...\n\n> Problem: I don't want to have to do a network request every time I do\n> a build, in fact I'd rather almost never have to do a network request.\n> Gradle makes reducing the network request to less than once per build\n> something ... unsupported. jgit doesn't expose support for fetching\n> this information. Then I found out that you could do `git remote\n> set-head ` which appears to behave exactly how I'd\n> want and expect. It doesn't easily solve my problem though because I\n> want my solution to be generally applicable.\n\n...set-head will set. So OK, but...\n\n> Ideal Long-Term Solution: git remote set-head happens automatically on\n> lone, and even fetch if it's not set. Explicit setting would override\n> any automatic setting; and it might be a good idea to automatically\n> unset if the HEAD branch disappears from the remote.\n\nWe already do the equivalent of set-head on clone. If you do:\n\n git clone https://github.com/git/git\n cd git\n git symbolic-ref refs/remotes/origin/HEAD\n\nyou should see it pointing to \"refs/remotes/origin/master\" (and like you\ncan refer to \"origin/HEAD\" or \"origin\" from git-log, etc). Are you not\nseeing that?\n\nWe don't update it on fetch. That has been discussed, but there are some\nquestions about when it should overwrite what's available locally. E.g.\nthis thread:\n\n https://lore.kernel.org/git/D3HBD7C1FR14.74FL1Q1S9UCB@ferdinandy.com/\n\nThere have been some patches in that direction but I have not kept up\nwith the current state:\n\n https://lore.kernel.org/git/20241023153736.257733-2-bence@ferdinandy.com/\n\n-Peff\n"},{"id":"507408","messageId":"D5NOZMMISX44.2PTTMY57J5EM6@ferdinandy.com","threadId":"62499","inReplyTo":"20241116033616.GB1782794@coredump.intra.peff.net","subject":"Re: git remote set-head automatically","fromName":"Bence Ferdinandy","fromEmail":"bence@ferdinandy.com","sentAt":"2024-11-16T15:01:59Z","receivedAt":"2024-11-16T15:02:29Z","isPatch":false,"sender":{"key":"bence@ferdinandy.com","avatar":"https://avatars.githubusercontent.com/u/6343487?v=4"},"body":"\nOn Sat Nov 16, 2024 at 04:36, Jeff King wrote:\n> On Fri, Nov 15, 2024 at 09:34:28AM -0500, Caleb Cushing wrote:\n>\n>> Context: recently I've been trying to develop a feature for my Gradle\n>> plugin that derives a semantic version from git describe. In order to\n>> achieve my next level of feature I need the HEAD Branch. Now, I can\n>> get this branch using git remote show and parsing the output.\n>> I'm a firm believer that it should be possible for me to write code,\n>> long term even, without the internet; I did this once with my job when\n>> I needed to go home to my parents who were very rural and didn't have\n>> internet; I was able to keep working without access. I want that for\n>> anyone that uses this tool.\n>\n> You should use the refs/remotes//HEAD symref instead (or its\n> alias, just \"\"), which is more convenient and doesn't hit the\n> network. Which is exactly what...\n>\n>> Problem: I don't want to have to do a network request every time I do\n>> a build, in fact I'd rather almost never have to do a network request.\n>> Gradle makes reducing the network request to less than once per build\n>> something ... unsupported. jgit doesn't expose support for fetching\n>> this information. Then I found out that you could do `git remote\n>> set-head ` which appears to behave exactly how I'd\n>> want and expect. It doesn't easily solve my problem though because I\n>> want my solution to be generally applicable.\n>\n> ...set-head will set. So OK, but...\n>\n>> Ideal Long-Term Solution: git remote set-head happens automatically on\n>> lone, and even fetch if it's not set. Explicit setting would override\n>> any automatic setting; and it might be a good idea to automatically\n>> unset if the HEAD branch disappears from the remote.\n>\n> We already do the equivalent of set-head on clone. If you do:\n>\n> git clone https://github.com/git/git\n> cd git\n> git symbolic-ref refs/remotes/origin/HEAD\n>\n> you should see it pointing to \"refs/remotes/origin/master\" (and like you\n> can refer to \"origin/HEAD\" or \"origin\" from git-log, etc). Are you not\n> seeing that?\n>\n> We don't update it on fetch. That has been discussed, but there are some\n> questions about when it should overwrite what's available locally. E.g.\n> this thread:\n>\n> https://lore.kernel.org/git/D3HBD7C1FR14.74FL1Q1S9UCB@ferdinandy.com/\n\nThat part we already have pinned down: fetch will only update remote/HEAD if it\ndoesn't already exist. So running \"init && remote add && fetch\" should end you\nup in the same place as \"clone\" (although fetch will report if the remote has\nchanged HEAD compared to what you have for transparency). If you _always_ want\nto have the latest head you'll need to run \"fetch && remote set-head --auto\n[remote]\" every time.\n\nSomething like\n\tgit fetch --all && git remote | xargs -i git remote set-head -a {}\ncovers everything.\n\n>\n> There have been some patches in that direction but I have not kept up\n> with the current state:\n>\n> https://lore.kernel.org/git/20241023153736.257733-2-bence@ferdinandy.com/\n\nThere's definitely going to be another round, but I think (hope :)) we're not\nvery far off from finishing.\n\nBest,\nBence\n"},{"id":"507625","messageId":"CAAHKNRF8JDUTH-QzPG1b4-wafzU+MXaMNinfBRu3JfCssfwGUw@mail.gmail.com","threadId":"62499","inReplyTo":"D5NOZMMISX44.2PTTMY57J5EM6@ferdinandy.com","subject":"Re: git remote set-head automatically","fromName":"Caleb Cushing","fromEmail":"xenoterracide@gmail.com","sentAt":"2024-11-19T15:40:55Z","receivedAt":"2024-11-19T15:41:34Z","isPatch":false,"sender":{"key":"xenoterracide@gmail.com","avatar":"https://gravatar.com/avatar/af3f0745dfa0ea9c4ee551d7d0a3cfe7ba8d229754c11678ab2ed23c3fa57065?d=mp&s=160"},"body":"sounds great. I think I realized why I didn't have it. It's not done\nby `git remote add https://...` my experiment was `git\nremote rm origin` and then `git remote add origin ... ; git fetch\n--all --prune` I think I also tried without the prune option. git\nversion 2.46.1\n\nWhat I want mostly is for that HEAD ref to always exist. As far as\nthere being ways to configure it, that's all good but I don't want to\nexplain doing that to consumers of my code. I'd rather it just work\nfor them, on clones, and add remotes or fetch if it's missing.\n\nI'm not super worried about it being updated as I feel like if that\never happens it's something loudly communicated, and I'm more willing\nto find it ok to make that an FAQ, if this breaks because that changed\nyou can manually update that. Mostly I'm of the opinion that what I'm\ndoing needs to work in various CI environments out of the box.\n\nThanks for the info, hopefully soon (tm).\n\nOn Sat, Nov 16, 2024 at 10:02 AM Bence Ferdinandy wrote:\n>\n>\n> On Sat Nov 16, 2024 at 04:36, Jeff King wrote:\n> > On Fri, Nov 15, 2024 at 09:34:28AM -0500, Caleb Cushing wrote:\n> >\n> >> Context: recently I've been trying to develop a feature for my Gradle\n> >> plugin that derives a semantic version from git describe. In order to\n> >> achieve my next level of feature I need the HEAD Branch. Now, I can\n> >> get this branch using git remote show and parsing the output.\n> >> I'm a firm believer that it should be possible for me to write code,\n> >> long term even, without the internet; I did this once with my job when\n> >> I needed to go home to my parents who were very rural and didn't have\n> >> internet; I was able to keep working without access. I want that for\n> >> anyone that uses this tool.\n> >\n> > You should use the refs/remotes//HEAD symref instead (or its\n> > alias, just \"\"), which is more convenient and doesn't hit the\n> > network. Which is exactly what...\n> >\n> >> Problem: I don't want to have to do a network request every time I do\n> >> a build, in fact I'd rather almost never have to do a network request.\n> >> Gradle makes reducing the network request to less than once per build\n> >> something ... unsupported. jgit doesn't expose support for fetching\n> >> this information. Then I found out that you could do `git remote\n> >> set-head ` which appears to behave exactly how I'd\n> >> want and expect. It doesn't easily solve my problem though because I\n> >> want my solution to be generally applicable.\n> >\n> > ...set-head will set. So OK, but...\n> >\n> >> Ideal Long-Term Solution: git remote set-head happens automatically on\n> >> lone, and even fetch if it's not set. Explicit setting would override\n> >> any automatic setting; and it might be a good idea to automatically\n> >> unset if the HEAD branch disappears from the remote.\n> >\n> > We already do the equivalent of set-head on clone. If you do:\n> >\n> > git clone https://github.com/git/git\n> > cd git\n> > git symbolic-ref refs/remotes/origin/HEAD\n> >\n> > you should see it pointing to \"refs/remotes/origin/master\" (and like you\n> > can refer to \"origin/HEAD\" or \"origin\" from git-log, etc). Are you not\n> > seeing that?\n> >\n> > We don't update it on fetch. That has been discussed, but there are some\n> > questions about when it should overwrite what's available locally. E.g.\n> > this thread:\n> >\n> > https://lore.kernel.org/git/D3HBD7C1FR14.74FL1Q1S9UCB@ferdinandy.com/\n>\n> That part we already have pinned down: fetch will only update remote/HEAD if it\n> doesn't already exist. So running \"init && remote add && fetch\" should end you\n> up in the same place as \"clone\" (although fetch will report if the remote has\n> changed HEAD compared to what you have for transparency). If you _always_ want\n> to have the latest head you'll need to run \"fetch && remote set-head --auto\n> [remote]\" every time.\n>\n> Something like\n> git fetch --all && git remote | xargs -i git remote set-head -a {}\n> covers everything.\n>\n> >\n> > There have been some patches in that direction but I have not kept up\n> > with the current state:\n> >\n> > https://lore.kernel.org/git/20241023153736.257733-2-bence@ferdinandy.com/\n>\n> There's definitely going to be another round, but I think (hope :)) we're not\n> very far off from finishing.\n>\n> Best,\n> Bence\n\n\n\n-- \nCaleb Cushing\n\nAppointments https://calendly.com/caleb-cushing\nhttps://xenoterracide.com\n"},{"id":"507633","messageId":"CAAHKNRF4AnvceiTDLdpNS94yRnoZYMSD0Wkg7V+4YBwSej7NSA@mail.gmail.com","threadId":"62499","inReplyTo":"CAAHKNRF8JDUTH-QzPG1b4-wafzU+MXaMNinfBRu3JfCssfwGUw@mail.gmail.com","subject":"Re: git remote set-head automatically","fromName":"Caleb Cushing","fromEmail":"xenoterracide@gmail.com","sentAt":"2024-11-19T17:06:21Z","receivedAt":"2024-11-19T17:06:57Z","isPatch":false,"sender":{"key":"xenoterracide@gmail.com","avatar":"https://gravatar.com/avatar/af3f0745dfa0ea9c4ee551d7d0a3cfe7ba8d229754c11678ab2ed23c3fa57065?d=mp&s=160"},"body":"A little more progress on what I'm going to have to do, github action,\nwithout set-head the ref/HEAD isn't present\n\n- uses: actions/checkout@v4\n with:\n ref: ${{ github.event.workflow_run.head_branch}}\n filter: \"blob:none\"\n fetch-depth: 0\n- run: git remote set-head origin --auto # fixes otherwise the cat\nwill not find a file\n- run: cat .git/refs/remotes/origin/HEAD\n\nhttps://github.com/xenoterracide/gradle-convention/actions/runs/11917790368/job/33213687888\n\nMy problem of course isn't what *I* have to do, it's explaining to\nother people what to do and why; as it feels like this could set-head\nimplicitly.\n\n/usr/bin/git -c protocol.version=2 fetch --prune\n--no-recurse-submodules --filter=blob:none origin\n+refs/heads/*:refs/remotes/origin/* +refs/tags/*:refs/tags/*\n+e1f39782ea2c90f5a9657ae88369599518b22a51:refs/remotes/pull/57/merge\n\nOn Tue, Nov 19, 2024 at 10:40 AM Caleb Cushing wrote:\n>\n> sounds great. I think I realized why I didn't have it. It's not done\n> by `git remote add https://...` my experiment was `git\n> remote rm origin` and then `git remote add origin ... ; git fetch\n> --all --prune` I think I also tried without the prune option. git\n> version 2.46.1\n>\n> What I want mostly is for that HEAD ref to always exist. As far as\n> there being ways to configure it, that's all good but I don't want to\n> explain doing that to consumers of my code. I'd rather it just work\n> for them, on clones, and add remotes or fetch if it's missing.\n>\n> I'm not super worried about it being updated as I feel like if that\n> ever happens it's something loudly communicated, and I'm more willing\n> to find it ok to make that an FAQ, if this breaks because that changed\n> you can manually update that. Mostly I'm of the opinion that what I'm\n> doing needs to work in various CI environments out of the box.\n>\n> Thanks for the info, hopefully soon (tm).\n>\n> On Sat, Nov 16, 2024 at 10:02 AM Bence Ferdinandy wrote:\n> >\n> >\n> > On Sat Nov 16, 2024 at 04:36, Jeff King wrote:\n> > > On Fri, Nov 15, 2024 at 09:34:28AM -0500, Caleb Cushing wrote:\n> > >\n> > >> Context: recently I've been trying to develop a feature for my Gradle\n> > >> plugin that derives a semantic version from git describe. In order to\n> > >> achieve my next level of feature I need the HEAD Branch. Now, I can\n> > >> get this branch using git remote show and parsing the output.\n> > >> I'm a firm believer that it should be possible for me to write code,\n> > >> long term even, without the internet; I did this once with my job when\n> > >> I needed to go home to my parents who were very rural and didn't have\n> > >> internet; I was able to keep working without access. I want that for\n> > >> anyone that uses this tool.\n> > >\n> > > You should use the refs/remotes//HEAD symref instead (or its\n> > > alias, just \"\"), which is more convenient and doesn't hit the\n> > > network. Which is exactly what...\n> > >\n> > >> Problem: I don't want to have to do a network request every time I do\n> > >> a build, in fact I'd rather almost never have to do a network request.\n> > >> Gradle makes reducing the network request to less than once per build\n> > >> something ... unsupported. jgit doesn't expose support for fetching\n> > >> this information. Then I found out that you could do `git remote\n> > >> set-head ` which appears to behave exactly how I'd\n> > >> want and expect. It doesn't easily solve my problem though because I\n> > >> want my solution to be generally applicable.\n> > >\n> > > ...set-head will set. So OK, but...\n> > >\n> > >> Ideal Long-Term Solution: git remote set-head happens automatically on\n> > >> lone, and even fetch if it's not set. Explicit setting would override\n> > >> any automatic setting; and it might be a good idea to automatically\n> > >> unset if the HEAD branch disappears from the remote.\n> > >\n> > > We already do the equivalent of set-head on clone. If you do:\n> > >\n> > > git clone https://github.com/git/git\n> > > cd git\n> > > git symbolic-ref refs/remotes/origin/HEAD\n> > >\n> > > you should see it pointing to \"refs/remotes/origin/master\" (and like you\n> > > can refer to \"origin/HEAD\" or \"origin\" from git-log, etc). Are you not\n> > > seeing that?\n> > >\n> > > We don't update it on fetch. That has been discussed, but there are some\n> > > questions about when it should overwrite what's available locally. E.g.\n> > > this thread:\n> > >\n> > > https://lore.kernel.org/git/D3HBD7C1FR14.74FL1Q1S9UCB@ferdinandy.com/\n> >\n> > That part we already have pinned down: fetch will only update remote/HEAD if it\n> > doesn't already exist. So running \"init && remote add && fetch\" should end you\n> > up in the same place as \"clone\" (although fetch will report if the remote has\n> > changed HEAD compared to what you have for transparency). If you _always_ want\n> > to have the latest head you'll need to run \"fetch && remote set-head --auto\n> > [remote]\" every time.\n> >\n> > Something like\n> > git fetch --all && git remote | xargs -i git remote set-head -a {}\n> > covers everything.\n> >\n> > >\n> > > There have been some patches in that direction but I have not kept up\n> > > with the current state:\n> > >\n> > > https://lore.kernel.org/git/20241023153736.257733-2-bence@ferdinandy.com/\n> >\n> > There's definitely going to be another round, but I think (hope :)) we're not\n> > very far off from finishing.\n> >\n> > Best,\n> > Bence\n>\n>\n>\n> --\n> Caleb Cushing\n>\n> Appointments https://calendly.com/caleb-cushing\n> https://xenoterracide.com\n\n\n\n-- \nCaleb Cushing\n\nAppointments https://calendly.com/caleb-cushing\nhttps://xenoterracide.com\n"},{"id":"507636","messageId":"20241119184404.GA15723@coredump.intra.peff.net","threadId":"62499","inReplyTo":"CAAHKNRF4AnvceiTDLdpNS94yRnoZYMSD0Wkg7V+4YBwSej7NSA@mail.gmail.com","subject":"Re: git remote set-head automatically","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2024-11-19T18:44:04Z","receivedAt":"2024-11-19T18:50:46Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Nov 19, 2024 at 12:06:21PM -0500, Caleb Cushing wrote:\n\n> A little more progress on what I'm going to have to do, github action,\n> without set-head the ref/HEAD isn't present\n> \n> - uses: actions/checkout@v4\n> with:\n> ref: ${{ github.event.workflow_run.head_branch}}\n> filter: \"blob:none\"\n> fetch-depth: 0\n> - run: git remote set-head origin --auto # fixes otherwise the cat\n> will not find a file\n\nWe do create the HEAD symref in clone by default, but IIRC\nactions/checkout does a more limited clone with --depth and\n--single-branch.\n\nThe separate set-head should work, but it is a shame that it will have\nto hit the server for a second request.\n\nYou might look for options in actions/checkout to change the way it\ninvokes Git. Though I suspect there might not be a way to trigger\ngit-clone to do a single-branch clone _and_ create the HEAD symref. So\nyou may be stuck with the two calls.\n\n> - run: cat .git/refs/remotes/origin/HEAD\n\nDon't access the file directly; it will break if the ref storage format\nchanges. Use \"git symbolic-ref refs/remotes/origin/HEAD\" instead.\n\n(Not sure if this was just illustrative or what you are planning to do\nin a real CI job).\n\n-Peff\n"},{"id":"507669","messageId":"xmqq1pz6btgq.fsf@gitster.g","threadId":"62499","inReplyTo":"CAAHKNRF8JDUTH-QzPG1b4-wafzU+MXaMNinfBRu3JfCssfwGUw@mail.gmail.com","subject":"Re: git remote set-head automatically","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-11-20T01:10:45Z","receivedAt":"2024-11-20T01:10:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":""},{"id":"507670","messageId":"xmqqv7wiaeku.fsf@gitster.g","threadId":"62499","inReplyTo":"CAAHKNRF8JDUTH-QzPG1b4-wafzU+MXaMNinfBRu3JfCssfwGUw@mail.gmail.com","subject":"Re: git remote set-head automatically","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-11-20T01:17:37Z","receivedAt":"2024-11-20T01:17:40Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Caleb Cushing writes:\n\n> sounds great. I think I realized why I didn't have it. It's not done\n> by `git remote add https://...` my experiment was `git\n> remote rm origin` and then `git remote add origin ... ; git fetch\n> --all --prune` I think I also tried without the prune option. git\n> version 2.46.1\n\nYes, \"git fetch\" does not notice a missing remotes/$name/HEAD and\ndoes not automatically create it.\n\nThis is being worked on in a separate thread.\n\nDoing it unconditionally may hurt some existing users (including me)\nwho see more than one primarily interesting branches in a single\nremote and want to force themselves to be more explicit, though.\nFor us, leaving remotes/$name/HEAD missing (e.g. by \"git clone\"\nfollowed by \"git update-ref --no-deref -d refs/remotes/origin/HEAD\")\nis a way to allow ourselves to say things like\n\n $ git checkout -b mytopic origin/maint\n $ git rebase origin/master mytopic\n\nbut not\n\n $ git checkout --detach origin\n\nbecause the last one is ambiguous between the two branches of\nprimary interest.\n\nBut hopefully they have trained their fingers not to say \"origin\" by\nnow ;-) So changing \"git fetch\" to auto-fill remotes/origin/HEAD to\nwhatever branch the remote is pointing at at the time of running\nwould be good enough for an initial enhanced version, even though we\nmight need to further improve on by allowing folks to opt out of the\nfeature.\n"},{"id":"507702","messageId":"D5QVRMGNDJ3A.4INI8UF7PDW5@ferdinandy.com","threadId":"62499","inReplyTo":"xmqqv7wiaeku.fsf@gitster.g","subject":"Re: git remote set-head automatically","fromName":"Bence Ferdinandy","fromEmail":"bence@ferdinandy.com","sentAt":"2024-11-20T08:58:40Z","receivedAt":"2024-11-20T08:59:14Z","isPatch":false,"sender":{"key":"bence@ferdinandy.com","avatar":"https://avatars.githubusercontent.com/u/6343487?v=4"},"body":"On Wed Nov 20, 2024 at 02:17, Junio C Hamano wrote:\n> Caleb Cushing writes:\n>\n>> sounds great. I think I realized why I didn't have it. It's not done\n>> by `git remote add https://...` my experiment was `git\n>> remote rm origin` and then `git remote add origin ... ; git fetch\n>> --all --prune` I think I also tried without the prune option. git\n>> version 2.46.1\n>\n> Yes, \"git fetch\" does not notice a missing remotes/$name/HEAD and\n> does not automatically create it.\n>\n> This is being worked on in a separate thread.\n>\n> Doing it unconditionally may hurt some existing users (including me)\n> who see more than one primarily interesting branches in a single\n> remote and want to force themselves to be more explicit, though.\n> For us, leaving remotes/$name/HEAD missing (e.g. by \"git clone\"\n> followed by \"git update-ref --no-deref -d refs/remotes/origin/HEAD\")\n> is a way to allow ourselves to say things like\n>\n> $ git checkout -b mytopic origin/maint\n> $ git rebase origin/master mytopic\n>\n> but not\n>\n> $ git checkout --detach origin\n>\n> because the last one is ambiguous between the two branches of\n> primary interest.\n\nYou learn every day :) I had no idea that the remote's name works this way.\n\nThanks!\n\n>\n> But hopefully they have trained their fingers not to say \"origin\" by\n> now ;-) So changing \"git fetch\" to auto-fill remotes/origin/HEAD to\n> whatever branch the remote is pointing at at the time of running\n> would be good enough for an initial enhanced version, even though we\n> might need to further improve on by allowing folks to opt out of the\n> feature.\n\n"},{"id":"510378","messageId":"D6ZY4MU53E2I.3LWESUZX6TR5A@ferdinandy.com","threadId":"62499","inReplyTo":"CAAHKNRF8JDUTH-QzPG1b4-wafzU+MXaMNinfBRu3JfCssfwGUw@mail.gmail.com","subject":"Re: git remote set-head automatically","fromName":"Bence Ferdinandy","fromEmail":"bence@ferdinandy.com","sentAt":"2025-01-12T08:19:39Z","receivedAt":"2025-01-12T08:25:12Z","isPatch":false,"sender":{"key":"bence@ferdinandy.com","avatar":"https://avatars.githubusercontent.com/u/6343487?v=4"},"body":"\nOn Tue Nov 19, 2024 at 16:40, Caleb Cushing wrote:\n> sounds great. I think I realized why I didn't have it. It's not done\n> by `git remote add https://...` my experiment was `git\n> remote rm origin` and then `git remote add origin ... ; git fetch\n> --all --prune` I think I also tried without the prune option. git\n> version 2.46.1\n>\n> What I want mostly is for that HEAD ref to always exist. As far as\n> there being ways to configure it, that's all good but I don't want to\n> explain doing that to consumers of my code. I'd rather it just work\n> for them, on clones, and add remotes or fetch if it's missing.\n>\n> I'm not super worried about it being updated as I feel like if that\n> ever happens it's something loudly communicated, and I'm more willing\n> to find it ok to make that an FAQ, if this breaks because that changed\n> you can manually update that. Mostly I'm of the opinion that what I'm\n> doing needs to work in various CI environments out of the box.\n>\n> Thanks for the info, hopefully soon (tm).\n\nIt's in the new release now, it also got some configuration options, but the\ndefault should be what you want\n\nhttps://git-scm.com/docs/git-config#Documentation/git-config.txt-remoteltnamegtfollowRemoteHEAD\n\nBest,\nBence\n"}]}