From: Linus Torvalds <torvalds@osdl.org>
Date: Mon, 16 May 2005 16:10:10 GMT
Subject: Re: Summary of core GIT while you are away.
Message-ID: <Pine.LNX.4.58.0505160837080.28162@ppc970.osdl.org>
In-Reply-To: <7vzmuy13od.fsf@assigned-by-dhcp.cox.net>




On Sat, 14 May 2005, Junio C Hamano wrote:
>
> Hoping that you had a good time during your vacation, and at the
> same time also hoping to help you catch up with GIT traffic,
> here is my version of the summary of things that happened in the
> GIT community around core GIT [*1*].

Thanks. I'm back and reading email, but have by no means caught up yet.

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

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

Then you could just do

	git-rev-list -v --header HEAD | grep -z 'author[^\n]*Linus'

to tell it to do the "verbose" thing (only showing the header of the 
commit, not the whole message), and grep for "Linus" in the author line.

Or, if you want to see all commits that are signed off by so-and-so, do:

	git-rev-list -v HEAD | grep -zi 'signed-off-by:[^\n]*so-and-so'

and it would still be pretty efficient, and a _lot_ more generic and 
flexible than the "--author" and "--committer" flags.

I also suspect that a lot of uses if git-rev-{tree|list} actually want to 
see the commit stuff anyway, ie things like gitweb etc currently likely 
end up doing a separate "git-cat-file commit <sha1>" to get the whole 
commit information, which the "-v" flag would just give directly.

The only question is whether you want to have it be human-readable by
default (indent the message lines with a <tab>, and nonheaders with
<tab>+4*<space> or something), and then have a "-z" flag to do the
machine-readable version described above.

Hmm?

		Linus