Ok, so this was not quite as bad as I feared. The move support as far as I had thought to test it previously actually worked ok, it just wasn't tested (which is embarrassing enough).
The bug fixed in patch 3 is a bit more involved and only triggered by history that merges a rename with a modification to the original filename. Luckily -- I guess -- there are several cases of this happening in git.git around the big builtin/ move in 81b50f3 (Move 'builtin-*' into a 'builtin/' subdirectory, 2010-02-22). So my fuzz tests found that problem. You can reproduce with e.g. git log -M -L:cmd_format_patch:builtin/log.c in any git.git. Thomas Rast (4): t4211: pass -M to 'git log -M -L...' test log -L: test merge of parallel modify/rename log -L: store the path instead of a diff_filespec log -L: improve comments in process_all_files() line-log.c | 62 +++++++----- line-log.h | 8 +- t/t4211-line-log.sh | 18 +++- t/t4211/expect.move-support-f | 56 +++++++++-- t/t4211/expect.parallel-change-f-to-main | 160 +++++++++++++++++++++++++++++++ t/t4211/history.export | 80 +++++++++++++++- 6 files changed, 344 insertions(+), 40 deletions(-) create mode 100644 t/t4211/expect.parallel-change-f-to-main -- 1.8.2.1.567.g8ad0f43 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
