On Sun, Mar 22, 2009 at 4:59 AM, Jeff King <peff@xxxxxxxx> wrote: > The data structure used to store this list is a string_list > of sources with the destination in the util member. The > current code just sorts on the source; if a single source is > pushed to two different destination refs at a remote, then > the order in which they are printed is non-deterministic. > > This patch implements a comparison using both fields. > Besides being a little nicer on the eyes, giving a stable > sort prevents false negatives in the test suite when > comparing output. > > Signed-off-by: Jeff King <peff@xxxxxxxx> > --- > The discussion of the proper interface to the one-line wrapper to qsort > didn't really resolve anything. It seems that the constraints of C make > a nice wrapper a little painful, so let's just use a bare qsort. Once > again, I really don't care what it looks like, so feel free to mark it > up if you prefer differently; I just want it off my todo list, and to > let JSixt run his tests in peace. > > I did have one somewhat sick thought for an API: have string_list's > cmp_items (or an alternate cmp_items_with_util) treat a non-NULL util > member as a pointer to a string, and use it as a secondary key in the > sort. It works here because the first member of the push_info struct is > the secondary key. But I think it is a bit too subtle for my taste. Ack. There is one thing I wonder though. Is this even a sane config? It's accepted, but is that intentional or just an accident? Would anyone notice if the push parsing were changed to only accept a single dest for a given source branch? Thanks for the patch Jeff. j. -- 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
