* Git --reference bug(?)
@ 2011-10-18 22:04 Andrea Gelmini
2011-10-19 5:01 ` Michael Haggerty
0 siblings, 1 reply; 6+ messages in thread
From: Andrea Gelmini @ 2011-10-18 22:04 UTC (permalink / raw)
To: mhagger; +Cc: gitster, git
Hi Michael,
and thanks a lot for your time on Git.
I have a problem with latest Git tree:
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
/tmp/3.1 --reference /home/gelma/dev/kernel/linus/
Cloning into /tmp/3.1...
fatal: Reference has invalid format: 'refs/tags/3.1.1.1^{}'
fatal: The remote end hung up unexpectedly
It works with Ubuntu Git version 1.7.4.1, of course.
Well, bisecting I've got this:
dce4bab6567de7c458b334e029e3dedcab5f2648 is the first bad commit
commit dce4bab6567de7c458b334e029e3dedcab5f2648
Author: Michael Haggerty <mhagger@alum.mit.edu>
Date: Thu Sep 15 23:10:43 2011 +0200
add_ref(): verify that the refname is formatted correctly
In add_ref(), verify that the refname is formatted correctly before
adding it to the ref_list. Here we have to allow refname components
that start with ".", since (for example) the remote protocol uses
synthetic reference name ".have". So add a new REFNAME_DOT_COMPONENT
flag that can be passed to check_refname_format() to allow leading
dots.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
:100644 100644 096b42c5e993193dd83a02128be4b90ebc59edd1
832a52f7818369bca969d49317718714a5bcabac M refs.c
:100644 100644 b0da5fc95dff025a8dd5c1f299ee25efc6141e81
d5ac133336dc0da45cd916207d12a5e0e4237ae3 M refs.h
bisect run success
git bisect log
git bisect start
# bad: [85bb77ed056057b727ba8dc7965fbfcde987d189] Merge branch
'master' of git://git.kernel.org/pub/scm/git/git
git bisect bad 85bb77ed056057b727ba8dc7965fbfcde987d189
# good: [9971d6d52c5afeb8ba60ae6ddcffb34af23eeadd] Git 1.7.4.1
git bisect good 9971d6d52c5afeb8ba60ae6ddcffb34af23eeadd
# good: [456a4c08b8d8ddefda939014c15877ace3e3f499] Merge branch
'jk/diff-not-so-quick'
git bisect good 456a4c08b8d8ddefda939014c15877ace3e3f499
# good: [18dce8d4226c56b10d2b783b476008117d60a23e] Merge branch
'master' of git://git.kernel.org/pub/scm/git/git
git bisect good 18dce8d4226c56b10d2b783b476008117d60a23e
# good: [821b315ebebd5371abd9124478261064b36a6592] Merge branch
'da/make-auto-header-dependencies'
git bisect good 821b315ebebd5371abd9124478261064b36a6592
# bad: [e579a5d398744e8182decff1329c468d59e6974c] Merge branch
'mh/maint-notes-merge-pathbuf-fix'
git bisect bad e579a5d398744e8182decff1329c468d59e6974c
# good: [17e2b114a8f9d66d7c9263755f89cc503c94c38c] Merge branch
'jn/gitweb-highlite-sanitise'
git bisect good 17e2b114a8f9d66d7c9263755f89cc503c94c38c
# good: [5fbdb9c2e8cc7226d9a9e7de5ad09ac5f0a0b906] Merge branch
'jm/mergetool-pathspec'
git bisect good 5fbdb9c2e8cc7226d9a9e7de5ad09ac5f0a0b906
# good: [f989fea0e0b47873de62a355f4766f03a88fb01b] resolve_ref(): also
treat a too-long SHA1 as invalid
git bisect good f989fea0e0b47873de62a355f4766f03a88fb01b
# bad: [9bd500048d467791902b1a5e8c22165325952fde] Merge branch
'mh/check-ref-format-3'
git bisect bad 9bd500048d467791902b1a5e8c22165325952fde
# good: [ce40979cf83c4c92421f9dd56cc4eabb67c85f29] Store the submodule
name in struct cached_refs
git bisect good ce40979cf83c4c92421f9dd56cc4eabb67c85f29
# good: [11fa509957025cc30c063d75014b701dd9ae235d] Merge branch
'mh/iterate-refs'
git bisect good 11fa509957025cc30c063d75014b701dd9ae235d
# bad: [dce4bab6567de7c458b334e029e3dedcab5f2648] add_ref(): verify
that the refname is formatted correctly
git bisect bad dce4bab6567de7c458b334e029e3dedcab5f2648
# good: [7cb368421f62318f2c0f0e19a83ca34c201aebaa] resolve_ref():
expand documentation
git bisect good 7cb368421f62318f2c0f0e19a83ca34c201aebaa
If I revert it, everything's ok.
Thanks a lot,
Andrea Gelmini
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Git --reference bug(?)
2011-10-18 22:04 Git --reference bug(?) Andrea Gelmini
@ 2011-10-19 5:01 ` Michael Haggerty
2011-10-19 6:21 ` Junio C Hamano
0 siblings, 1 reply; 6+ messages in thread
From: Michael Haggerty @ 2011-10-19 5:01 UTC (permalink / raw)
To: Andrea Gelmini; +Cc: gitster, git
On 10/19/2011 12:04 AM, Andrea Gelmini wrote:
> git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> /tmp/3.1 --reference /home/gelma/dev/kernel/linus/
> Cloning into /tmp/3.1...
> fatal: Reference has invalid format: 'refs/tags/3.1.1.1^{}'
> fatal: The remote end hung up unexpectedly
The upstream repo reports what look like non-reference references:
$ git ls-remote --tags
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git | head
5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c refs/tags/v2.6.11
c39ae07f393806ccf406ef966e9a15afc43cc36a refs/tags/v2.6.11^{}
5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c refs/tags/v2.6.11-tree
c39ae07f393806ccf406ef966e9a15afc43cc36a refs/tags/v2.6.11-tree^{}
26791a8bcf0e6d33f43aef7682bdb555236d56de refs/tags/v2.6.12
9ee1c939d1cb936b1f98e8d81aeffab57bae46ab refs/tags/v2.6.12^{}
9e734775f7c22d2f89943ad6c745571f1930105f refs/tags/v2.6.12-rc2
1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 refs/tags/v2.6.12-rc2^{}
0397236d43e48e821cce5bbe6a80a1a56bb7cc3a refs/tags/v2.6.12-rc3
a2755a80f40e5794ddc20e00f781af9d6320fafb refs/tags/v2.6.12-rc3^{}
[...]
I've never seen this format before; is this the remote protocol for
peeled refs or maybe the behavior of an old version of git?
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Git --reference bug(?)
2011-10-19 5:01 ` Michael Haggerty
@ 2011-10-19 6:21 ` Junio C Hamano
2011-10-19 6:25 ` Junio C Hamano
0 siblings, 1 reply; 6+ messages in thread
From: Junio C Hamano @ 2011-10-19 6:21 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Andrea Gelmini, gitster, git
Michael Haggerty <mhagger@alum.mit.edu> writes:
> On 10/19/2011 12:04 AM, Andrea Gelmini wrote:
>> git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
>> /tmp/3.1 --reference /home/gelma/dev/kernel/linus/
>> Cloning into /tmp/3.1...
>> fatal: Reference has invalid format: 'refs/tags/3.1.1.1^{}'
>> fatal: The remote end hung up unexpectedly
>
> The upstream repo reports what look like non-reference references:
>
> $ git ls-remote --tags
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git | head
> 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c refs/tags/v2.6.11
> c39ae07f393806ccf406ef966e9a15afc43cc36a refs/tags/v2.6.11^{}
> 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c refs/tags/v2.6.11-tree
> c39ae07f393806ccf406ef966e9a15afc43cc36a refs/tags/v2.6.11-tree^{}
> 26791a8bcf0e6d33f43aef7682bdb555236d56de refs/tags/v2.6.12
> 9ee1c939d1cb936b1f98e8d81aeffab57bae46ab refs/tags/v2.6.12^{}
> 9e734775f7c22d2f89943ad6c745571f1930105f refs/tags/v2.6.12-rc2
> 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 refs/tags/v2.6.12-rc2^{}
> 0397236d43e48e821cce5bbe6a80a1a56bb7cc3a refs/tags/v2.6.12-rc3
> a2755a80f40e5794ddc20e00f781af9d6320fafb refs/tags/v2.6.12-rc3^{}
> [...]
>
> I've never seen this format before; is this the remote protocol for
> peeled refs or maybe the behavior of an old version of git?
This should be very well documented and has been the output from fairly
early days of ls-remote.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Git --reference bug(?)
2011-10-19 6:21 ` Junio C Hamano
@ 2011-10-19 6:25 ` Junio C Hamano
2011-10-19 6:33 ` Junio C Hamano
0 siblings, 1 reply; 6+ messages in thread
From: Junio C Hamano @ 2011-10-19 6:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael Haggerty, Andrea Gelmini, git
Junio C Hamano <gitster@pobox.com> writes:
>> 0397236d43e48e821cce5bbe6a80a1a56bb7cc3a refs/tags/v2.6.12-rc3
>> a2755a80f40e5794ddc20e00f781af9d6320fafb refs/tags/v2.6.12-rc3^{}
>> [...]
>>
>> I've never seen this format before; is this the remote protocol for
>> peeled refs or maybe the behavior of an old version of git?
>
> This should be very well documented and has been the output from fairly
> early days of ls-remote.
I take the first half back. The ls-remote documentation seems to have
bit-rotten quite a bit.
IIRC, we started doing this when we introduced auto-following of the tag
objects. Even update-server-info knows about it so it way predates smart
HTTP and is a fairly old and established behaviour.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Git --reference bug(?)
2011-10-19 6:25 ` Junio C Hamano
@ 2011-10-19 6:33 ` Junio C Hamano
2011-10-19 6:55 ` Junio C Hamano
0 siblings, 1 reply; 6+ messages in thread
From: Junio C Hamano @ 2011-10-19 6:33 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Andrea Gelmini, git
Junio C Hamano <gitster@pobox.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>>> 0397236d43e48e821cce5bbe6a80a1a56bb7cc3a refs/tags/v2.6.12-rc3
>>> a2755a80f40e5794ddc20e00f781af9d6320fafb refs/tags/v2.6.12-rc3^{}
>>> [...]
>>>
>>> I've never seen this format before; is this the remote protocol for
>>> peeled refs or maybe the behavior of an old version of git?
>>
>> This should be very well documented and has been the output from fairly
>> early days of ls-remote.
>
> I take the first half back. The ls-remote documentation seems to have
> bit-rotten quite a bit.
>
> IIRC, we started doing this when we introduced auto-following of the tag
> objects. Even update-server-info knows about it so it way predates smart
> HTTP and is a fairly old and established behaviour.
In addition, you must be careful about what is added with add_extra_ref();
they are often not refs but are placeholders for Git to know that the
history leading to it is complete, even though they do not exist as
refs. The values of real refs that exist in your alternate object store
are treated this way, because you know you do not have to fetch (if you
are initiating fetch-pack) or receive (if the other side is initiating
send-pack) histories leading to them from the other side.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Git --reference bug(?)
2011-10-19 6:33 ` Junio C Hamano
@ 2011-10-19 6:55 ` Junio C Hamano
0 siblings, 0 replies; 6+ messages in thread
From: Junio C Hamano @ 2011-10-19 6:55 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Andrea Gelmini, git
Junio C Hamano <gitster@pobox.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
> In addition, you must be careful about what is added with add_extra_ref();
> they are often not refs but are placeholders for Git to know that the
> history leading to it is complete, even though they do not exist as
> refs. The values of real refs that exist in your alternate object store
> are treated this way, because you know you do not have to fetch (if you
> are initiating fetch-pack) or receive (if the other side is initiating
> send-pack) histories leading to them from the other side.
I think a quick and simple rule would be that add_extra_ref() is to give
our history in the object database extra anchor points to avoid fetching
or receiving pushes of unnecessary history into our object database, when
we know our object database has certain histories that are not reachable
from our own refs available. The names given to add_extra_ref() would not
follow any normal refname rules (in fact, "refs/tags/v2.6.12-rc3^{}"
peeled notation was designed not to collide with real refs, so was ".have"
sent from receive-pack.c to send-pack.c even though the latter is not kept
track of with the refs mechanism).
They do not have to be shown when resolve_ref() is called. They only need
to appear in for_each_ref() so that revision walking machinery can use
them when we need to compute the set-difference of commits between what we
have and what the other side has.
Hope this clears things up a bit.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-10-19 6:55 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-10-18 22:04 Git --reference bug(?) Andrea Gelmini
2011-10-19 5:01 ` Michael Haggerty
2011-10-19 6:21 ` Junio C Hamano
2011-10-19 6:25 ` Junio C Hamano
2011-10-19 6:33 ` Junio C Hamano
2011-10-19 6:55 ` Junio C Hamano
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).