{"thread":{"id":"42376","subject":"git fetch origin $SHA1 doesn't work as often as it could","startedAt":"2016-05-18T20:20:24Z","lastAt":"2016-05-19T01:53:23Z","messageCount":4,"participants":["JP Sugarbroad","Junio C Hamano","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"286926","messageId":"CAD0oC4yQzvAH=6a6Xgy6xOPoYCaO2zsDg5mDySkb6VJ6FdeeEQ@mail.gmail.com","threadId":"42376","inReplyTo":null,"subject":"git fetch origin $SHA1 doesn't work as often as it could","fromName":"JP Sugarbroad","fromEmail":"jpsugar@google.com","sentAt":"2016-05-18T20:20:24Z","receivedAt":"2016-05-18T20:20:24Z","isPatch":false,"sender":{"key":"jpsugar@google.com","avatar":null},"body":"So I'm trying to make cloning the rust repo a little easier, and I\nnoticed there's a new feature to `git submodule update --depth=1` --\nbut it doesn't work for this, even though it could.\n\nReason is that fetch-pack will only fetch by sha1 if the remote\nspecifies allow_tip/unreachable_sha1, even if the sha1 specified\nmatches an advertised ref.\n\nMy thought is to rework filter_refs() to match on oid if matching on\nname fails. Thoughts?\n\n- JP\n"},{"id":"286936","messageId":"xmqq8tz7qb7d.fsf@gitster.mtv.corp.google.com","threadId":"42376","inReplyTo":"CAD0oC4yQzvAH=6a6Xgy6xOPoYCaO2zsDg5mDySkb6VJ6FdeeEQ@mail.gmail.com","subject":"Re: git fetch origin $SHA1 doesn't work as often as it could","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-05-18T21:59:34Z","receivedAt":"2016-05-18T21:59:34Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"JP Sugarbroad <jpsugar@google.com> writes:\n\n> So I'm trying to make cloning the rust repo a little easier, and I\n> noticed there's a new feature to `git submodule update --depth=1` --\n> but it doesn't work for this, even though it could.\n>\n> Reason is that fetch-pack will only fetch by sha1 if the remote\n> specifies allow_tip/unreachable_sha1, even if the sha1 specified\n> matches an advertised ref.\n\nIf a project wants its users to do the 'update --depth=1' thing, it\nshould allow fetching not just from the tip but also reachable.\n\nThe commit from the submodule that is bound to the superproject may\nno longer be sitting at the tip of any branch in the submodule.  The\nhack you are outlining here would not help, and invites \"the feature\nworks some of the time (i.e. the commit happens to be at the tip of\none of the refs) but fails most of the time\" bug reports.\n\nSo I am not enthused, even though at the technical level, I agree\nthat it is a good \"solution\" to pretend as if one of the refs were\nrequested after the fetch-pack discovers the refs advertised by the\nupload-pack.\n\nI just fear that it is a wrong approach to solve the real issue and\ninstead make it worse by relieving the pressure from the project and\nhosting site to configure their repository to support their users\nproperly.\n"},{"id":"286941","messageId":"CAD0oC4wezb8svOW5KHONLi5wQN+H_3xqPLoU_EZbtL5zAkdv_Q@mail.gmail.com","threadId":"42376","inReplyTo":"xmqq8tz7qb7d.fsf@gitster.mtv.corp.google.com","subject":"Re: git fetch origin $SHA1 doesn't work as often as it could","fromName":"JP Sugarbroad","fromEmail":"jpsugar@google.com","sentAt":"2016-05-18T22:40:37Z","receivedAt":"2016-05-18T22:40:37Z","isPatch":false,"sender":{"key":"jpsugar@google.com","avatar":null},"body":"On Wed, May 18, 2016 at 5:59 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> The commit from the submodule that is bound to the superproject may\n> no longer be sitting at the tip of any branch in the submodule.  The\n> hack you are outlining here would not help, and invites \"the feature\n> works some of the time (i.e. the commit happens to be at the tip of\n> one of the refs) but fails most of the time\" bug reports.\n\nSure, that's a reasonable fear. In this case the branches don't move,\nbut if one were concerned about that one could use tags instead. It is\nquite reasonable to point a submodule to a tag and not expect that to\ngo away.\n\n> So I am not enthused, even though at the technical level, I agree\n> that it is a good \"solution\" to pretend as if one of the refs were\n> requested after the fetch-pack discovers the refs advertised by the\n> upload-pack.\n\nIt could also lead to allowing \"git clone -b $SHA\".\n\nIt's possible to implement this today by manually doing the conversion\nvia git ls-remote. This is a significant streamlining that would\ninteract well with the recent change to submodules to attempt \"git\nfetch origin $SHA1\".\n\n> I just fear that it is a wrong approach to solve the real issue and\n> instead make it worse by relieving the pressure from the project and\n> hosting site to configure their repository to support their users\n> properly.\n\nUnfortunately I don't see the likes of github or bitbucket adding\nallow-reachable-sha1-in-want any time soon, as it is an expensive\noperation server-side.\n\nThis is a significant boost to utility of shallow submodules (a flag\nfor which was just recently added to clone), without requiring any\nsignificant changes to repository configuration.\n\n- JP\n"},{"id":"286959","messageId":"20160519015323.GA24225@sigill.intra.peff.net","threadId":"42376","inReplyTo":"CAD0oC4wezb8svOW5KHONLi5wQN+H_3xqPLoU_EZbtL5zAkdv_Q@mail.gmail.com","subject":"Re: git fetch origin $SHA1 doesn't work as often as it could","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-05-19T01:53:23Z","receivedAt":"2016-05-19T01:53:23Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, May 18, 2016 at 06:40:37PM -0400, JP Sugarbroad wrote:\n\n> > I just fear that it is a wrong approach to solve the real issue and\n> > instead make it worse by relieving the pressure from the project and\n> > hosting site to configure their repository to support their users\n> > properly.\n> \n> Unfortunately I don't see the likes of github or bitbucket adding\n> allow-reachable-sha1-in-want any time soon, as it is an expensive\n> operation server-side.\n\nI don't think it's _too_ bad, at least compared to some of the nastier\nthings one can convince the server side of a git fetch to do. It at\nleast looks at just the commits; the bad cases usually involve\ntraversing the whole object graph.\n\nIt's also something that's easily sped up with reachability bitmaps.\n\nBut I haven't done any real analysis on the kind of load it would cause.\nSo no promises, but I don't think it's outside the realm of possibility\nfor GitHub to enable, if it's something that would be useful to a lot of\npeople. I can't speak for Bitbucket. :)\n\n-Peff\n"}]}