Re: [PATCH 0/6] clean up parsing of maybe_bool

Stefan Beller [off-list ref] writes:

The series looks fine to me overall, though patch 5 is overly gentle IMHO.
We could have removed it right there as Junio is very good at resolving
conflicts or producing dirty merges for such a situation.
But delaying it until no other series' are in flight is fine with me, too.

If you remove the old one, it would cause compilation error due to
removal of the declaration of the old one when other series that are
in flight adds new callsites to it.  Which makes life a bit easier
for the integrators when it is trivial to convert these callsites to
use the new one.  If the way the old one and the new one are called
are vastly different, of course, leaving the compatibility layer
that no longer is used after the series will make it easier to live
with other topics in flight, on the other hand.

I am fine with either in this case, but I probably would have opted
for removal at the end of this series if I were doing this series,
because

-	git_config_maybe_bool(K,V)
+	git_parse_maybe_bool(V)

that may have to happen during evil merges would have been trivial.

Thanks.

On 7 August 2017 at 23:12, Junio C Hamano [off-list ref] wrote:

Stefan Beller [off-list ref] writes:

quoted

The series looks fine to me overall, though patch 5 is overly gentle IMHO.
We could have removed it right there as Junio is very good at resolving
conflicts or producing dirty merges for such a situation.
But delaying it until no other series' are in flight is fine with me, too.

[...]

I am fine with either in this case, but I probably would have opted
for removal at the end of this series if I were doing this series,
because

-       git_config_maybe_bool(K,V)
+       git_parse_maybe_bool(V)

that may have to happen during evil merges would have been trivial.

Thanks, both of you. I could wait a couple of days to see if there are
other things to address, then send a v2 with a more aggressive patch 5?

Martin