]> git.ipfire.org Git - thirdparty/git.git/commit - fast-import.c
fast-import: tighten parsing of datarefs
authorPete Wyckoff <pw@padd.com>
Sat, 7 Apr 2012 22:59:20 +0000 (18:59 -0400)
committerJunio C Hamano <gitster@pobox.com>
Tue, 10 Apr 2012 21:34:02 +0000 (14:34 -0700)
commit06454cb9a3bd2a34299779b147e388ff0f31c9f7
treed27562385b8c05560ac8b2f34de3bb1cc0b1f5b1
parentcb2ed324fc917db0b79d7b1f3756575ffa5f70d5
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>
fast-import.c
t/t9300-fast-import.sh