Re: Summary of core GIT while you are away.

From: Linus Torvalds <torvalds@osdl.org>
Date: May 16, 2005, 16:10 UTC
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:

Show 5 quoted lines

>
> 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