summaryrefslogtreecommitdiff
path: root/Documentation/git-verify-tag.txt
diff options
context:
space:
mode:
authorLibravatar Shawn O. Pearce <spearce@spearce.org>2007-03-05 12:43:14 -0500
committerLibravatar Shawn O. Pearce <spearce@spearce.org>2007-03-05 12:43:14 -0500
commit2f6dc35d2ad0bd2a8648902a692f087f47d1ee86 (patch)
treee9b268b86e2e7418a849702f9cd361a06ab69033 /Documentation/git-verify-tag.txt
parentfast-import: Avoid infinite loop after reset (diff)
downloadtgif-2f6dc35d2ad0bd2a8648902a692f087f47d1ee86.tar.xz
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>
Diffstat (limited to 'Documentation/git-verify-tag.txt')
0 files changed, 0 insertions, 0 deletions