rev-list/tree committer/author information.

LT> Anyway, everything I've read so far makes sense, and it LT> might make sense to continue git development using just LT> git-pb. The only thing I personally think sucks is the LT> author/committer matching of git-rev-list/tree, since it LT> would seem like somebody might well like to match on an LT> arbitrary part of a commit, and special-casing LT> author/committer seems somewhat broken.

Well, that author/committer thing is not in git-pb yet, if I am not mistaken [*1].

The only reason why I did it that way was because the strategy taken by "struct object" derivatives seemed to pick up bare absolute minimum to support actual callers that have immediate need for information stored in structural fields, as opposed to designing for helping yet to be written callers by adding fields to hold information of "having this might also help somebody in the future" type. And the author and committer names are in the structured fields while signed-off-by and others are not. Also when author / committer name strings are intern'ed like the way I did, the memory consumption even for a long sequence of commits are kept reasonably low. However,...

LT> I personally suspect that both git-rev-list and git-rev-tree LT> should have an alternate output format that could be more LT> easily grepped by subsequent commands. For example, right LT> now git-rev-list just outputs a list of commit ID's, and it LT> might make sense to have a flag to just append the commit LT> message to the output, and zero-terminate it (and if the LT> commit message has a NUL byte in it, just truncate it at LT> that point).

I think what you said here makes more sense [*2*]. The above implies to keep the unpacked raw data as a whole to be accessible to the callers for at least commit objects and if we go that route I think it would make more sense to do that uniformly for everything (probably except for pure "blob" objects for size concerns but we might as well do them while we are at it). On the other hand, the current lifetime rules being what it is, that strategy may introduce memory consumption problems when working on a huge project.

[Footnote]

*1* Petr has been applying quite good judgements. I would have polluted git-jc with that patch already if I were still running it. So far, I have been generally happy with his acceptance criteria for external patches. Anything he places on hold or just outright returns to me, I later find rooms for improvements myself, and the later rounds that eventually get accepted always turn out to be far cleaner, thanks to his comments.

*2* At least in principle. I am not quite sure what the output should look like for rev-tree.