summaryrefslogtreecommitdiff
path: root/compat
diff options
context:
space:
mode:
authorLibravatar Eric Rannaud <e@nanocritical.com>2017-09-28 20:09:36 -0700
committerLibravatar Junio C Hamano <gitster@pobox.com>2017-09-29 18:35:42 +0900
commit30e215a65c9f75e0f2a72c9f695389179bc30f72 (patch)
tree340faf7137f02ac1f09a426f76a9b963fc7d7cff /compat
parentRelNotes: further fixes for 2.14.2 from the master front (diff)
downloadtgif-30e215a65c9f75e0f2a72c9f695389179bc30f72.tar.xz
fast-import: checkpoint: dump branches/tags/marks even if object_count==0
The checkpoint command cycles packfiles if object_count != 0, a sensible test or there would be no pack files to write. Since 820b931012, the command also dumps branches, tags and marks, but still conditionally. However, it is possible for a command stream to modify refs or create marks without creating any new objects. For example, reset a branch (and keep fast-import running): $ git fast-import reset refs/heads/master from refs/heads/master^ checkpoint but refs/heads/master remains unchanged. Other example: a commit command that re-creates an object that already exists in the object database. The man page also states that checkpoint "updates the refs" and that "placing a progress command immediately after a checkpoint will inform the reader when the checkpoint has been completed and it can safely access the refs that fast-import updated". This wasn't always true without this patch. This fix unconditionally calls dump_{branches,tags,marks}() for all checkpoint commands. dump_branches() and dump_tags() are cheap to call in the case of a no-op. Add tests to t9300 that observe the (non-packfiles) effects of checkpoint. Signed-off-by: Eric Rannaud <e@nanocritical.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'compat')
0 files changed, 0 insertions, 0 deletions