{"thread":{"id":"37665","subject":"Can I fetch an arbitrary commit by sha1?","startedAt":"2014-10-02T13:57:45Z","lastAt":"2014-10-09T18:08:06Z","messageCount":12,"participants":["Christian Halstrick","Dan Johnson","Jeff King","Jonathan Nieder","Patrick Donnelly","David Lang","Duy Nguyen","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"250169","messageId":"CAENte7htO13s91UJFNzW4aBhsGxE=LpnvaZfce+vqQU5+a-cYg@mail.gmail.com","threadId":"37665","inReplyTo":null,"subject":"Can I fetch an arbitrary commit by sha1?","fromName":"Christian Halstrick","fromEmail":"christian.halstrick@gmail.com","sentAt":"2014-10-02T13:57:45Z","receivedAt":"2014-10-02T13:57:45Z","isPatch":false,"sender":{"key":"christian.halstrick@gmail.com","avatar":"https://gravatar.com/avatar/3598bf518644c7dc32d4dcd8e0554b6a313e12103011862402c83ae2854203ce?d=mp&s=160"},"body":"I always though during fetch I have to specify a refspec and that a\nsha1 would not be accepted as a ref. Firing some like 'git fetch\norigin <sha1>' should be forbidden. But in fact I see that such a\nfetch command succeeds if you already have that object in your local\nrepo.\n\nMy question: is it allowed to fetch sha1's? Shouldn't fetch fail if you try it?\n\nSee here:\n\n> git clone -q https://github.com/chalstrick/dondalfi.git\n> cd dondalfi\n> git ls-remote\nFrom https://github.com/chalstrick/dondalfi.git\nce08dcc41104383f3cca2b95bd41e9054a957f5b HEAD\naf00f4c39bcc8dc29ed8f59a47066d5993c279e4 refs/foo/b1\n...\n> git show af00f4c39bcc8dc29ed8f59a47066d5993c279e4\nfatal: bad object af00f4c39bcc8dc29ed8f59a47066d5993c279e4\n> git fetch origin af00f4c39bcc8dc29ed8f59a47066d5993c279e4\nerror: no such remote ref af00f4c39bcc8dc29ed8f59a47066d5993c279e4\n> git fetch origin refs/foo/b1\nremote: Counting objects: 3, done.\nremote: Compressing objects: 100% (2/2), done.\nremote: Total 3 (delta 0), reused 0 (delta 0)\nUnpacking objects: 100% (3/3), done.\nFrom https://github.com/chalstrick/dondalfi\n * branch            refs/foo/b1 -> FETCH_HEAD\n> git fetch origin af00f4c39bcc8dc29ed8f59a47066d5993c279e4\nFrom https://github.com/chalstrick/dondalfi\n * branch            af00f4c39bcc8dc29ed8f59a47066d5993c279e4 -> FETCH_HEAD\n\nCiao\n  Chris\n"},{"id":"250171","messageId":"CAPBPrnsA4KxNximtKXcC37kuwBHK0Esytdm4nsgLHkrJSg3Ufw@mail.gmail.com","threadId":"37665","inReplyTo":"CAENte7htO13s91UJFNzW4aBhsGxE=LpnvaZfce+vqQU5+a-cYg@mail.gmail.com","subject":"Re: Can I fetch an arbitrary commit by sha1?","fromName":"Dan Johnson","fromEmail":"computerdruid@gmail.com","sentAt":"2014-10-02T14:22:50Z","receivedAt":"2014-10-02T14:22:50Z","isPatch":false,"sender":{"key":"computerdruid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/34696?v=4"},"body":"On Thu, Oct 2, 2014 at 9:57 AM, Christian Halstrick\n<christian.halstrick@gmail.com> wrote:\n> I always though during fetch I have to specify a refspec and that a\n> sha1 would not be accepted as a ref. Firing some like 'git fetch\n> origin <sha1>' should be forbidden. But in fact I see that such a\n> fetch command succeeds if you already have that object in your local\n> repo.\n>\n> My question: is it allowed to fetch sha1's? Shouldn't fetch fail if you try it?\n>\n> See here:\n>\n>> git clone -q https://github.com/chalstrick/dondalfi.git\n>> cd dondalfi\n>> git ls-remote\n> From https://github.com/chalstrick/dondalfi.git\n> ce08dcc41104383f3cca2b95bd41e9054a957f5b HEAD\n> af00f4c39bcc8dc29ed8f59a47066d5993c279e4 refs/foo/b1\n> ...\n>> git show af00f4c39bcc8dc29ed8f59a47066d5993c279e4\n> fatal: bad object af00f4c39bcc8dc29ed8f59a47066d5993c279e4\n>> git fetch origin af00f4c39bcc8dc29ed8f59a47066d5993c279e4\n> error: no such remote ref af00f4c39bcc8dc29ed8f59a47066d5993c279e4\n>> git fetch origin refs/foo/b1\n> remote: Counting objects: 3, done.\n> remote: Compressing objects: 100% (2/2), done.\n> remote: Total 3 (delta 0), reused 0 (delta 0)\n> Unpacking objects: 100% (3/3), done.\n> From https://github.com/chalstrick/dondalfi\n>  * branch            refs/foo/b1 -> FETCH_HEAD\n>> git fetch origin af00f4c39bcc8dc29ed8f59a47066d5993c279e4\n> From https://github.com/chalstrick/dondalfi\n>  * branch            af00f4c39bcc8dc29ed8f59a47066d5993c279e4 -> FETCH_HEAD\n\nMy understanding is that you are allowed to ask for a SHA1, but most\ngit servers refuse the request. But if you already have the SHA\nlocally, then git doesn't neet to bother asking the server for it, so\nthere's no request to be refused.\n\nBut it's been a while for me since I did any git development, so it's\npossible I missed something.\n\n-Dan\n"},{"id":"250173","messageId":"20141002161006.GB2505@peff.net","threadId":"37665","inReplyTo":"CAPBPrnsA4KxNximtKXcC37kuwBHK0Esytdm4nsgLHkrJSg3Ufw@mail.gmail.com","subject":"Re: Can I fetch an arbitrary commit by sha1?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-10-02T16:10:06Z","receivedAt":"2014-10-02T16:10:06Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 02, 2014 at 10:22:50AM -0400, Dan Johnson wrote:\n\n> >> git show af00f4c39bcc8dc29ed8f59a47066d5993c279e4\n> > fatal: bad object af00f4c39bcc8dc29ed8f59a47066d5993c279e4\n> >> git fetch origin af00f4c39bcc8dc29ed8f59a47066d5993c279e4\n> > error: no such remote ref af00f4c39bcc8dc29ed8f59a47066d5993c279e4\n> >> git fetch origin refs/foo/b1\n> > remote: Counting objects: 3, done.\n> > remote: Compressing objects: 100% (2/2), done.\n> > remote: Total 3 (delta 0), reused 0 (delta 0)\n> > Unpacking objects: 100% (3/3), done.\n> > From https://github.com/chalstrick/dondalfi\n> >  * branch            refs/foo/b1 -> FETCH_HEAD\n> >> git fetch origin af00f4c39bcc8dc29ed8f59a47066d5993c279e4\n> > From https://github.com/chalstrick/dondalfi\n> >  * branch            af00f4c39bcc8dc29ed8f59a47066d5993c279e4 -> FETCH_HEAD\n> \n> My understanding is that you are allowed to ask for a SHA1, but most\n> git servers refuse the request. But if you already have the SHA\n> locally, then git doesn't neet to bother asking the server for it, so\n> there's no request to be refused.\n\nThat's right. It is the server which enforces the \"you cannot fetch an\narbitrary sha1\" rule.\n\nBut I think Christian is arguing that the client side should complain\nthat $sha1 is not a remote ref, and therefore not something we can\nfetch.  This used to be the behavior until 6e7b66e (fetch: fetch objects\nby their exact SHA-1 object names, 2013-01-29). The idea there is that\nsome refs may be kept \"hidden\" from the ref advertisement, but clients\nwho learn about the sha1 out-of-band may fetch the tips of hidden refs.\n\nI'm not sure it is a feature that has been particularly well-used to\ndate, though.\n\n-Peff\n"},{"id":"250175","messageId":"20141002173551.GA12591@google.com","threadId":"37665","inReplyTo":"20141002161006.GB2505@peff.net","subject":"Re: Can I fetch an arbitrary commit by sha1?","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2014-10-02T17:35:51Z","receivedAt":"2014-10-02T17:35:51Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Jeff King wrote:\n\n> But I think Christian is arguing that the client side should complain\n> that $sha1 is not a remote ref, and therefore not something we can\n> fetch.  This used to be the behavior until 6e7b66e (fetch: fetch objects\n> by their exact SHA-1 object names, 2013-01-29). The idea there is that\n> some refs may be kept \"hidden\" from the ref advertisement, but clients\n> who learn about the sha1 out-of-band may fetch the tips of hidden refs.\n>\n> I'm not sure it is a feature that has been particularly well-used to\n> date, though.\n\nI use it pretty often.  The commits I'm fetching are pointed to\ndirectly by refs, but I don't care about what the ref is called and I\nwant exactly that commit.\n\nThe context is that the commit is mentioned in the gerrit web UI.\nFetching by commit name feels simpler than getting the\nrefs/changes/something ref, since I think in terms of commits instead\nof in terms of change numbers.\n\nThanks and hope that helps,\nJonathan\n"},{"id":"250260","messageId":"CAENte7gQm-Mb=73M9dv=vR+N8y=tUsrhLdrwDu4LxOcEFKNB3g@mail.gmail.com","threadId":"37665","inReplyTo":"20141002173551.GA12591@google.com","subject":"Re: Can I fetch an arbitrary commit by sha1?","fromName":"Christian Halstrick","fromEmail":"christian.halstrick@gmail.com","sentAt":"2014-10-05T20:49:09Z","receivedAt":"2014-10-05T20:49:09Z","isPatch":false,"sender":{"key":"christian.halstrick@gmail.com","avatar":"https://gravatar.com/avatar/3598bf518644c7dc32d4dcd8e0554b6a313e12103011862402c83ae2854203ce?d=mp&s=160"},"body":"I also like the feature of being able to fetch commits by SHA-1. My\nproblem is that it is not clear to end users whether they can fetch\nSHA-1 from a specific server or not. For exactly the same server a\n\"git fetch origin <id-of-commit-x>\" first doesn't work and all of the\nsudden that command works and updates e.g. FETCH_HEAD. That's because\nbetween the first and the second fetch you fetched that commit already\nby fetching a branch.\n\nAnd even if the commit is known only to the local repo then the fetch\nworks. I tried to fetch a commit which I just created locally. And the\noutput is:\n\n> git fetch eclipse 382dfeab0e11bd88388d7195114c046c3ec27d8f\nFrom https://git.eclipse.org/r/jgit/jgit\n * branch            382dfeab0e11bd88388d7195114c046c3ec27d8f -> FETCH_HEAD\n\nThis gives me the impression that that update was triggered by data\ncoming from the server https://git.eclipse.org/r/jgit/jgit. But the\nserver doesn't know the commit. In my eyes the fetch should fail if\nthe server doesn't know the commit.\n\nCiao\n  Chris\n"},{"id":"250269","messageId":"CACh33FpWPuyJRryf6hzbAkqWJMwzz1mLLDDRxEQ0niT2CznTRg@mail.gmail.com","threadId":"37665","inReplyTo":"20141002161006.GB2505@peff.net","subject":"Re: Can I fetch an arbitrary commit by sha1?","fromName":"Patrick Donnelly","fromEmail":"batrick@batbytes.com","sentAt":"2014-10-06T18:25:55Z","receivedAt":"2014-10-06T18:25:55Z","isPatch":false,"sender":{"key":"batrick@batbytes.com","avatar":null},"body":"On Thu, Oct 2, 2014 at 12:10 PM, Jeff King <peff@peff.net> wrote:\n> On Thu, Oct 02, 2014 at 10:22:50AM -0400, Dan Johnson wrote:\n>> My understanding is that you are allowed to ask for a SHA1, but most\n>> git servers refuse the request. But if you already have the SHA\n>> locally, then git doesn't neet to bother asking the server for it, so\n>> there's no request to be refused.\n>\n> That's right. It is the server which enforces the \"you cannot fetch an\n> arbitrary sha1\" rule.\n>\n> But I think Christian is arguing that the client side should complain\n> that $sha1 is not a remote ref, and therefore not something we can\n> fetch.  This used to be the behavior until 6e7b66e (fetch: fetch objects\n> by their exact SHA-1 object names, 2013-01-29). The idea there is that\n> some refs may be kept \"hidden\" from the ref advertisement, but clients\n> who learn about the sha1 out-of-band may fetch the tips of hidden refs.\n>\n> I'm not sure it is a feature that has been particularly well-used to\n> date, though.\n\nThere are efforts in the scientific communities at preserving\nexperimental software and results. One of the things we'd like to do\nis shallow clone a specific sha1 commit from e.g. GitHub. [I think\nGitHub has this disabled though? I haven't been able to get it to\nwork.] I guess this feature was a step in the right direction but it's\nnot usable AFAIK. Tags are not really suitable as they could change\nand there are possible namespace issues.\n\n-- \nPatrick Donnelly\n"},{"id":"250270","messageId":"alpine.DEB.2.02.1410061127080.26324@nftneq.ynat.uz","threadId":"37665","inReplyTo":"CACh33FpWPuyJRryf6hzbAkqWJMwzz1mLLDDRxEQ0niT2CznTRg@mail.gmail.com","subject":"Re: Can I fetch an arbitrary commit by sha1?","fromName":"David Lang","fromEmail":"david@lang.hm","sentAt":"2014-10-06T18:28:41Z","receivedAt":"2014-10-06T18:28:41Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Mon, 6 Oct 2014, Patrick Donnelly wrote:\n\n> There are efforts in the scientific communities at preserving\n> experimental software and results. One of the things we'd like to do\n> is shallow clone a specific sha1 commit from e.g. GitHub. [I think\n> GitHub has this disabled though? I haven't been able to get it to\n> work.] I guess this feature was a step in the right direction but it's\n> not usable AFAIK. Tags are not really suitable as they could change\n> and there are possible namespace issues.\n\nremember that git != github and it's not hard to run your own git server.\n\nif you sign tags, they should be very stable. You do have the namespace issue, \nbut unless you have a lot of different people tagging in the same repository, \nthat shouldn't be an issue (and if you do, can't you use the person's name as \npart of the tag?)\n\nDavid Lang\n"},{"id":"250280","messageId":"CACsJy8B0dbE0C3M0PO-EfaZ_bSxwGJSFVejEGFzjHSOZKOc+Jw@mail.gmail.com","threadId":"37665","inReplyTo":"CACh33FpWPuyJRryf6hzbAkqWJMwzz1mLLDDRxEQ0niT2CznTRg@mail.gmail.com","subject":"Re: Can I fetch an arbitrary commit by sha1?","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2014-10-07T12:34:36Z","receivedAt":"2014-10-07T12:34:36Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Oct 7, 2014 at 1:25 AM, Patrick Donnelly <batrick@batbytes.com> wrote:\n> On Thu, Oct 2, 2014 at 12:10 PM, Jeff King <peff@peff.net> wrote:\n>> On Thu, Oct 02, 2014 at 10:22:50AM -0400, Dan Johnson wrote:\n>>> My understanding is that you are allowed to ask for a SHA1, but most\n>>> git servers refuse the request. But if you already have the SHA\n>>> locally, then git doesn't neet to bother asking the server for it, so\n>>> there's no request to be refused.\n>>\n>> That's right. It is the server which enforces the \"you cannot fetch an\n>> arbitrary sha1\" rule.\n>>\n>> But I think Christian is arguing that the client side should complain\n>> that $sha1 is not a remote ref, and therefore not something we can\n>> fetch.  This used to be the behavior until 6e7b66e (fetch: fetch objects\n>> by their exact SHA-1 object names, 2013-01-29). The idea there is that\n>> some refs may be kept \"hidden\" from the ref advertisement, but clients\n>> who learn about the sha1 out-of-band may fetch the tips of hidden refs.\n>>\n>> I'm not sure it is a feature that has been particularly well-used to\n>> date, though.\n>\n> There are efforts in the scientific communities at preserving\n> experimental software and results. One of the things we'd like to do\n> is shallow clone a specific sha1 commit\n\nYou're not the first one asking about making a shallow clone from from\na specific point. I think the reason fetching from arbitrary sha-1 is\nnot supported is because of security. If we can verify the asked sha-1\nis reachable from the visible ref set, then we should allow it. With\npack bitmaps, it's getting much cheaper to do such a test. If pack\nbitmaps are not used, we could set a default/configurable limit, like\nnot traversing more than 1000 commits from any ref for this\nreachability test). Anybody objecting this approach?\n-- \nDuy\n"},{"id":"250281","messageId":"20141007131257.GA24348@lanh","threadId":"37665","inReplyTo":"CACsJy8B0dbE0C3M0PO-EfaZ_bSxwGJSFVejEGFzjHSOZKOc+Jw@mail.gmail.com","subject":"Re: Can I fetch an arbitrary commit by sha1?","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2014-10-07T13:12:57Z","receivedAt":"2014-10-07T13:12:57Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Oct 07, 2014 at 07:34:36PM +0700, Duy Nguyen wrote:\n> If we can verify the asked sha-1 is reachable from the visible ref\n> set, then we should allow it. With pack bitmaps, it's getting much\n> cheaper to do such a test. If pack bitmaps are not used, we could\n> set a default/configurable limit, like not traversing more than 1000\n> commits from any ref for this reachability test).\n\nHmm.. Junio already did most of the work in 051e400 (helping\nsmart-http/stateless-rpc fetch race - 2011-08-05), so all we need to\ndo is enable uploadpack.allowtipsha1inwant and apply this patch\n\n-- 8< --\ndiff --git a/upload-pack.c b/upload-pack.c\nindex c789ec0..493f8ee 100644\n--- a/upload-pack.c\n+++ b/upload-pack.c\n@@ -454,10 +454,6 @@ static void check_non_tip(void)\n \tchar namebuf[42]; /* ^ + SHA-1 + LF */\n \tint i;\n \n-\t/* In the normal in-process case non-tip request can never happen */\n-\tif (!stateless_rpc)\n-\t\tgoto error;\n-\n \tcmd.argv = argv;\n \tcmd.git_cmd = 1;\n \tcmd.no_stderr = 1;\n-- 8< --\n\nIf we already let smart-http do this, I don't see any harm in letting\ngit protocol do the same (even though it's the the original reason why\nthis code exists).\n--\nDuy\n"},{"id":"250289","messageId":"xmqqwq8bizzi.fsf@gitster.dls.corp.google.com","threadId":"37665","inReplyTo":"20141007131257.GA24348@lanh","subject":"Re: Can I fetch an arbitrary commit by sha1?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-10-07T16:52:33Z","receivedAt":"2014-10-07T16:52:33Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Duy Nguyen <pclouds@gmail.com> writes:\n\n> Hmm.. Junio already did most of the work in 051e400 (helping\n> smart-http/stateless-rpc fetch race - 2011-08-05), so all we need to\n> do is enable uploadpack.allowtipsha1inwant and apply this patch\n\nNot that patch, I would think.\n\nI would understand \"if !stateless_rpc and !allowtipsha1 then it is\nan error\", though.\n\n> -- 8< --\n> diff --git a/upload-pack.c b/upload-pack.c\n> index c789ec0..493f8ee 100644\n> --- a/upload-pack.c\n> +++ b/upload-pack.c\n> @@ -454,10 +454,6 @@ static void check_non_tip(void)\n>  \tchar namebuf[42]; /* ^ + SHA-1 + LF */\n>  \tint i;\n>  \n> -\t/* In the normal in-process case non-tip request can never happen */\n> -\tif (!stateless_rpc)\n> -\t\tgoto error;\n> -\n>  \tcmd.argv = argv;\n>  \tcmd.git_cmd = 1;\n>  \tcmd.no_stderr = 1;\n> -- 8< --\n>\n> If we already let smart-http do this, I don't see any harm in letting\n> git protocol do the same (even though it's the the original reason why\n> this code exists).\n> --\n> Duy\n"},{"id":"250356","messageId":"20141008133029.GA23010@lanh","threadId":"37665","inReplyTo":"xmqqwq8bizzi.fsf@gitster.dls.corp.google.com","subject":"Re: Can I fetch an arbitrary commit by sha1?","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2014-10-08T13:30:29Z","receivedAt":"2014-10-08T13:30:29Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Oct 07, 2014 at 09:52:33AM -0700, Junio C Hamano wrote:\n> Duy Nguyen <pclouds@gmail.com> writes:\n> \n> > Hmm.. Junio already did most of the work in 051e400 (helping\n> > smart-http/stateless-rpc fetch race - 2011-08-05), so all we need to\n> > do is enable uploadpack.allowtipsha1inwant and apply this patch\n> \n> Not that patch, I would think.\n> \n> I would understand \"if !stateless_rpc and !allowtipsha1 then it is\n> an error\", though.\n\nFair enough. It seems to work, technically, using the patch below. But\nI think people would rather have support from \"git clone\" and \"git\nclone --branch\" can't deal with SHA-1 this way yet. And --branch might\nbe a bad place to enable this..\n\nSo it needs more work. Any help is appreciated, as I still need to\nfinish my untracked cache series first and re-evaluate watchman series\nbefore git 3.0 is released.\n\n-- 8< --\ndiff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh\nindex 67e0ab3..bdc121e 100755\n--- a/t/t5516-fetch-push.sh\n+++ b/t/t5516-fetch-push.sh\n@@ -1277,4 +1277,22 @@ EOF\n \tgit push --no-thin --receive-pack=\"$rcvpck\" no-thin/.git refs/heads/master:refs/heads/foo\n '\n \n+test_expect_success 'shallow fetch reachable SHA1 (but not a ref)' '\n+\tmk_empty testrepo &&\n+\t(\n+\t\tcd testrepo &&\n+\t\ttest_commit foo &&\n+\t\ttest_commit bar\n+\t) &&\n+\tSHA1=`git --git-dir=testrepo/.git rev-parse HEAD^` &&\n+\tgit init shallow &&\n+\t(\n+\t\tcd shallow &&\n+\t\ttest_must_fail git fetch --depth=1 ../testrepo/.git $SHA1 &&\n+\t\tgit --git-dir=../testrepo/.git config uploadpack.allowtipsha1inwant true &&\n+\t\tgit fetch --depth=1 ../testrepo/.git $SHA1 &&\n+\t\tgit cat-file commit $SHA1 >/dev/null\n+\t)\n+'\n+\n test_done\ndiff --git a/upload-pack.c b/upload-pack.c\nindex c789ec0..4a9a656 100644\n--- a/upload-pack.c\n+++ b/upload-pack.c\n@@ -454,8 +454,12 @@ static void check_non_tip(void)\n \tchar namebuf[42]; /* ^ + SHA-1 + LF */\n \tint i;\n \n-\t/* In the normal in-process case non-tip request can never happen */\n-\tif (!stateless_rpc)\n+\t/*\n+\t * In the normal in-process case without\n+\t * uploadpack.allowtipsha1inwant, non-tip requests can never\n+\t * happen\n+\t */\n+\tif (!stateless_rpc && !allow_tip_sha1_in_want)\n \t\tgoto error;\n \n \tcmd.argv = argv;\n-- 8< --\n"},{"id":"250432","messageId":"xmqqppe16rqx.fsf@gitster.dls.corp.google.com","threadId":"37665","inReplyTo":"20141008133029.GA23010@lanh","subject":"Re: Can I fetch an arbitrary commit by sha1?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-10-09T18:08:06Z","receivedAt":"2014-10-09T18:08:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Duy Nguyen <pclouds@gmail.com> writes:\n\n> On Tue, Oct 07, 2014 at 09:52:33AM -0700, Junio C Hamano wrote:\n>> Duy Nguyen <pclouds@gmail.com> writes:\n>> \n>> > Hmm.. Junio already did most of the work in 051e400 (helping\n>> > smart-http/stateless-rpc fetch race - 2011-08-05), so all we need to\n>> > do is enable uploadpack.allowtipsha1inwant and apply this patch\n>> \n>> Not that patch, I would think.\n>> \n>> I would understand \"if !stateless_rpc and !allowtipsha1 then it is\n>> an error\", though.\n>\n> Fair enough. It seems to work, technically, using the patch below. But\n> I think people would rather have support from \"git clone\" and \"git\n> clone --branch\" can't deal with SHA-1 this way yet. And --branch might\n> be a bad place to enable this..\n>\n> So it needs more work.\n\nThis is so non-standard a thing to do that I doubt it is worth\nsupporting with \"git clone\".  \"git clone --branch\", which is about\n\"I want to follow that particular branch\", would not mesh well with\n\"I want to see the history that leads to this exact commit\", either.\nYou would not know which branch(es) is that exact commit is on in\nthe first place.\n\nI would not say that \"git archive\" is sufficient, however, as \"I\nwant to see the history that leads to the commit\" is different from\n\"I want to grab the state recorded at that commit\".\n\nThe \"uploadpack.allowtipsha1inwant\" is a wrong configuration to tie\nthis into.  The intent of the configuration is to allow *ONLY*\ncommits at the tip of the (possibly hidden) refs to be asked for.\nThose who want to hide some refs using \"uploadpack.hiderefs\" may\nwant to enable \"allowtipsha1inwant\" to allow the tips of the hidden\nrefs while still disallowing a request to fetch any random reachable\ncommit not at the tip.\n\nThe \"check_non_tip()\" hack is a work-around for the deficiency of\nthe smart HTTP protocol (the tips of the refs the client reads off\nof the server end are not the tips of the refs the serving server\nverifies against the request due to information loss between the two\nprocesses at the server end), and is not necessary for the proper\nGit transport, where the server who first grabbed its tips of refs\nand advertised them will know what it advertised and can expect the\nrequest to come back asking exactly for those refs, not random\nancestors of those refs.\n\nThis new feature needs to be enabled with a different configuration\nvariable, perhaps \"uploadpack.allownontipsha1inwant\".  It has\nassociated cost of having to walk back the history to check the\nreachability.\n\nThanks.\n"}]}