Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)

[Phillip Wood <phillip.wood@talktalk.net>]

On 11/10/2018 23:40, Junio C Hamano wrote:
> Phillip Wood <phillip.wood@talktalk.net> 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.

It would be nice if the parsing used starts_with(option_name, user_text)
rather than strcmp() as well. Also I think --color-moved=no is valid as
a synonym of --no-color-moved but --color-moved-ws=no is not supported.

>  * 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?
> 
> 
>