H. Peter Anvin wrote: > Junio C Hamano wrote: >> "H. Peter Anvin" <hpa@xxxxxxxxx> writes: >> >>> For heaven's sake, in computer science we can *NEVER* use the same >>> feature for *MORE THAN ONE THING*. If it doesn't work format-wise >>> that's fine, but "it's only supposed to be used by dumb transports" is >>> ridiculous. Please, for the future, mark irony if it might be mistaken... >> Hmmmm... I am lost here.... > > Jakub and Johannes seems to have been arguing that "info/refs is for > dumb transports, therefore it cannot be used for any other purpose." I > find this argument utterly bizarre, since in general, in computer > science, you try to be multipurpose whenever practical. First, changing info/refs format _might_ break fetch related scripts, which rely on git-peek-remote / git-ls-remote / info/refs format. Second, it is a bit impractical because info/refs contain (and must contain) also _tags_ information (which is not needed for gitweb "Last Change" field in projects list) and referenced object for those tags. Tags need not to point to commits, nor dereference to commits: for example in git.git tags v1.0rc1 to v1.0rc6 points to other tags, and junio-gpg-pub point to out-of-tree blob (which does not have any "commit time" associated). So what to write there in the "commit time" field? What to write in "commit time" for tags? -- Jakub Narebski Poland - To unsubscribe from this list: 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