Re: Gitk feature - show nearby tags

["Marco Costalba" <mcostalba@gmail.com>]

On 6/5/06, Junio C Hamano <junkio@cox.net> wrote:
> "Marco Costalba" <mcostalba@gmail.com> writes:
>
> I think your "start from positive ones, traverse one by one and
> stop traversal that hits the negative one" logic requires the
> negative one to be directly on the traversal paths starting from
> positive ones to have _any_ effect.  We often ask "what's the
> ones that are still not merged to the master from the side
> branch" while dealing with topic branches:
>
>          c-------d---e master         time flows from
>         /       /                     left to right
>  --a---b---x---y---z side
>
> and the way to ask that question is "rev-list master..side"
> (which is "rev-list side ^master").  It should list z and not
> show y nor x nor b nor a.
>
> In order for it to be able to notice that y should not be
> listed, it needs to perform traversals from negative ones as
> well in order to learn that y is reachable from master.
>

Thanks for your clear explanation. Now I see much better what's the deal.

>
> I think one useful thing we can do is to generalize what
> "describe", "nave-rev", and "merge-base" do to have a command
> that takes a committish X and a set of other committish T1..Tn,
> and examines if Ti (1<=i<=n) is reachable from X and if X is
> reachable from Ti (1<=i<=n), and give a short-hand to specify
> the set of T for common patterns like --heads --tags and --all.
>

I don't know if this is enough for our original problem to find previous tag.

Our problem is indeed not only to find previous tags, but _nearest_
previous, so I think we have to think to a generalization that takes
in account also a kind of 'metric' among tags because the only
reachability seems to fall short in finding the nearset one.

But definitely I need to think more about this ;-)

   Marco