From: Marco Costalba Date: Mon, 05 Jun 2006 11:54:35 GMT Subject: Re: Gitk feature - show nearby tags Message-ID: In-Reply-To: <7vhd305dk9.fsf@assigned-by-dhcp.cox.net> On 6/5/06, Junio C Hamano wrote: > "Marco Costalba" 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