Re: [PATCH v2 2/5] Use variables for the lists of tools that support merging / diffing

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

Re: [PATCH v2 2/5] Use variables for the lists of tools that support merging / diffing

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

Sebastian Schuberth [off-list ref] writes:
quoted
This patch makes sense to me, but at the same time makes [PATCH 1/5]
a "Meh", methinks.
Yeah, I can see why. So I've renamed __git_mergetools_common to
__git_diffmerge_tools and squashed with [PATCH 1/5] to make it
less "Meh" as it does not stand on its own.
As you append kcompare or tortoise _after_ the common list, any code
that uses the variable cannot assume that the list is sorted, and
needs to sort the elements if it wants to give a sorted output, so
squashing does not make the Meh-ness go away.

By the way, would it make sense to remove these three variables from
the completion code, and instead ask "git mergetool --tool-help"
when it needs the list of supported tools for the first time?  It
would be trivial to introduce --tool-list that gives a one tool per
line output to both "git difftool" and "git mergetool" and we would
remove the risk of separately maintained list drifting away over
time.

Re: [PATCH v2 2/5] Use variables for the lists of tools that support merging / diffing

From: Sebastian Schuberth <hidden>
Date: 2016-06-15 22:54:19

On 23.07.2012 20:37, Junio C Hamano wrote:
quoted
quoted
This patch makes sense to me, but at the same time makes [PATCH 1/5]
a "Meh", methinks.
Yeah, I can see why. So I've renamed __git_mergetools_common to
__git_diffmerge_tools and squashed with [PATCH 1/5] to make it
less "Meh" as it does not stand on its own.
As you append kcompare or tortoise _after_ the common list, any code
that uses the variable cannot assume that the list is sorted, and
needs to sort the elements if it wants to give a sorted output, so
squashing does not make the Meh-ness go away.
Well, that (mostly) sorted listed still helps to find out a little 
quicker whether a specific tool that can do both merging and diffing is 
already in the list. At least that's the case for me.
By the way, would it make sense to remove these three variables from
the completion code, and instead ask "git mergetool --tool-help"
when it needs the list of supported tools for the first time?  It
would be trivial to introduce --tool-list that gives a one tool per
line output to both "git difftool" and "git mergetool" and we would
remove the risk of separately maintained list drifting away over
time.
Sounds like a good idea now that you've added "git mergetool 
--tool-help". But I'd like to save this for a future exercise to not do 
too much stuff at the same time.

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