Re: Gitk feature - show nearby tags

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

On 6/4/06, Junio C Hamano <junkio@cox.net> wrote:
> "Marco Costalba" <mcostalba@gmail.com> writes:
>
> >> Sorry, in the example time flows from left to right.  If you
> >> exclude g then you are excluding everything that is reachable
> >> from g so you would not see "f".
> >>
> > From today git:
> >
> > tag list is:
> >
> > v1.3.3 1b9bc5a7b7434d771726011613a00cb202bd9f44
> > v1.3.2 7abd7117ec57b8c3c2a469db62c7811fdac5c655
> > v1.3.1 7d09fbe4ab7f080a8f8f5dcef7e0f3edf5e26019
> > v1.3.0 4baff50551545e2b6825973ec37bcaf03edb95fe
> >
> > selected sha is ccb365047a1081455b767867f0887e7b4334f9d8
> > (Allow "git repack" users to specify repacking window/depth)
> >
> > $ git-rev-list --topo-order ccb365047a1081455b767867f0887e7b4334f9d8
> > ^1b9bc5a7b7434d771726011613a00cb202bd9f44
> > ^7abd7117ec57b8c3c2a469db62c7811fdac5c655
> > ^7d09fbe4ab7f080a8f8f5dcef7e0f3edf5e26019
> > ^4baff50551545e2b6825973ec37bcaf03edb95fe
> >
> > ccb365047a1081455b767867f0887e7b4334f9d8
> > ...
> > cd2bdc5309461034e5cc58e1d3e87535ed9e093b
> >
> > Parent of cd2bdc5309461034e5cc58e1d3e87535ed9e093b is
> >
> > 4baff50551545e2b6825973ec37bcaf03edb95fe
> >
> > aka tag v1.3.0
> >
> > Am I missing something?
>
> No, just that I am not getting what you are trying to prove
> here.  The tags are all older than your chosen commit.
>
> $ git-rev-list --topo-order ^v1.3.0 ^v1.3.1 ^v1.3.2 ^v1.3.3 e923eff
>
> would show nothing -- and you propose to find out that commit is
> between v1.3.1 and v1.3.2 by using the information that the
> command gives an empty result but I do not know how?
>

OK. Now I understand.

I was erroneously thinking that in

$ git-rev-list --topo-order e923eff ^v1.3.0 ^v1.3.1 ^v1.3.2 ^v1.3.3

the listing (and searching) was _starting_ from e923eff, i.e. all the
previous stuff, in our case v1.3.2 and v1.3.3 was never seen neither
filtered out.

Following an extract from git-rev-list documentation.

DESCRIPTION
-----------
Lists commit objects in reverse chronological order *starting at the
given commit(s)*, taking ancestry relationship into account.  This is
useful to produce human-readable log output.

Commits which are stated with a preceding '{caret}' *cause listing to stop at
that point*. Their parents are implied. "git-rev-list foo bar {caret}baz" thus
means "list all the commits which are included in 'foo' and 'bar', but
not in 'baz'".



Perhaps it's me, but I really don't found clear from documentation
that git-rev-list anySha ^HEAD gives _always_ an empty result.

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.

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

If I have understood correctly with this change the above proposed
algorithm should work.

    Marco