Re: [PATCH v2 5/7] diff: use skip-to-optional-val in parsing --relative

2 messages, 2 authors, 2017-12-08 · open the first message on its own page

Re: [PATCH v2 5/7] diff: use skip-to-optional-val in parsing --relative

From: Junio C Hamano <hidden>
Date: 2017-12-07 22:31:44

Jeff King [off-list ref] writes:
On Thu, Dec 07, 2017 at 01:59:39PM -0800, Junio C Hamano wrote:
quoted
Jeff King [off-list ref] writes:
quoted
On Thu, Dec 07, 2017 at 09:30:32AM -0800, Junio C Hamano wrote:
quoted
Signed-off-by: Junio C Hamano <redacted>
---
It might be worth mentioning why this conversion is pulled out from the
others (because its "default" case is "do not touch the pointer").
I am not sure what you mean by "pulled out from the others".  I did
not intend to keep these 3 additional patches permanently; rather, I
did them to help Christian's rerolling the series, and I do not think
this one should be separate from other ones that use the _default()
variant when that happens.
Ah, I see. I had thought you meant these to be applied on top.
Ah, I do not particularly mind doing things incrementally, either.

If this goes on top as a standalone patch, then the reason why it is
separate from the other users of _default() is not because the way
it uses the null return is special, but because it was written by a
different author, I would think.  

The reason why _default() variant exists is because its callers want
to react differently to "--foo" from the way they react to "--foo="
(with an empty string as its value), and from that point of view,
this caller is not all that different from other ones, like the one
that parses --color-words Christian wrote in his initial round.

Re: [PATCH v2 5/7] diff: use skip-to-optional-val in parsing --relative

From: Jeff King <hidden>
Date: 2017-12-08 09:05:41

On Thu, Dec 07, 2017 at 02:31:38PM -0800, Junio C Hamano wrote:
If this goes on top as a standalone patch, then the reason why it is
separate from the other users of _default() is not because the way
it uses the null return is special, but because it was written by a
different author, I would think.
Mostly I was just concerned that we missed a somewhat subtle bug in the
first conversion, and I think it's worth calling out in the commit
message why that callsite must be converted in a particular way. Whether
that happens in a separate commit or squashed, I don't care too much.

But I dunno. Maybe it is obvious now that the correct code is in there.
;)

-Peff
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help