summaryrefslogtreecommitdiff
path: root/t/t5515/fetch.br-config-explicit-octopus
diff options
context:
space:
mode:
authorLibravatar Pete Wyckoff <pw@padd.com>2012-04-07 18:59:20 -0400
committerLibravatar Junio C Hamano <gitster@pobox.com>2012-04-10 14:34:02 -0700
commit06454cb9a3bd2a34299779b147e388ff0f31c9f7 (patch)
treed27562385b8c05560ac8b2f34de3bb1cc0b1f5b1 /t/t5515/fetch.br-config-explicit-octopus
parentGit 1.7.9.6 (diff)
downloadtgif-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-config-explicit-octopus')
0 files changed, 0 insertions, 0 deletions