summaryrefslogtreecommitdiff
path: root/builtin/merge-ours.c
diff options
context:
space:
mode:
authorLibravatar Kyle Meyer <kyle@kyleam.com>2017-02-20 20:10:35 -0500
committerLibravatar Junio C Hamano <gitster@pobox.com>2017-02-20 22:04:47 -0800
commit39ee4c6c2fc80960094ae1454922c2d10c72f210 (patch)
treeb560d4925bc4e6ed3d49163b05352609e7615f7c /builtin/merge-ours.c
parentrename_ref: replace empty message in HEAD's log (diff)
downloadtgif-39ee4c6c2fc80960094ae1454922c2d10c72f210.tar.xz
branch: record creation of renamed branch in HEAD's log
Renaming the current branch adds an event to the current branch's log and to HEAD's log. However, the logged entries differ. The entry in the branch's log represents the entire renaming operation (the old and new hash are identical), whereas the entry in HEAD's log represents the deletion only (the new sha1 is null). Extend replace_each_worktree_head_symref(), whose only caller is branch_rename(), to take a reflog message argument. This allows the creation of the new ref to be recorded in HEAD's log. As a result, the renaming event is represented by two entries (a deletion and a creation entry) in HEAD's log. It's a bit unfortunate that the branch's log and HEAD's log now represent the renaming event in different ways. Given that the renaming operation is not atomic, the two-entry form is a more accurate representation of the operation and is more useful for debugging purposes if a failure occurs between the deletion and creation events. It would make sense to move the branch's log to the two-entry form, but this would involve changes to how the rename is carried out and to how the update flags and reflogs are processed for deletions, so it may not be worth the effort. Based-on-patch-by: Jeff King <peff@peff.net> Signed-off-by: Kyle Meyer <kyle@kyleam.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'builtin/merge-ours.c')
0 files changed, 0 insertions, 0 deletions