On Thu, 2 Mar 2006, Junio C Hamano wrote: > > Linus Torvalds <torvalds@xxxxxxxx> 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? 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 - : 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