Re: [PATCH] tag: support --sort=version

From: Jeff King <peff@peff.net>
Date: Feb 20, 2014, 20:43 UTC
Message-ID: <20140220204345.GA3374@sigill.intra.peff.net>
In-Reply-To: <CACsJy8CL3rQx=QHf_eABCUqS+9kZXEmopUuCMiNCL+UPyvtbyw@mail.gmail.com>

On Wed, Feb 19, 2014 at 09:19:24PM +0700, Duy Nguyen wrote:

Show 7 quoted lines

> > We don't need to do any of that immediately.  This is mostly just me
> > thinking aloud, to make sure we do not paint ourselves into a corner
> > compatibility-wise.
> 
> Good thinking. If you plan to use the exact same sort syntax f-e-r
> uses now, pick a letter (the dot I used above is probably not the
> best), I'll rewrite this patch to use the same syntax.

I think I actually prefer the full word "version", as you have already. It's clear what it means, and we can extend the syntax generally to:

  --sort=[-][comparison:]field

like:

  --sort=-version:subject

for descending version-sort by subject. And then as a special-case convenience, make "version" without a field default to "version:refname". There's no ambiguity because the set of comparison names and field-names is fixed, and we know there is no overlap.

If want to, we can _also_ give a one-letter abbreviation to the comparison field, like:

  --sort=v:subject

but that is not necessary.

So I think your patch is fine as-is. It is perhaps a little funny to start with the special case and only implement the general case later, but:

  1. We would want the special case eventually, because it is the most
     natural thing to type, and pretty clearly the most common use-case.

  2. We may not ever even end up with the general case. This is just
     about making sure that if we _do_ add it, that it fits
     syntactically with "--sort=version".

-Peff