Jeff King <peff@xxxxxxxx> writes: > On Fri, Feb 17, 2017 at 02:43:50PM -0500, Jeff King wrote: > >> Yes. I think the options are basically (in order of decreasing >> preference in my opinion): >> >> 1. Log a rename entry (same sha1, but note the rename in the free-form >> text). >> >> 2. Log a delete (sha1 goes to null) followed by a creation (from null >> back to the original sha1). >> >> 3. Log nothing at all for HEAD. >> >> This does half of (2). If we do the second half, then I'd prefer it to >> (3). But if we can do (1), that is better still (IMHO). [...] >> I'm actually confused about which bit of code is updating HEAD. I do not >> see it either in files_rename_ref() or in the caller. Yet it clearly >> happens. But that is the code that would know enough to do (1) or the >> second half of (2) above. > > Ah, I found it. It's in replace_each_worktree_head_symref() these days, > which does not bother to pass a log message. > > So I think the second half of (2) is probably something like the patch > below. > > Thinking on it more, we probably _do_ want two entries. Because the > operations are not atomic, it's possible that we may end up in a > half-way state after the first entry is written. And when debugging such > a case, I'd much rather see the first half of the operation logged than > nothing at all. OK, I'll have a go at replacing patch 3 with this approach. -- Kyle