Sebastian Schuberth <sschube...@gmail.com> writes:
>> 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
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html