{"thread":{"id":"61961","subject":"feature request: set remote/HEAD with fetch","startedAt":"2024-08-16T11:59:03Z","lastAt":"2024-08-20T21:39:26Z","messageCount":7,"participants":["Bence Ferdinandy","brian m. carlson","Junio C Hamano","Jeff King","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"501135","messageId":"D3HBD7C1FR14.74FL1Q1S9UCB@ferdinandy.com","threadId":"61961","inReplyTo":null,"subject":"feature request: set remote/HEAD with fetch","fromName":"Bence Ferdinandy","fromEmail":"bence@ferdinandy.com","sentAt":"2024-08-16T11:53:31Z","receivedAt":"2024-08-16T11:59:03Z","isPatch":false,"sender":{"key":"bence@ferdinandy.com","avatar":"https://avatars.githubusercontent.com/u/6343487?v=4"},"body":"Hi,\n\nthis comes after a bit of discussion on #git. The current behaviour of git is\nthat when cloning, `refs/remotes/[remote]/HEAD` is set, but if you use `git\ninit` and `git remote add`, then you must manually run `git remote set-head -a`\nto arrive at the same state. Having origin/HEAD set is pretty useful for\nscripting and aliases, because you don't need to remember what the current\nproject uses (origin/[master|main|trunk|etc]).\n\nI would propose that running `git fetch` should also update remote/HEAD. In\ncase there is a possibility that it is useful in some cases that remote/HEAD is\nactually different from whatever is set in the remote repository as the default\nbranch, I think a setting for opt-out would be better, and the default\nbehaviour should be essentially always running `set-head -a`.\n\nMy current workaround is an alias:\n    fetchall = !git fetch --all && git remote | xargs -i git remote set-head -a {}\n\nwhich works for me, but I think it would be more elegant not to have to do this.\n\nA slight aside: if `refs/remotes/[remote]/HEAD` is set you still might have\na problem of easily accessing the current remote's HEAD, since @{upstream} will\npoint to the branch. It's again not something you can't script around, but\nwould be cool if there were an easy way of avoiding hardcoded \"origin\" in\naliases and scripts.\n\nThanks for considering!\n\nBest,\nBence\n"},{"id":"501162","messageId":"Zr_KtAXQuFwEmFfI@tapette.crustytoothpaste.net","threadId":"61961","inReplyTo":"D3HBD7C1FR14.74FL1Q1S9UCB@ferdinandy.com","subject":"Re: feature request: set remote/HEAD with fetch","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2024-08-16T21:55:00Z","receivedAt":"2024-08-16T21:55:02Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2024-08-16 at 11:53:31, Bence Ferdinandy wrote:\n> Hi,\n> \n> this comes after a bit of discussion on #git. The current behaviour of git is\n> that when cloning, `refs/remotes/[remote]/HEAD` is set, but if you use `git\n> init` and `git remote add`, then you must manually run `git remote set-head -a`\n> to arrive at the same state. Having origin/HEAD set is pretty useful for\n> scripting and aliases, because you don't need to remember what the current\n> project uses (origin/[master|main|trunk|etc]).\n> \n> I would propose that running `git fetch` should also update remote/HEAD. In\n> case there is a possibility that it is useful in some cases that remote/HEAD is\n> actually different from whatever is set in the remote repository as the default\n> branch, I think a setting for opt-out would be better, and the default\n> behaviour should be essentially always running `set-head -a`.\n> \n> My current workaround is an alias:\n>     fetchall = !git fetch --all && git remote | xargs -i git remote set-head -a {}\n> \n> which works for me, but I think it would be more elegant not to have to do this.\n\nI believe this would be a valuable change.  I know a lot of other users\nwant this features as well.  However, I think it needs to be opt-in,\nsince there are some cases where you want `git fetch` to specifically\nfetch only certain objects or don't want to modify the refs. For\nexample, I know some server-side implementations use `git fetch`\ninternally and require refs to be updated in a special way, and they\nwould not appreciate extra refs appearing.\n-- \nbrian m. carlson (they/them or he/him)\nToronto, Ontario, CA\n"},{"id":"501163","messageId":"xmqqplq8jf02.fsf@gitster.g","threadId":"61961","inReplyTo":"Zr_KtAXQuFwEmFfI@tapette.crustytoothpaste.net","subject":"Re: feature request: set remote/HEAD with fetch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-08-16T22:10:21Z","receivedAt":"2024-08-16T22:10:24Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"brian m. carlson\" <sandals@crustytoothpaste.net> writes:\n\n>> My current workaround is an alias:\n>>     fetchall = !git fetch --all && git remote | xargs -i git remote set-head -a {}\n>> \n>> which works for me, but I think it would be more elegant not to have to do this.\n>\n> I believe this would be a valuable change.  I know a lot of other users\n> want this features as well.  However, I think it needs to be opt-in,\n> since there are some cases where you want `git fetch` to specifically\n> fetch only certain objects or don't want to modify the refs. For\n> example, I know some server-side implementations use `git fetch`\n> internally and require refs to be updated in a special way, and they\n> would not appreciate extra refs appearing.\n\nYeah, \"remote set-head\" implementation internally uses the same\n\"what's the current state of the refs on the other side?\" query as\nwhat \"fetch\" does when it contacts the other side, so it makes sense\nfor a new feature \"git fetch --set-head ...\" to internally do what\nis done by \"remote set-head\".\n\nWhat should *not* happen automatically without an opt-in is to\noverwrite an existing refs/remotes/$remote/HEAD with a new value.\nIt might even make sense to allow it to happen, even if the\n\"--set-head\" option is not given from the command line, if\n\"refs/remotes/$remote/HEAD\" does not exist.\n\nThanks.\n\n\n\n\n\n"},{"id":"501177","messageId":"20240817050240.GA29822@coredump.intra.peff.net","threadId":"61961","inReplyTo":"Zr_KtAXQuFwEmFfI@tapette.crustytoothpaste.net","subject":"Re: feature request: set remote/HEAD with fetch","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2024-08-17T05:02:40Z","receivedAt":"2024-08-17T05:09:55Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Aug 16, 2024 at 09:55:00PM +0000, brian m. carlson wrote:\n\n> > I would propose that running `git fetch` should also update remote/HEAD. In\n> > case there is a possibility that it is useful in some cases that remote/HEAD is\n> > actually different from whatever is set in the remote repository as the default\n> > branch, I think a setting for opt-out would be better, and the default\n> > behaviour should be essentially always running `set-head -a`.\n> > \n> > My current workaround is an alias:\n> >     fetchall = !git fetch --all && git remote | xargs -i git remote set-head -a {}\n> > \n> > which works for me, but I think it would be more elegant not to have to do this.\n> \n> I believe this would be a valuable change.  I know a lot of other users\n> want this features as well.  However, I think it needs to be opt-in,\n> since there are some cases where you want `git fetch` to specifically\n> fetch only certain objects or don't want to modify the refs. For\n> example, I know some server-side implementations use `git fetch`\n> internally and require refs to be updated in a special way, and they\n> would not appreciate extra refs appearing.\n\nThere was discussion a while ago that proposed a tri-state config\noption: never update the remote head on fetch, always do so, or add it\nonly when missing:\n\n  https://lore.kernel.org/git/20201118091219.3341585-1-felipe.contreras@gmail.com/\n\nI think that is a good first step, as we could stop there and leave the\ndefault at \"never\" without any compatibility issues (and/or contemplate\na change in the default as a separate step).\n\nI don't think the patch in that thread is likely to go anywhere at this\npoint, but if somebody wanted to pick it up, I think everybody was\npositive on the general direction.\n\n-Peff\n"},{"id":"501230","messageId":"D3IF2EVJPNMX.CFNKJQDPHZQ0@ferdinandy.com","threadId":"61961","inReplyTo":"20240817050240.GA29822@coredump.intra.peff.net","subject":"Re: feature request: set remote/HEAD with fetch","fromName":"Bence Ferdinandy","fromEmail":"bence@ferdinandy.com","sentAt":"2024-08-17T19:00:10Z","receivedAt":"2024-08-17T19:05:43Z","isPatch":false,"sender":{"key":"bence@ferdinandy.com","avatar":"https://avatars.githubusercontent.com/u/6343487?v=4"},"body":"\n> There was discussion a while ago that proposed a tri-state config\n> option: never update the remote head on fetch, always do so, or add it\n> only when missing:\n>\n>   https://lore.kernel.org/git/20201118091219.3341585-1-felipe.contreras@gmail.com/\n\nThanks for linking that, I didn't think about searching for old discussion\nbefore writing ...\n\n>\n> I think that is a good first step, as we could stop there and leave the\n> default at \"never\" without any compatibility issues (and/or contemplate\n> a change in the default as a separate step).\n>\n> I don't think the patch in that thread is likely to go anywhere at this\n> point, but if somebody wanted to pick it up, I think everybody was\n> positive on the general direction.\n\nMy C skills aren't great (probably an overstatement), but if Felipe or somebody\nelse more qualified than me doesn't want to pick this up, I'm willing to give\nit a shot based on the Felipe's patch. It will take some time though :)\n\nThanks,\nBence\n"},{"id":"501286","messageId":"c10652f9-3cf8-e1b3-27f3-63fd5b8ac52a@gmx.de","threadId":"61961","inReplyTo":"D3IF2EVJPNMX.CFNKJQDPHZQ0@ferdinandy.com","subject":"Re: feature request: set remote/HEAD with fetch","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2024-08-19T16:40:11Z","receivedAt":"2024-08-19T16:40:36Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Bence,\n\nOn Sat, 17 Aug 2024, Bence Ferdinandy wrote:\n\n>\n> > There was discussion a while ago that proposed a tri-state config\n> > option: never update the remote head on fetch, always do so, or add it\n> > only when missing:\n> >\n> >   https://lore.kernel.org/git/20201118091219.3341585-1-felipe.contreras@gmail.com/\n>\n> Thanks for linking that, I didn't think about searching for old discussion\n> before writing ...\n\nA better link (in particular because it does not involve a now-banned\nperson) might be\nhttps://lore.kernel.org/git/CANWRddN4R6AceeaOyZm1vs8AXBNv3J+cE5MOyrhKVhcqddjUOA@mail.gmail.com/\n\nThis discussion might not be about that mentioned tri-state, but about the\n\"take a step back\" question: What is the best way to update a\nremote-tracking `HEAD`.\n\n> > I think that is a good first step, as we could stop there and leave the\n> > default at \"never\" without any compatibility issues (and/or contemplate\n> > a change in the default as a separate step).\n> >\n> > I don't think the patch in that thread is likely to go anywhere at this\n> > point, but if somebody wanted to pick it up, I think everybody was\n> > positive on the general direction.\n>\n> My C skills aren't great (probably an overstatement), but if Felipe or somebody\n> else more qualified than me doesn't want to pick this up, I'm willing to give\n> it a shot based on the Felipe's patch. It will take some time though :)\n\nI dropped him from the Cc:, as a consequence of\nhttps://lore.kernel.org/git/ZF%2F38DXNYMsZjvy4@nand.local/.\n\nSince this leaves you in somewhat of a pickle because you probably should\nnot start from those patches, and since you seem to be in the same time\nzone as I am, I'll offer you to pair with you on getting you started. If\nyou are interested, please just reply privately.\n\nCiao,\nJohannes\n"},{"id":"501396","messageId":"D3L2BKO9M1IE.3ADG61CDGXLV2@ferdinandy.com","threadId":"61961","inReplyTo":"c10652f9-3cf8-e1b3-27f3-63fd5b8ac52a@gmx.de","subject":"Re: feature request: set remote/HEAD with fetch","fromName":"Bence Ferdinandy","fromEmail":"bence@ferdinandy.com","sentAt":"2024-08-20T21:38:53Z","receivedAt":"2024-08-20T21:39:26Z","isPatch":false,"sender":{"key":"bence@ferdinandy.com","avatar":"https://avatars.githubusercontent.com/u/6343487?v=4"},"body":"Hey,\n\nOn Mon Aug 19, 2024 at 18:40, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n> https://lore.kernel.org/git/ZF%2F38DXNYMsZjvy4@nand.local/.\n\nwell, _that_ was definitely not something I searched for.\n\n>\n> Since this leaves you in somewhat of a pickle because you probably should\n> not start from those patches, and since you seem to be in the same time\n> zone as I am, I'll offer you to pair with you on getting you started. If\n> you are interested, please just reply privately.\n\nSure, thanks, I'll reach out to you about the details in private.\n\nBest,\nBence\n"}]}