{"thread":{"id":"28715","subject":"Git --reference bug(?)","startedAt":"2011-10-18T22:04:09Z","lastAt":"2011-10-19T06:55:50Z","messageCount":6,"participants":["Andrea Gelmini","Michael Haggerty","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"177970","messageId":"CAK-xaQaUxJ5c_kN48g7-J9fosDv6awbAFQSFLpF2fA+hc-i-MA@mail.gmail.com","threadId":"28715","inReplyTo":null,"subject":"Git --reference bug(?)","fromName":"Andrea Gelmini","fromEmail":"andrea.gelmini@gmail.com","sentAt":"2011-10-18T22:04:09Z","receivedAt":"2011-10-18T22:04:09Z","isPatch":false,"sender":{"key":"andrea.gelmini@gmail.com","avatar":null},"body":"Hi Michael,\n and thanks a lot for your time on Git.\n I have a problem with latest Git tree:\n\ngit clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git\n/tmp/3.1 --reference /home/gelma/dev/kernel/linus/\nCloning into /tmp/3.1...\nfatal: Reference has invalid format: 'refs/tags/3.1.1.1^{}'\nfatal: The remote end hung up unexpectedly\n\n It works with Ubuntu Git version 1.7.4.1, of course.\n\n Well, bisecting I've got this:\n\ndce4bab6567de7c458b334e029e3dedcab5f2648 is the first bad commit\ncommit dce4bab6567de7c458b334e029e3dedcab5f2648\nAuthor: Michael Haggerty \nDate: Thu Sep 15 23:10:43 2011 +0200\n\n add_ref(): verify that the refname is formatted correctly\n\n In add_ref(), verify that the refname is formatted correctly before\n adding it to the ref_list. Here we have to allow refname components\n that start with \".\", since (for example) the remote protocol uses\n synthetic reference name \".have\". So add a new REFNAME_DOT_COMPONENT\n flag that can be passed to check_refname_format() to allow leading\n dots.\n\n Signed-off-by: Michael Haggerty \n Signed-off-by: Junio C Hamano \n\n:100644 100644 096b42c5e993193dd83a02128be4b90ebc59edd1\n832a52f7818369bca969d49317718714a5bcabac M\trefs.c\n:100644 100644 b0da5fc95dff025a8dd5c1f299ee25efc6141e81\nd5ac133336dc0da45cd916207d12a5e0e4237ae3 M\trefs.h\nbisect run success\n\ngit bisect log\ngit bisect start\n# bad: [85bb77ed056057b727ba8dc7965fbfcde987d189] Merge branch\n'master' of git://git.kernel.org/pub/scm/git/git\ngit bisect bad 85bb77ed056057b727ba8dc7965fbfcde987d189\n# good: [9971d6d52c5afeb8ba60ae6ddcffb34af23eeadd] Git 1.7.4.1\ngit bisect good 9971d6d52c5afeb8ba60ae6ddcffb34af23eeadd\n# good: [456a4c08b8d8ddefda939014c15877ace3e3f499] Merge branch\n'jk/diff-not-so-quick'\ngit bisect good 456a4c08b8d8ddefda939014c15877ace3e3f499\n# good: [18dce8d4226c56b10d2b783b476008117d60a23e] Merge branch\n'master' of git://git.kernel.org/pub/scm/git/git\ngit bisect good 18dce8d4226c56b10d2b783b476008117d60a23e\n# good: [821b315ebebd5371abd9124478261064b36a6592] Merge branch\n'da/make-auto-header-dependencies'\ngit bisect good 821b315ebebd5371abd9124478261064b36a6592\n# bad: [e579a5d398744e8182decff1329c468d59e6974c] Merge branch\n'mh/maint-notes-merge-pathbuf-fix'\ngit bisect bad e579a5d398744e8182decff1329c468d59e6974c\n# good: [17e2b114a8f9d66d7c9263755f89cc503c94c38c] Merge branch\n'jn/gitweb-highlite-sanitise'\ngit bisect good 17e2b114a8f9d66d7c9263755f89cc503c94c38c\n# good: [5fbdb9c2e8cc7226d9a9e7de5ad09ac5f0a0b906] Merge branch\n'jm/mergetool-pathspec'\ngit bisect good 5fbdb9c2e8cc7226d9a9e7de5ad09ac5f0a0b906\n# good: [f989fea0e0b47873de62a355f4766f03a88fb01b] resolve_ref(): also\ntreat a too-long SHA1 as invalid\ngit bisect good f989fea0e0b47873de62a355f4766f03a88fb01b\n# bad: [9bd500048d467791902b1a5e8c22165325952fde] Merge branch\n'mh/check-ref-format-3'\ngit bisect bad 9bd500048d467791902b1a5e8c22165325952fde\n# good: [ce40979cf83c4c92421f9dd56cc4eabb67c85f29] Store the submodule\nname in struct cached_refs\ngit bisect good ce40979cf83c4c92421f9dd56cc4eabb67c85f29\n# good: [11fa509957025cc30c063d75014b701dd9ae235d] Merge branch\n'mh/iterate-refs'\ngit bisect good 11fa509957025cc30c063d75014b701dd9ae235d\n# bad: [dce4bab6567de7c458b334e029e3dedcab5f2648] add_ref(): verify\nthat the refname is formatted correctly\ngit bisect bad dce4bab6567de7c458b334e029e3dedcab5f2648\n# good: [7cb368421f62318f2c0f0e19a83ca34c201aebaa] resolve_ref():\nexpand documentation\ngit bisect good 7cb368421f62318f2c0f0e19a83ca34c201aebaa\n\n If I revert it, everything's ok.\n\nThanks a lot,\nAndrea Gelmini\n"},{"id":"177980","messageId":"4E9E59A7.7070307@alum.mit.edu","threadId":"28715","inReplyTo":"CAK-xaQaUxJ5c_kN48g7-J9fosDv6awbAFQSFLpF2fA+hc-i-MA@mail.gmail.com","subject":"Re: Git --reference bug(?)","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2011-10-19T05:01:27Z","receivedAt":"2011-10-19T05:01:27Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 10/19/2011 12:04 AM, Andrea Gelmini wrote:\n> git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git\n> /tmp/3.1 --reference /home/gelma/dev/kernel/linus/\n> Cloning into /tmp/3.1...\n> fatal: Reference has invalid format: 'refs/tags/3.1.1.1^{}'\n> fatal: The remote end hung up unexpectedly\n\nThe upstream repo reports what look like non-reference references:\n\n$ git ls-remote --tags\ngit://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git | head\n5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c\trefs/tags/v2.6.11\nc39ae07f393806ccf406ef966e9a15afc43cc36a\trefs/tags/v2.6.11^{}\n5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c\trefs/tags/v2.6.11-tree\nc39ae07f393806ccf406ef966e9a15afc43cc36a\trefs/tags/v2.6.11-tree^{}\n26791a8bcf0e6d33f43aef7682bdb555236d56de\trefs/tags/v2.6.12\n9ee1c939d1cb936b1f98e8d81aeffab57bae46ab\trefs/tags/v2.6.12^{}\n9e734775f7c22d2f89943ad6c745571f1930105f\trefs/tags/v2.6.12-rc2\n1da177e4c3f41524e886b7f1b8a0c1fc7321cac2\trefs/tags/v2.6.12-rc2^{}\n0397236d43e48e821cce5bbe6a80a1a56bb7cc3a\trefs/tags/v2.6.12-rc3\na2755a80f40e5794ddc20e00f781af9d6320fafb\trefs/tags/v2.6.12-rc3^{}\n[...]\n\nI've never seen this format before; is this the remote protocol for\npeeled refs or maybe the behavior of an old version of git?\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"177983","messageId":"7vpqhtec2n.fsf@alter.siamese.dyndns.org","threadId":"28715","inReplyTo":"4E9E59A7.7070307@alum.mit.edu","subject":"Re: Git --reference bug(?)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-10-19T06:21:20Z","receivedAt":"2011-10-19T06:21:20Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael Haggerty writes:\n\n> On 10/19/2011 12:04 AM, Andrea Gelmini wrote:\n>> git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git\n>> /tmp/3.1 --reference /home/gelma/dev/kernel/linus/\n>> Cloning into /tmp/3.1...\n>> fatal: Reference has invalid format: 'refs/tags/3.1.1.1^{}'\n>> fatal: The remote end hung up unexpectedly\n>\n> The upstream repo reports what look like non-reference references:\n>\n> $ git ls-remote --tags\n> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git | head\n> 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c\trefs/tags/v2.6.11\n> c39ae07f393806ccf406ef966e9a15afc43cc36a\trefs/tags/v2.6.11^{}\n> 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c\trefs/tags/v2.6.11-tree\n> c39ae07f393806ccf406ef966e9a15afc43cc36a\trefs/tags/v2.6.11-tree^{}\n> 26791a8bcf0e6d33f43aef7682bdb555236d56de\trefs/tags/v2.6.12\n> 9ee1c939d1cb936b1f98e8d81aeffab57bae46ab\trefs/tags/v2.6.12^{}\n> 9e734775f7c22d2f89943ad6c745571f1930105f\trefs/tags/v2.6.12-rc2\n> 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2\trefs/tags/v2.6.12-rc2^{}\n> 0397236d43e48e821cce5bbe6a80a1a56bb7cc3a\trefs/tags/v2.6.12-rc3\n> a2755a80f40e5794ddc20e00f781af9d6320fafb\trefs/tags/v2.6.12-rc3^{}\n> [...]\n>\n> I've never seen this format before; is this the remote protocol for\n> peeled refs or maybe the behavior of an old version of git?\n\nThis should be very well documented and has been the output from fairly\nearly days of ls-remote.\n"},{"id":"177984","messageId":"7vipnlebwb.fsf@alter.siamese.dyndns.org","threadId":"28715","inReplyTo":"7vpqhtec2n.fsf@alter.siamese.dyndns.org","subject":"Re: Git --reference bug(?)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-10-19T06:25:08Z","receivedAt":"2011-10-19T06:25:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n>> 0397236d43e48e821cce5bbe6a80a1a56bb7cc3a\trefs/tags/v2.6.12-rc3\n>> a2755a80f40e5794ddc20e00f781af9d6320fafb\trefs/tags/v2.6.12-rc3^{}\n>> [...]\n>>\n>> I've never seen this format before; is this the remote protocol for\n>> peeled refs or maybe the behavior of an old version of git?\n>\n> This should be very well documented and has been the output from fairly\n> early days of ls-remote.\n\nI take the first half back. The ls-remote documentation seems to have\nbit-rotten quite a bit.\n\nIIRC, we started doing this when we introduced auto-following of the tag\nobjects. Even update-server-info knows about it so it way predates smart\nHTTP and is a fairly old and established behaviour.\n"},{"id":"177985","messageId":"7v8vohebhx.fsf@alter.siamese.dyndns.org","threadId":"28715","inReplyTo":"7vipnlebwb.fsf@alter.siamese.dyndns.org","subject":"Re: Git --reference bug(?)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-10-19T06:33:46Z","receivedAt":"2011-10-19T06:33:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Junio C Hamano writes:\n>\n>>> 0397236d43e48e821cce5bbe6a80a1a56bb7cc3a\trefs/tags/v2.6.12-rc3\n>>> a2755a80f40e5794ddc20e00f781af9d6320fafb\trefs/tags/v2.6.12-rc3^{}\n>>> [...]\n>>>\n>>> I've never seen this format before; is this the remote protocol for\n>>> peeled refs or maybe the behavior of an old version of git?\n>>\n>> This should be very well documented and has been the output from fairly\n>> early days of ls-remote.\n>\n> I take the first half back. The ls-remote documentation seems to have\n> bit-rotten quite a bit.\n>\n> IIRC, we started doing this when we introduced auto-following of the tag\n> objects. Even update-server-info knows about it so it way predates smart\n> HTTP and is a fairly old and established behaviour.\n\nIn addition, you must be careful about what is added with add_extra_ref();\nthey are often not refs but are placeholders for Git to know that the\nhistory leading to it is complete, even though they do not exist as\nrefs. The values of real refs that exist in your alternate object store\nare treated this way, because you know you do not have to fetch (if you\nare initiating fetch-pack) or receive (if the other side is initiating\nsend-pack) histories leading to them from the other side.\n"},{"id":"177988","messageId":"7v4nz5eah5.fsf@alter.siamese.dyndns.org","threadId":"28715","inReplyTo":"7v8vohebhx.fsf@alter.siamese.dyndns.org","subject":"Re: Git --reference bug(?)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-10-19T06:55:50Z","receivedAt":"2011-10-19T06:55:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Junio C Hamano writes:\n>\n> In addition, you must be careful about what is added with add_extra_ref();\n> they are often not refs but are placeholders for Git to know that the\n> history leading to it is complete, even though they do not exist as\n> refs. The values of real refs that exist in your alternate object store\n> are treated this way, because you know you do not have to fetch (if you\n> are initiating fetch-pack) or receive (if the other side is initiating\n> send-pack) histories leading to them from the other side.\n\nI think a quick and simple rule would be that add_extra_ref() is to give\nour history in the object database extra anchor points to avoid fetching\nor receiving pushes of unnecessary history into our object database, when\nwe know our object database has certain histories that are not reachable\nfrom our own refs available. The names given to add_extra_ref() would not\nfollow any normal refname rules (in fact, \"refs/tags/v2.6.12-rc3^{}\"\npeeled notation was designed not to collide with real refs, so was \".have\"\nsent from receive-pack.c to send-pack.c even though the latter is not kept\ntrack of with the refs mechanism).\n\nThey do not have to be shown when resolve_ref() is called. They only need\nto appear in for_each_ref() so that revision walking machinery can use\nthem when we need to compute the set-difference of commits between what we\nhave and what the other side has.\n\nHope this clears things up a bit.\n"}]}