Re: [PATCH] remote: improve sorting of "configure for git push" list
- From
Jay Soffian <jaysoffian@gmail.com>
- Date
- Mar 22, 2009, 14:47 UTC
- Message-ID
- <76718490903220747p74cf3704vbbbc085c28a105b2@mail.gmail.com>
- In-Reply-To
- <20090322085920.GA5201@coredump.intra.peff.net>
On Sun, Mar 22, 2009 at 4:59 AM, Jeff King <peff@peff.net> wrote:
Show 25 quoted lines
> 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@peff.net> > --- > 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.