Linus Torvalds [off-list ref] writes:
Yeah, I actually looked at a few examples, so I knew what it was basically
trying to do, and then I ignored it as not interesting to the exercise,
which was to abuse the new revision listing library in interesting ways by
calling it multiple times.
Abuse is exactly the word. The reason it is an abuse is exactly
why you said "... but to fix it you'd have to actualyl walk the
parent list yourself, rather than letting get_revision do it all
for you." Which relates to the fact that object.c layer is not
designed to be used multiple times...
Maybe we want to make object.c layer reusable first?
On Thu, 2 Mar 2006, Junio C Hamano wrote:
Linus Torvalds [off-list ref] writes:
quoted
Yeah, I actually looked at a few examples, so I knew what it was basically
trying to do, and then I ignored it as not interesting to the exercise,
which was to abuse the new revision listing library in interesting ways by
calling it multiple times.
Abuse is exactly the word. The reason it is an abuse is exactly
why you said "... but to fix it you'd have to actualyl walk the
parent list yourself, rather than letting get_revision do it all
for you." Which relates to the fact that object.c layer is not
designed to be used multiple times...
Maybe we want to make object.c layer reusable first?
No, the "abuse" is actually very much done that way on purpose. It's a bit
strange to do "incremental" prepare_revision_walk() calls, but it all
comes from the fact that the object structures are "persistent" across the
calls, even if we remove them from the list when we walk them.
So it's strange, but that was kind of part of the reason for doing it.
It's a _good_ strangeness.
The thing about handling commits that were already in another branch but
weren't shown is different: the way to handle that is to generate the
_whole_ revision list in one go - instead of incrementally - and then for
each branch you merge you show the top 10 "not yet shown" commits.
IOW, that thing would never use "get_revision()" at all, but would instead
depend on "prepare_revision_walk()" generating the whole tree, and then
you just walk the parent pointers from the branch heads by hand, marking
then "seen" as you print them.
So the object layer and the revision parsing actually does exactly the
right thing, you just have to decide on how to use them..
Linus