Re: What's cooking in git.git (Oct 2018, #01; Wed, 10)
- From
- Phillip Wood <phillip.wood@talktalk.net>
- Date
- Oct 12, 2018, 09:59 UTC
- Message-ID
- <ca3b162d-d1c6-1ed1-cb20-4232d91f7b51@talktalk.net>
- In-Reply-To
- <xmqqa7nkf6o4.fsf@gitster-ct.c.googlers.com>
On 11/10/2018 23:40, Junio C Hamano wrote:
Show 35 quoted lines
> 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.
Show 17 quoted lines
> * 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? > > >