On 6/4/06, Paul Mackerras <paulus@xxxxxxxxx> wrote:
Marco Costalba writes:
> If I have understood correctly the patch runs a 'git rev-list --all
> --topo-order --parents'
> and then does a tree walking.
Yes, that's right. It means that gitk can show the nearest tags even
if they aren't included in the current view.
> I am wandering if there exist any native git way to found the previous tag.
I don't know of any. Doing the tree walking in Tcl turned out to be
not too much of an overhead, though; it does the whole kernel
repository in 1.5 seconds on my G5.
> As example given a selected revision with id <sha> is it possible to
> do something like this to fond the ancestor?
>
> 1) get the tag list with git-peek-remote or something similar if tags
> are not already loaded
>
> 2) given the tagList vector with n elements run
>
> git-rev-list --topo-order <sha> ^tagList[0] ^tagList[1] ....
> ^tagList[n-1]
>
> 3) take the last sha spit out by git-rev-list, be it <lastSha>.
>
> 4) Previous nearest tag is the parent of lastSha
>
> I've missed something?
I'm not sure exactly what that would do, but gitk can show more than
one tag (the term "nearest tag" is only a shorthand approximation for
what it does). For example, if you have two tagged commits where
neither is an ancestor of the other, and do a merge of the two, gitk
will show both tags when you select the merge.
What you suggest we need it's a kind of history of tags.
Currently we can run
git-rev-list --top-order --parents HEAD -- foo.c
and we get an history of file foo.c *with modified parents*
Junio, could be possible have something like
git-rev-list --top-order --parents --tags
with the history of tags ?
And, according to Paul suggestions, not only tags, but merge revisions
between tags.
A more general and IMHO very powerful tool could be something like
git-rev-list --top-order --parents --selected-only HEAD -- <sha 1>
<sha 2> ..... <sha n>
Where git rev list gives the history, with modified parents, of the
given revisions _only_ plus the merging revisions among them.
This could be used for tags (got from git-peek-remote), for branches
and in general for a given set of interesting revisions.
Once we have the history of tags, perhaps requested once at startup,
we can get the previous tags of a given revision, our original
problem, with
git-rev-list --topo-order <sha> ^tagList[0] ^tagList[1] ....
^tagList[n-1] ^merge[0] ... ^merge[k]
And have one or more tags according if results is a rev in tagList or
mergeList. Having the tag history it's easy to look up _all_ the tag
ancestors.
Marco
P.S: another use of
git-rev-list --top-order --parents --selected-only HEAD -- <sha 1>
<sha 2> ..... <sha n>
could be this:
Currently both qgit and gitk can filter revisions with a given set of
filter rules, but the results are shown together with the other
revisions or as a list of matching revisions with no useful graph
information.
We could feed git-rev-list --top-order --parents --selected-only with
the list of matching revisions and have a pretty and sensible graph
too.
-
: 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