Re: Gitk feature - show nearby tags

From: Junio C Hamano <junkio@cox.net>
Date: Jun 5, 2006, 06:20 UTC
Message-ID: <7vhd305dk9.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <e5bfff550606040657p5c1a3dceq3eef254ab64f0e3a@mail.gmail.com>

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

Show 5 quoted lines

> 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.