Michael Haggerty <mhag...@alum.mit.edu> writes:

> 1. Document that string_list sorts entries according to their strcmp()
> order, as proposed in this patch.  Then fetch can rely on this ordering.
>  If somebody wants a different ordering in the future, it is easy to
> make the sort order a parameter.
> 2. Leave string_list's "default" sort order unspecified, but already
> implement a way to let string_list users specify a particular sort
> order.  Change the fetch machinery to specify a strcmp()-based ordering
> explicitly.  This approach has the advantage of letting the default sort
> order of string_list to be changed, though I don't really see how this
> would be helpful.
> 3. Change fetch back to doing its own sorting again, rather than relying
> on sort_string_list().  This isn't a lot of work (inline the one line of
> sort_string_list(), then either make string-list.c:cmp_items() public or
> duplicate that function too).

I haven't looked at non-users of string-list API, but my gut feeling
has been that lack of 2. made the API less useful for current
non-users, possible callers that could benefit from something like
string-list that lets them specify their own sort order.

Also, I actually am more worried about us wanting to change the
order in which ref-list is sorted, rather than somebody randomly
deciding to change the default (and only) order string-list is
sorted on.  When that happens, we would have even less useful
string-list left behind, with a documented invariant that is not
helping anybody if we choose to do 1 now.

So to me, if we really wanted to avoid doing 2 prematurely (which is
a sensible concern, by the way), the more sensible option between 1
and 3 would be 3.  That makes my preference 2, 3 and then 1 (but I
do not care too deeply between 2 and 3).
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

Reply via email to