Re: Git tag output order is incorrect (IMHO)

From: Jeff King <peff@peff.net>
Date: Sep 8, 2013, 08:03 UTC
Message-ID: <20130908080311.GA25498@sigill.intra.peff.net>
In-Reply-To: <CALWbr2w7XCuD5tUSwR+Cwv4wyXLk8MHDGyU2Dr+jA9vOfDYqig@mail.gmail.com>

On Tue, Aug 20, 2013 at 05:12:47PM +0200, Antoine Pelisse wrote:

Show 8 quoted lines

> On Sat, Jul 20, 2013 at 2:22 AM, Jeff King <peff@peff.net> wrote:
> > I do plan to finish it eventually, but if anyone else feels like picking
> > it up, I'd be glad to review patches and/or share my work-in-progress as
> > a starting point.
> 
> I have some free time to come, and would like to work on that feature.
> Does the offer still hold ?
> If it does, I would be interested in your patches.

I'm sorry I have taken so long to get back to you on this. I was hoping to revisit the topic and make sure the patches were in a sensible state for showing to somebody. But it took me some time to get around to it, and now that I have, they're really not looking very good.

My general strategy was to factor out all of the "which refs to select" code from git-tag (which knows --contains and --points-at) and git-branch (which knows --merged, --no-merged, and --contains), and then make them all available in a library-ish way to both commands, as well as for-each-ref (which also knows name matching, which all 3 should know, too). You can see my messy in-progress commit (that does not even compile) at:

  git://github.com/peff/git.git jk/contains-wip

Part of the complication is that the filters have to happen at different times (you can efficiently ask "--contains" for each ref as you see it, but asking "--merged" must happen after you have collected each one).

I do not recall at this point what other issues led me to stop working on it (it may simply have been time for dinner, and I never came back to it). So the patches there may or may not actually be helpful to you.

Sorry I can't be more helpful. I'd be happy to discuss or review if you want to work on it.

-Peff