On 6/5/06, Junio C Hamano <junkio@xxxxxxx> wrote:
"Marco Costalba" <mcostalba@xxxxxxxxx> 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
-
: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html