Re: Gitk feature - show nearby tags

[Junio C Hamano <junkio@cox.net>]

"Marco Costalba" <mcostalba@gmail.com> writes:

> What I understand is that git-rev-list lists _first_ the given commit,
> then his parents, then his grandparents and so on _until_ a commit
> which is stated with a preceding '{caret}'  is found.
> So everything that is between the given commit and HEAD is never found
> and ignored.

As you now know, the way it works is that it takes an unordered
set of committishes, and performs a set operation that says
"include everybody reachable from positive ones while excluding
everybody reachable from negative ones".  --topo-order tells it
to topologically (instead of doing the commit date-order which
it does by default) sort the resulting list.  The resulting list
is then written out.

> Is it a problem to change the git-rev-list behaviour to reflect (my
> understanding of) documentation or it breaks something?

I suspect it would break quite many things.  Existing users use
the command knowing it is a set operation on an unordered set of
committishes, and expect the command to behave that way.  Also
the most typical use A..B translates to ^B A (either internally
or by rev-parse) so "the first" would typically be a negative
one.

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.  

How would you ask the same question to the modified rev-list
that does "start from positive ones, traverse one by one and
stop traversal that hits the negative one" logic?

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.

But that would not be rev-list; I suspect you would end up doing
something quite similar to what show-branch does.