Re: [RFC/PATCH jn/merge-renormalize] merge-recursive: expose merge options for builtin merge

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: [RFC/PATCH jn/merge-renormalize] merge-recursive: expose merge options for builtin merge

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:49:22

Jonathan Nieder [off-list ref] writes:
There are two very similar blocks of code that recognize options for
the "recursive" merge strategy.  Unify them.

No functional change intended.
It makes sense, but I wonder why you chose to do "if (fun() <= 0) error"
instead of usual "if (fun() < 0) error"...

Re: [RFC/PATCH jn/merge-renormalize] merge-recursive: expose merge options for builtin merge

From: Jonathan Nieder <hidden>
Date: 2016-06-15 22:49:23

Junio C Hamano wrote:
Jonathan Nieder [off-list ref] writes:
quoted
There are two very similar blocks of code that recognize options for
the "recursive" merge strategy.  Unify them.

No functional change intended.
It makes sense, but I wonder why you chose to do "if (fun() <= 0) error"
instead of usual "if (fun() < 0) error"...
No good reason (an attempt to vaguely imitate the interface of
handle_revision_opt() from revision.c).  Since both callers die for
an unrecognized option, returning 0 for success and -1 for failure
would indeed be simpler.

I'll try to find time to reroll the series (including --patience)
on top of jn/merge-renormalize tomorrow.  Probably
--ignore-space-change et al are safe, too, though some test cases
would be nice.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help