Phillip Wood <phillip.wood@xxxxxxxxxxxx> writes: > On 10/10/2018 06:43, Junio C Hamano wrote: >> Here are the topics that have been cooking. Commits prefixed with >> '-' are only in 'pu' (proposed updates) while commits prefixed with >> '+' are in 'next'. The ones marked with '.' do not appear in any of >> the integration branches, but I am still holding onto them. >> >> * pw/diff-color-moved-ws-fix (2018-10-04) 5 commits >> - diff --color-moved: fix a memory leak >> - diff --color-moved-ws: fix another memory leak >> - diff --color-moved-ws: fix a memory leak >> - diff --color-moved-ws: fix out of bounds string access >> - diff --color-moved-ws: fix double free crash >> >> Various fixes to "diff --color-moved-ws". >> >> What's the status of this topic? > > I think it is ready for next - Stefan was happy with the last iteration. This is not about your fixes, but I was skimming the color-moved support in general as a final sanity check to move this forward and noticed that $ git diff --color-moved-ws=ignore-any master... does not do anything interesting, which is broken at at least two points. * There is no "ignore-any" supported by the feature---I think that the parser for the option should have noticed and barfed, but it did not. It merely emitted a message to the standard output and let it scroll away with the huge diff before the reader noticed it. * After fixing ignore-any to one of the supported option (e.g. "ignore-all-spaces"), the color-moved feature still did not trigger. I think the presence of --color-moved-ws by itself is a hint that the user wants --color-moved to be used. If it turns out that there are some valid use cases where --color-moved-ws may have to be set but the color-moved feature should not be enabled, then diff --color-moved-ws=ignore-all-space --no-color-moved can be used to countermand this, of course. Am I missing something or are these mere small sloppiness in the current code?
