diff options
author | Pete Wyckoff <pw@padd.com> | 2012-04-07 18:59:20 -0400 |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2012-04-10 14:34:02 -0700 |
commit | 06454cb9a3bd2a34299779b147e388ff0f31c9f7 (patch) | |
tree | d27562385b8c05560ac8b2f34de3bb1cc0b1f5b1 /t/t5515/fetch.br-remote-explicit-octopus_remote-explicit | |
parent | Git 1.7.9.6 (diff) | |
download | tgif-06454cb9a3bd2a34299779b147e388ff0f31c9f7.tar.xz |
fast-import: tighten parsing of datarefs
The syntax for the use of mark references in fast-import
demands either a SP (space) or LF (end-of-line) after
a mark reference. Fast-import does not complain when garbage
appears after a mark reference in some cases.
Factor out parsing of mark references and complain if
errant characters are found. Also be a little more careful
when parsing "inline" and SHA1s, complaining if extra
characters appear or if the form of the dataref is unrecognized.
Buggy input can cause fast-import to produce the wrong output,
silently, without error. This makes it difficult to track
down buggy generators of fast-import streams. An example is
seen in the last line of this commit command:
commit refs/heads/S2
committer Name <name@example.com> 1112912893 -0400
data <<COMMIT
commit message
COMMIT
from :1M 100644 :103 hello.c
It is missing a newline and should be:
[...]
from :1
M 100644 :103 hello.c
What fast-import does is to produce a commit with the same
contents for hello.c as in refs/heads/S2^. What the buggy
program was expecting was the contents of blob :103. While
the resulting commit graph looked correct, the contents in
some commits were wrong.
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 't/t5515/fetch.br-remote-explicit-octopus_remote-explicit')
0 files changed, 0 insertions, 0 deletions