Incorrect tree shown with ls-tree ref^{type}:{{folder}}

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Suppose I have a repository that has the following files:

foo/bar/test1.txt
foo/{{curly}}/test2.txt

The following works fine:

$ git ls-tree master^{tree}
040000 tree 9284ac5fef7ad99a2bd508a8c89bde8bd1a88e9f    foo

$ git ls-tree master^{tree}:foo
040000 tree 69497de4d9a72713f87df8280a147e0a597c4055    bar
040000 tree b2abdac384f111c1a8a518e05b963a3bb2541659    {{curly}}

$ git ls-tree master^{tree}:foo/bar
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391    test1.txt

$ git ls-tree master:foo/{{curly}}
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391    test2.txt

However, the following returns the root tree instead of the tree
belonging to {{curly}}:

$ git ls-tree master^{tree}:foo/{{curly}}
040000 tree 9284ac5fef7ad99a2bd508a8c89bde8bd1a88e9f    foo

I believe the problem is on this line in sha1-name.c:peel_onion()
(https://github.com/git/git/blob/b21ebb671bb7dea8d342225f0d66c41f4e54d5ca/sha1-name.c#L1004):

if (len < 4 || name[len-1] != '}')

Since name is "master^{tree}:foo/{{curly}}", peel_onion() returns
early, thinking it is done.

I can append a '/' to force peel_onion() to work, but is that the
right thing to do here? Should this condition handle the
"ref^{type}:filename" case properly?



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux