On 23.07.2012 20:37, Junio C Hamano wrote:
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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html