On Wed, 2014-07-09 at 17:58 -0400, Jeff King wrote:
> On Wed, Jul 09, 2014 at 02:21:00PM -0700, Jacob Keller wrote:
>
> > Add support for configuring default sort ordering for git tags. Command
> > line option will override this configured value, using the exact same
> > syntax.
>
> This makes sense, and was something I was expecting to add once tag and
> branch both learned for-each-ref's sorting code. I don't think there
> will be any compatibility problems in adding it now, though; the
> ultimate interface will be the same (it will just know about more types
> of sorting).
>
I only noticed the sort recently, and I first tried to add an alias like
"tag = tag --sort=v:refname" but git didn't pick up the alias of the
name already. I use a lot of version-style tags so I wanted this to be
default. I did notice that the format of the sort parameter was actually
pretty complex, so it seemed that more was intended to be added to it.
The only main issue would be the location of the sort-configure code,
but that is actually easy to move so I don't think it's a big deal. The
configuration interface should remain similar.
> > +tag.sort::
> > + This variable is used to control the sort ordering of tags when
> > + displayed via linkgit:git-tag[5]. The current supported types are
> > + "refname" for lexicographic order (default) or "version:refname" or
> > + "v:refname" for tag names treated as versions. You may prepend a "-" to
> > + reverse the sort ordering.
>
> Your link to git-tag[5] should be to git-tag[1], I think. The final
> number is the manpage section.
>
Which I thought was 5 for the commands? Or is it always [1]?
> I was going to complain that this is duplicating the sort documentation
> from git-tag, but I see you actually moved it from the --sort option to
> here, and refer back from there to here.
>
I actually didn't remove anything from git-tag, I only added the
reference to git-config. But I can keep from duplicating the
documentation in there. I like the idea of using an included file
though.
> I think I'd prefer it the other way around (and explain this as "behave
> as if --sort=<value> had been given"). As the sort options grow, it
> seems likely that we will grow a new section in the git-tag manpage (and
> eventually probably feed that content from an include that works for all
> of for-each-ref, branch, and tag).
yes, I agree this makes more sense.
>
> > +static char *configured_tag_sort;
>
> When dealing with a config option that also has a command-line version,
> we usually forgo this separate storage for the configured value.
> Instead, we just set "sort" directly from the config callback (which may
> require making it a global so the callback can access it), and then let
> the command-line parser overwrite it.
>
Alright that makes sense. I will send a v2 soon. Thanks for the
comments.
> -Peff
Regards,
Jake
��.n��������+%������w��{.n��������n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�