Hi,
I've just started using GIT this week, currently the project i'm working on
is held in subversion. I tested git svn clone with a small test project
(about 10 files) which worked a treat.
This morning i decided to test the clone with the full project i'm working
on (11,000 files) and I get the error message Checksum mismatch: vn2.sln
0f7a82f1d38b819 expected: fde799e5ba0d1d07e6b539016bea3260
got: e71db1010a0da06ea76d4163c452df72
Can someone help with why this error is happening? Is there an issue with
the GIT clone and large repositories?
Thanks in advance for your help,
Gilbert.
--
View this message in context: http://www.nabble.com/svn-clone-Checksum-mismatch-question-tp22719363p22719363.html
Sent from the git mailing list archive at Nabble.com.
From: Björn Steinbrink <hidden> Date: 2016-06-15 22:46:28
On 2009.03.26 03:31:53 -0700, Gilbert Liddell wrote:
This morning i decided to test the clone with the full project i'm working
on (11,000 files) and I get the error message Checksum mismatch: vn2.sln
0f7a82f1d38b819 expected: fde799e5ba0d1d07e6b539016bea3260
got: e71db1010a0da06ea76d4163c452df72
Can someone help with why this error is happening? Is there an issue with
the GIT clone and large repositories?
Which git version is that? There was some bug in git-svn that caused it
to fill the disk with temporary files, without noticing that those files
get truncated when the disk is full. That was fixed in some 1.6.0.x
release IIRC.
Björn
Hi Björn,
Thanks for the reply, i'm using git version 1.6.2.msysgit.0.186.gf7512
Gilbert.
-----Original Message-----
From: Björn Steinbrink [mailto:B.Steinbrink@gmx.de]
Sent: 26 March 2009 13:02
To: Gilbert Liddell
Cc: git@vger.kernel.org
Subject: Re: svn clone Checksum mismatch question
On 2009.03.26 03:31:53 -0700, Gilbert Liddell wrote:
This morning i decided to test the clone with the full project i'm working
on (11,000 files) and I get the error message Checksum mismatch: vn2.sln
0f7a82f1d38b819 expected: fde799e5ba0d1d07e6b539016bea3260
got: e71db1010a0da06ea76d4163c452df72
Can someone help with why this error is happening? Is there an issue with
the GIT clone and large repositories?
Which git version is that? There was some bug in git-svn that caused it
to fill the disk with temporary files, without noticing that those files
get truncated when the disk is full. That was fixed in some 1.6.0.x
release IIRC.
Björn
Registered in Scotland
32 Fountain Drive
Inchinnan Business Park
Renfrewshire,PA4 9RF.
Company number:SC112872
This e-mail and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom
they are addressed.
If you have received this e-mail in error please notify the
originator of the message. This footer also confirms that this
e-mail message has been scanned for the presence of computer viruses.
Any views expressed in this message are those of the individual
sender, except where the sender specifies and with authority,
states them to be the views of Total Repair Solutions.
Scanning of this message and addition of this footer is performed
by SurfControl E-mail Filter software in conjunction with
virus detection software.
Heya,
[We do not top post on this list, instead it is customary to reply
inline, as I and Björn have done]
2009/3/26 Gilbert Liddell [off-list ref]:
2009/3/26 Björn Steinbrink [off-list ref]:
quoted
On 2009.03.26 03:31:53 -0700, Gilbert Liddell wrote:
quoted
This morning i decided to test the clone with the full project i'm working
on (11,000 files) and I get the error message Checksum mismatch: vn2.sln
0f7a82f1d38b819 expected: fde799e5ba0d1d07e6b539016bea3260
got: e71db1010a0da06ea76d4163c452df72
Can someone help with why this error is happening? Is there an issue with
the GIT clone and large repositories?
Which git version is that? There was some bug in git-svn that caused it
to fill the disk with temporary files, without noticing that those files
get truncated when the disk is full. That was fixed in some 1.6.0.x
release IIRC.
Thanks for the reply, i'm using git version 1.6.2.msysgit.0.186.gf7512
Seems like it could be one of the known bugs of git-svn on windows?
(ccing Dscho and J6t)
--
Cheers,
Sverre Rabbelier
On 2009.03.26 03:31:53 -0700, Gilbert Liddell wrote:
quoted
This morning i decided to test the clone with the full project i'm working
on (11,000 files) and I get the error message Checksum mismatch: vn2.sln
0f7a82f1d38b819 expected: fde799e5ba0d1d07e6b539016bea3260
got: e71db1010a0da06ea76d4163c452df72
Can someone help with why this error is happening? Is there an issue with
the GIT clone and large repositories?
Which git version is that? There was some bug in git-svn that caused it
to fill the disk with temporary files, without noticing that those files
get truncated when the disk is full. That was fixed in some 1.6.0.x
release IIRC.
Thanks for the reply, i'm using git version 1.6.2.msysgit.0.186.gf7512
Seems like it could be one of the known bugs of git-svn on windows?
(ccing Dscho and J6t)
--
Cheers,
Sverre Rabbelier
Hi,
Apologies for the Top Posting.
I've not been able to find any info about this being a but with git-svn on Windows. I stumbled across this post that appears to be the same/similar issue -
http://lists-archives.org/git/668493-git-svn-checksum-mismatch-importing-large-file.html
Gilbert.
Registered in Scotland
32 Fountain Drive
Inchinnan Business Park
Renfrewshire,PA4 9RF.
Company number:SC112872
This e-mail and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom
they are addressed.
If you have received this e-mail in error please notify the
originator of the message. This footer also confirms that this
e-mail message has been scanned for the presence of computer viruses.
Any views expressed in this message are those of the individual
sender, except where the sender specifies and with authority,
states them to be the views of Total Repair Solutions.
Scanning of this message and addition of this footer is performed
by SurfControl E-mail Filter software in conjunction with
virus detection software.
From: Peter Harris <hidden> Date: 2016-06-15 22:46:28
On Thu, Mar 26, 2009 at 6:31 AM, Gilbert Liddell wrote:
This morning i decided to test the clone with the full project i'm working
on (11,000 files) and I get the error message Checksum mismatch: vn2.sln
0f7a82f1d38b819 expected: fde799e5ba0d1d07e6b539016bea3260
got: e71db1010a0da06ea76d4163c452df72
Can someone help with why this error is happening? Is there an issue with
the GIT clone and large repositories?
(since you mentioned msysgit in another reply) What is your
core.autocrlf setting? Did you default it to 'true' or 'input' when
you installed msysgit?
Try "git config core.autocrlf false" and resume the import process
(with "git svn fetch" or similar).
Importing from svn with autocrlf on only works if every text file has
svn:eol-style=native set in every revision. *.sln files are even
worse, since they look like text to git, but they're really binary (so
nobody sets svn:eol-style on them).
Peter Harris
From: Anton Gyllenberg <hidden> Date: 2016-06-15 22:46:28
2009/3/26 Björn Steinbrink [off-list ref]:
On 2009.03.26 03:31:53 -0700, Gilbert Liddell wrote:
quoted
This morning i decided to test the clone with the full project i'm working
on (11,000 files) and I get the error message Checksum mismatch: vn2.sln
0f7a82f1d38b819 expected: fde799e5ba0d1d07e6b539016bea3260
got: e71db1010a0da06ea76d4163c452df72
Can someone help with why this error is happening? Is there an issue with
the GIT clone and large repositories?
Which git version is that? There was some bug in git-svn that caused it
to fill the disk with temporary files, without noticing that those files
get truncated when the disk is full. That was fixed in some 1.6.0.x
release IIRC.
I don't know if this is the same issue, but the I get a similar error
on the public twisted-python repository on both windows and linux,
with several different versions and plenty of free disk space. As this
is a publicly accessible repository it should be easy to reproduce:
git svn init -s svn://svn.twistedmatrix.com/svn/Twisted twisted
cd twisted
git svn fetch -r 13611:HEAD
This ultimately dies with the following error:
W: +empty_dir: trunk/doc/core/howto/listings/finger/finger
r13612 = f6d995ac255e3dfa08a517a6e72fbcfe63feaaa0 (trunk)
Checksum mismatch:
branches/foom/--omg-optimized/twisted/internet/cdefer/cdefer.pyx
264b0c5f7b3a00d401d1a5dcce67a3734f0eede3
expected: c7ccddd195f132926e20bab573da7ef3
got: f006323ff4714ca52c0228ce6390d415
I found this a long time ago but never got around to analyze or report it.
Anton
From: Anton Gyllenberg <hidden> Date: 2016-06-15 22:46:29
I hope I didn't hijack the thread with an unrelated issue.
2009/3/26 Anton Gyllenberg [off-list ref]:
I don't know if this is the same issue, but the I get a similar error
on the public twisted-python repository on both windows and linux,
with several different versions and plenty of free disk space. As this
is a publicly accessible repository it should be easy to reproduce:
git svn init -s svn://svn.twistedmatrix.com/svn/Twisted twisted
cd twisted
git svn fetch -r 13611:HEAD
This ultimately dies with the following error:
W: +empty_dir: trunk/doc/core/howto/listings/finger/finger
r13612 = f6d995ac255e3dfa08a517a6e72fbcfe63feaaa0 (trunk)
Checksum mismatch:
branches/foom/--omg-optimized/twisted/internet/cdefer/cdefer.pyx
264b0c5f7b3a00d401d1a5dcce67a3734f0eede3
expected: c7ccddd195f132926e20bab573da7ef3
got: f006323ff4714ca52c0228ce6390d415
Looking into this, the mentioned blob
264b0c5f7b3a00d401d1a5dcce67a3734f0eede3 with md5sum
f006323ff4714ca52c0228ce6390d415 is not at path
branches/foom/--omg-optimized/twisted/internet/cdefer/cdefer.pyx. The
contents of the blob is the seemingly totally unrelated LICENSE file
that is found at trunk/LICENSE and
branches/foom/--omg-optimized/LICENSE. cdefer.pyx does have the md5sum
c7ccddd195f132926e20bab573da7ef3. Note that the branch root directory
is branches/foom/--omg-optimized (like with the branch name being
foom/--omg-optimized), not just branches/foom. Is think git-svn relies
on the standard layout being branches directly under the branches/
directory, but I don't see how this would get the paths mixed up like
this.
Looking at what was done around this commit one finds odd stuff, like
deleting directories in trunk and then copying from a previous
revision of trunk to under the branch:
http://twistedmatrix.com/trac/changeset/13611
I created a local test svn repository and tried to do something
similar but git-svn had no problem with my test.
This is issue is not critical for me in any way but if somebody wants
to look into it I am happy to help out.
Anton
From: Eric Wong <hidden> Date: 2016-06-15 22:46:29
Anton Gyllenberg [off-list ref] wrote:
I hope I didn't hijack the thread with an unrelated issue.
No worries if you did. You helped me find a stupid bug in git-svn
that's been there for 3 years. I couldn't help the original poster at
all since he was working on a private repo and I can't support git-svn
under Windows.
2009/3/26 Anton Gyllenberg [off-list ref]:
quoted
I don't know if this is the same issue, but the I get a similar error
on the public twisted-python repository on both windows and linux,
with several different versions and plenty of free disk space. As this
is a publicly accessible repository it should be easy to reproduce:
git svn init -s svn://svn.twistedmatrix.com/svn/Twisted twisted
cd twisted
git svn fetch -r 13611:HEAD
This ultimately dies with the following error:
W: +empty_dir: trunk/doc/core/howto/listings/finger/finger
r13612 = f6d995ac255e3dfa08a517a6e72fbcfe63feaaa0 (trunk)
Checksum mismatch:
branches/foom/--omg-optimized/twisted/internet/cdefer/cdefer.pyx
264b0c5f7b3a00d401d1a5dcce67a3734f0eede3
expected: c7ccddd195f132926e20bab573da7ef3
got: f006323ff4714ca52c0228ce6390d415
is branches/foom/--omg-optimized (like with the branch name being
foom/--omg-optimized), not just branches/foom. Is think git-svn relies
on the standard layout being branches directly under the branches/
directory, but I don't see how this would get the paths mixed up like
this.
Root problem: I misused "git ls-tree" for 3 years and nobody noticed.
At least I'm glad the checksum verification every step of the way caught
this bug and prevented propagating it into repository corruption.
Looking at what was done around this commit one finds odd stuff, like
deleting directories in trunk and then copying from a previous
revision of trunk to under the branch:
http://twistedmatrix.com/trac/changeset/13611
I created a local test svn repository and tried to do something
similar but git-svn had no problem with my test.
I was fooled by the weird copy sequences, too.
This is issue is not critical for me in any way but if somebody wants
to look into it I am happy to help out.
I guess few folks in the UNIX world are crazy enough to make pathnames
prefixed with dashes :) But I do wonder how/if many repositories out
there failed and nobody bothered to report it...
Patch in reply
--
Eric Wong
From: Junio C Hamano <hidden> Date: 2016-06-15 22:46:31
Eric Wong [off-list ref] writes:
To find the blob object name given a tree and pathname, we were
incorrectly calling "git ls-tree" with a "--" argument followed
by the pathname of the file we wanted to get.
git ls-tree <TREE> -- --dashed/path/name.c
Unlike many command-line interfaces, the "--" alone does not
symbolize the end of non-option arguments on the command-line.
ls-tree interprets the "--" as a prefix to match against, thus
the entire contents of the --dashed/* hierarchy would be
returned because the "--" matches "--dashed" and every path
under it.
The above makes only half a sense to me. In an empty directory:
$ git init
Initialized empty Git repository in /tmp/empty/.git
$ mkdir -p ./--dashed/path
$ >./--dashed/path/name
$ git add .
$ git ls-files
--dashed/path/name
$ git commit -a -m initial
[master (root-commit) cd44284] initial
0 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 --dashed/path/name
$ git ls-tree HEAD^{tree} --
$ git ls-tree HEAD^{tree} -- --dashed/path/name
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 --dashed/path/name
$ mkdir ./--
$ >./--/eman
$ git add .
$ git commit -m second
[master 80f8ef9] second
0 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 --/eman
$ git ls-tree HEAD^{tree} -- --dashed/path
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 --/eman
040000 tree 23e59e0c91294c39ac7c5a2e39efb01d878de9a0 --dashed/path
$ exit
Perhaps the problem repository had a pathname that is exactly -- (in
addition to --dashed/), and ls-tree emitted everything under --/
hierarchy? In other words, your fix to git-svn may be correct and I am
reading your problem description above incorrectly?
As the command always takes exactly one tree, it could be argued that it
is not a bug that it does not honour the usual -- convention, even though
I am tempted to think it is of a very dark shade of gray. It is certainly
something that we would have done differently if we were implementing the
command today.
"Fixing" ls-tree would be trivial to ignore the first "--" if it precedes
other pathspecs (see below), but the command is a plumbing, and such a
change will break existing scripts that have relied on the existing
behaviour since 2005, so I do not think it is worth the risk of causing
such silent breakages to them. Besides, with such a "fix", fixing of user
scripts will become much more cumbersome, as they need to detect the
version of git and drive ls-tree differently.
builtin-ls-tree.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
From: Eric Wong <hidden> Date: 2016-06-15 22:46:31
Junio C Hamano [off-list ref] wrote:
Eric Wong [off-list ref] writes:
quoted
To find the blob object name given a tree and pathname, we were
incorrectly calling "git ls-tree" with a "--" argument followed
by the pathname of the file we wanted to get.
git ls-tree <TREE> -- --dashed/path/name.c
Unlike many command-line interfaces, the "--" alone does not
symbolize the end of non-option arguments on the command-line.
ls-tree interprets the "--" as a prefix to match against, thus
the entire contents of the --dashed/* hierarchy would be
returned because the "--" matches "--dashed" and every path
under it.
The above makes only half a sense to me. In an empty directory:
Ah, I think you missed this line:
"the entire contents of the --dashed/* hierarchy would be"
This is similar to the problem I was experiencing.
$ exit
Perhaps the problem repository had a pathname that is exactly -- (in
addition to --dashed/), and ls-tree emitted everything under --/
hierarchy? In other words, your fix to git-svn may be correct and I am
reading your problem description above incorrectly?
I think so.
As the command always takes exactly one tree, it could be argued that it
is not a bug that it does not honour the usual -- convention, even though
I am tempted to think it is of a very dark shade of gray. It is certainly
something that we would have done differently if we were implementing the
command today.
Well, if somebody had a path in their repo called "--full-name" then it
would certainly be ambiguous and respecting "--" would help. Something
we should definitely go back and fix if we have time travel[1]
"Fixing" ls-tree would be trivial to ignore the first "--" if it precedes
other pathspecs (see below), but the command is a plumbing, and such a
change will break existing scripts that have relied on the existing
behaviour since 2005, so I do not think it is worth the risk of causing
such silent breakages to them. Besides, with such a "fix", fixing of user
scripts will become much more cumbersome, as they need to detect the
version of git and drive ls-tree differently.
I concur completely. I didn't propose a "fix" to ls-tree for exactly
the reasons you stated.
[1] But if we had time travel we could just release git before any other
SCM and hopefully not have to deal with SVN at all :)
--
Eric Wong
From: Björn Steinbrink <hidden> Date: 2016-06-15 22:46:31
On 2009.03.29 13:33:02 -0700, Junio C Hamano wrote:
Eric Wong [off-list ref] writes:
quoted
To find the blob object name given a tree and pathname, we were
incorrectly calling "git ls-tree" with a "--" argument followed
by the pathname of the file we wanted to get.
git ls-tree <TREE> -- --dashed/path/name.c
Unlike many command-line interfaces, the "--" alone does not
symbolize the end of non-option arguments on the command-line.
ls-tree interprets the "--" as a prefix to match against, thus
the entire contents of the --dashed/* hierarchy would be
returned because the "--" matches "--dashed" and every path
under it.
The above makes only half a sense to me. In an empty directory:
$ git init
Initialized empty Git repository in /tmp/empty/.git
$ mkdir -p ./--dashed/path
$ >./--dashed/path/name
$ git add .
$ git ls-files
--dashed/path/name
$ git commit -a -m initial
[master (root-commit) cd44284] initial
0 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 --dashed/path/name
$ git ls-tree HEAD^{tree} --
$ git ls-tree HEAD^{tree} -- --dashed/path/name
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 --dashed/path/name
$ mkdir ./--
$ >./--/eman
$ git add .
$ git commit -m second
[master 80f8ef9] second
0 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 --/eman
$ git ls-tree HEAD^{tree} -- --dashed/path
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 --/eman
040000 tree 23e59e0c91294c39ac7c5a2e39efb01d878de9a0 --dashed/path
$ exit
Perhaps the problem repository had a pathname that is exactly -- (in
addition to --dashed/), and ls-tree emitted everything under --/
hierarchy? In other words, your fix to git-svn may be correct and I am
reading your problem description above incorrectly?
Your test case is flawed, because you only have a single path in
--dashed/
Initialized empty Git repository in /home/doener/test/.git/
$ mkdir ./--dashed
$ touch ./--dashed/{1,2}
$ git add .
$ git ls-files
--dashed/1
--dashed/2
$ git commit -m init
[master (root-commit) ae7cd83] init
0 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 --dashed/1
create mode 100644 --dashed/2
$ git ls-tree HEAD^{tree}
040000 tree f353b342b53872c6a510229524f819c4fe0d5c1b --dashed
$ git ls-tree HEAD^{tree} --
$ git ls-tree HEAD^{tree} -- --dashed
040000 tree f353b342b53872c6a510229524f819c4fe0d5c1b --dashed
$ git ls-tree HEAD^{tree} -- --dashed/
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 --dashed/1
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 --dashed/2
$ git ls-tree HEAD^{tree} -- --dashed/1
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 --dashed/1
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 --dashed/2
Or even more weird (at least to me):
Initialized empty Git repository in /home/doener/test/.git/
$ mkdir foo fab
$ touch {foo,fab}/{1,2}
$ git add .
$ git commit -m init
[master (root-commit) fdb7bb3] init
0 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 fab/1
create mode 100644 fab/2
create mode 100644 foo/1
create mode 100644 foo/2
$ git ls-files foo/1 fab/1
fab/1
foo/1
$ git ls-files foo/1 fab/1 f
fab/1
foo/1
$ git ls-tree HEAD^{tree} foo/1 fab/1
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 fab/1
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 foo/1
$ git ls-tree HEAD^{tree} foo/1 fab/1 f
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 fab/1
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 fab/2
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 foo/1
100644 blob e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 foo/2
So if you go into some tree, any additional pattern that is a prefix of
the tree name will match the tree and its contents.
Björn
From: Junio C Hamano <hidden> Date: 2016-06-15 22:46:31
Eric Wong [off-list ref] writes:
Junio C Hamano [off-list ref] wrote:
quoted
Eric Wong [off-list ref] writes:
quoted
To find the blob object name given a tree and pathname, we were
incorrectly calling "git ls-tree" with a "--" argument followed
by the pathname of the file we wanted to get.
git ls-tree <TREE> -- --dashed/path/name.c
Unlike many command-line interfaces, the "--" alone does not
symbolize the end of non-option arguments on the command-line.
ls-tree interprets the "--" as a prefix to match against, thus
the entire contents of the --dashed/* hierarchy would be
returned because the "--" matches "--dashed" and every path
under it.
The above makes only half a sense to me. In an empty directory:
Ah, I think you missed this line:
"the entire contents of the --dashed/* hierarchy would be"
Actually, that was what I was trying to demonstrate to be false. Notice
the empty output from the first ls-tree with only -- and no other pathspec
on the command line. "--" should not match "--dashed/*" anything (but
also notice that I said "should" here).
I think that is an independent bug. Not just "--" but it appears "--d"
seems to hit it (and this is an ancient bug---even v1.0.0 seems to have
it).
[1] But if we had time travel we could just release git before any other
SCM and hopefully not have to deal with SVN at all :)
;-)
I suspect that ls-tree needs a fix, not about "--" but about the pathspec
filtering. It appears that the part that decides if a subtree is worth
traversing into uses the correct "is a pathspec pattern match leading path
components?" semantics (i.e. "--dashed" matches but "--" doesn't), but
after traversing into subtrees, the part that emits the output uses a
broken semantics "does the path have any pathspec patter as its prefix?"
It shouldn't check for "prefix", but for "leading path components", in
other words, the match must happen at directory boundaries.
And I do not think *this* bug is too late to fix. We should fix it.
From: Anton Gyllenberg <hidden> Date: 2016-06-15 22:46:31
Makes perfect sense now that you explain it and I see the patch. I
actually tried debugging it a bit but got lost in the perl SVN code.
Thank you Eric for figuring this out and for all your work on git-svn
in general!
I guess few folks in the UNIX world are crazy enough to make pathnames
prefixed with dashes :)
I guess they wouldn't call the project Twisted without reason :-).
Anton
From: Eric Wong <hidden> Date: 2016-06-15 22:46:31
Junio C Hamano [off-list ref] wrote:
Eric Wong [off-list ref] writes:
quoted
Junio C Hamano [off-list ref] wrote:
quoted
Eric Wong [off-list ref] writes:
quoted
To find the blob object name given a tree and pathname, we were
incorrectly calling "git ls-tree" with a "--" argument followed
by the pathname of the file we wanted to get.
git ls-tree <TREE> -- --dashed/path/name.c
Unlike many command-line interfaces, the "--" alone does not
symbolize the end of non-option arguments on the command-line.
ls-tree interprets the "--" as a prefix to match against, thus
the entire contents of the --dashed/* hierarchy would be
returned because the "--" matches "--dashed" and every path
under it.
The above makes only half a sense to me. In an empty directory:
Ah, I think you missed this line:
"the entire contents of the --dashed/* hierarchy would be"
Actually, that was what I was trying to demonstrate to be false. Notice
the empty output from the first ls-tree with only -- and no other pathspec
on the command line. "--" should not match "--dashed/*" anything (but
also notice that I said "should" here).
I think that is an independent bug. Not just "--" but it appears "--d"
seems to hit it (and this is an ancient bug---even v1.0.0 seems to have
it).
I suspect that ls-tree needs a fix, not about "--" but about the pathspec
filtering. It appears that the part that decides if a subtree is worth
traversing into uses the correct "is a pathspec pattern match leading path
components?" semantics (i.e. "--dashed" matches but "--" doesn't), but
after traversing into subtrees, the part that emits the output uses a
broken semantics "does the path have any pathspec patter as its prefix?"
It shouldn't check for "prefix", but for "leading path components", in
other words, the match must happen at directory boundaries.
And I do not think *this* bug is too late to fix. We should fix it.
From the ls-tree documentation, I was under the impression that "--"
matching "--dashed" was intended:
When paths are given, show them (note that this isn't really raw
pathnames, but rather a list of patterns to match).
It doesn't make sense to me match like this, either; but I do think it
was intended and it will break things if people depend on the
existing behavior.
--
Eric Wong
From: Eric Wong <hidden> Date: 2016-08-11 17:46:51
To find the blob object name given a tree and pathname, we were
incorrectly calling "git ls-tree" with a "--" argument followed
by the pathname of the file we wanted to get.
git ls-tree <TREE> -- --dashed/path/name.c
Unlike many command-line interfaces, the "--" alone does not
symbolize the end of non-option arguments on the command-line.
ls-tree interprets the "--" as a prefix to match against, thus
the entire contents of the --dashed/* hierarchy would be
returned because the "--" matches "--dashed" and every path
under it.
Thanks to Anton Gyllenberg for pointing me toward the
Twisted repository as a real-world example of this case.
Signed-off-by: Eric Wong <redacted>
---
Junio: This can go to maint. Thanks
git-svn.perl | 15 +++++++++------
1 files changed, 9 insertions(+), 6 deletions(-)
@@ -3387,15 +3387,18 @@ sub delete_entry {returnundefif($gpatheq'');# remove entire directories.-if(command('ls-tree',$self->{c},'--',$gpath)=~ /^040000 tree/){+my($tree)=(command('ls-tree','-z',$self->{c},"./$gpath")+=~ /\A040000 tree ([a-f\d]{40})\t\Q$gpath\E\0/);+if($tree){my($ls,$ctx)=command_output_pipe(qw/ls-tree-r--name-only-z/,-$self->{c},'--',$gpath);+$tree);local$/="\0";while(<$ls>){chomp;-$self->{gii}->remove($_);-print"\tD\t$_\n"unless$::_q;+my$rmpath="$gpath/$_";+$self->{gii}->remove($rmpath);+print"\tD\t$rmpath\n"unless$::_q;}print"\tD\t$gpath/\n"unless$::_q;command_close_pipe($ls,$ctx);
@@ -3414,8 +3417,8 @@ sub open_file {gotooutifis_path_ignored($path);my$gpath=$self->git_path($path);-($mode,$blob)=(command('ls-tree',$self->{c},'--',$gpath)-=~ /^(\d{6}) blob ([a-f\d]{40})\t/);+($mode,$blob)=(command('ls-tree','-z',$self->{c},"./$gpath")+=~ /\A(\d{6}) blob ([a-f\d]{40})\t\Q$gpath\E\0/);unless(defined$mode&&defined$blob){die"$path was not found in commit $self->{c} (r$rev)\n";}