fast-import: Fail if a non-existant commit is used for merge
commit2f6dc35d2ad0bd2a8648902a692f087f47d1ee86
authorShawn O. Pearce <spearce@spearce.org>
Mon, 5 Mar 2007 17:43:14 +0000 (5 12:43 -0500)
committerShawn O. Pearce <spearce@spearce.org>
Mon, 5 Mar 2007 17:43:14 +0000 (5 12:43 -0500)
treee9b268b86e2e7418a849702f9cd361a06ab69033
parent734c91f9e292cf6ed1401c178bc9fbb902cc82dd
fast-import: Fail if a non-existant commit is used for merge

Johannes Sixt noticed during one of his own imports that fast-import
did not fail if a non-existant commit is referenced by SHA-1 value
as an argument to the 'merge' command.  This allowed the user to
unknowingly create commits that would fail in fsck, as the commit
contents would not be completely reachable.

A side effect of this bug was that a frontend process could mark
any SHA-1 object (blob, tree, tag) as a parent of a merge commit.
This should also fail in fsck, as the commit is not a valid commit.

We now use the same rule as the 'from' command.  If a commit is
referenced in the 'merge' command by hex formatted SHA-1 then the
SHA-1 must be a commit or a tag that can be peeled back to a commit,
the commit must already exist, and must be readable by the core Git
infrastructure code.  This requirement means that the commit must
have existed prior to fast-import starting, or the commit must have
been flushed out by a prior 'checkpoint' command.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
fast-import.c