On 6/4/06, Junio C Hamano <junkio@xxxxxxx> wrote:
"Marco Costalba" <mcostalba@xxxxxxxxx> 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
-
: 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