Subject: git-log vs git-rev-list

From: Petr Baudis <[email-masked]>
Date: Fri, 30 May 2008 18:56:41 +0200

Hi,

  the baroque usage options of both git-log and git-rev-list make them
pretty much equivalent as far as I can see, except that:

  * Both have slightly different options set

  * git log --pretty=format is actually sane and does not pollute the
output with spurious 'commit' lines

  * I assume there are more subtle behaviour differences

  I think that having two commands that by now do essentially the same
thing, but slightly differently, is rather messy UI. Thus, I'm wondering
if it would be worthwhile to make rev-list a thin git-log wrapper and
start phasing it out?

  Yes, git-rev-list is supposed to be a plumbing thing, but from my
porcelain, I actually have to use git-log anyway if I'm to avoid messing
up my code with workarounds to the --pretty=format commit lines
evilness (hey, if I'm using --pretty=format, it means I actually want
to _control_ rev-list output, not having it trying to outsmart me
anyway).

  Merging porcelain and plumbing interface in a single command may sound
like a bad idea UI-wise, but I believe that consolidation would actually
result in a UI _improvement_ - you can cleanly separate the
documentation to the porcelain and plumbing part (actually, maybe
pushing all the plumbing part like --pretty documentation to
git-log-plumbing(1), having actually user-relevant options like -p or
--no-meges in git-log(1)). And you do not have to tell the user "oh, and
there is also git-rev-list(1) which does the same thing, but
differently; ah, and for some reason you are also to use only that one
if you need to query for bisect points".

  Should I do it?

-- 
				Petr "Pasky" Baudis
Whatever you can do, or dream you can, begin it.
Boldness has genius, power, and magic in it.	-- J. W. von Goethe