git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Petr Baudis <pasky@suse.cz>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: git@vger.kernel.org
Subject: Re: git-log vs git-rev-list
Date: Fri, 30 May 2008 23:34:43 +0200	[thread overview]
Message-ID: <20080530213443.GJ593@machine.or.cz> (raw)
In-Reply-To: <alpine.LFD.1.10.0805301316580.3141@woody.linux-foundation.org>

On Fri, May 30, 2008 at 01:20:13PM -0700, Linus Torvalds wrote:
> On Fri, 30 May 2008, Petr Baudis wrote:
> > Step back a bit: it's git-_REV_-list. Technically, --all --objects is
> > nonsensical operation to do on revision list either.
> 
> Who cares?

You did in case of git log.

> Why are you arguing against *facts*?
> 
> The *fact* is, git rev-list can traverse the whole object chain.
> 
> The *fact* is that git rev-list can do other operations that have nothing 
> to do with logs (bisection, for example).
> 
> The *fact* is that both git rev-list and git log can traverse a set of 
> revisions, but that doesn't make them the same command.

Huh? Of course these are facts, but I don't see what does that have to
do with anything. I'm not arguing this isn't so, I'm arguing it _is_ so
and some of it is _wrong_ from user interface standpoint.

> I totally don't see your arguments. They are pointless. git rev-list and 
> git log already share all the relevant internal machinery for the things 
> where they overlap in capabilities. And the fact that they output 
> different things is because they are different.

My argument is that there should not be two different commands with
similar interface and almost similar feature set when a single interface
would be more than enough - no matter if it is UI or an API, redundant
interfaces mean more clutter for users (or developers) to wade through
and more bitrot for the project. After all, as I said - when I've hit
the rev-list / log inconsitencies, I was not looking for UI but indeed
for an internal helper.


Having said that, I'm fine with Junio's argument that we need to keep
git-rev-list for compatibility reasons as long as the relationship
between git-rev-list and git-log is more clearly documented; I would be
happier if the few remaining options would get implemented for git-log
and git-rev-list got deprecated (which does not mean removing it right
away; git-ssh-push was removed after two years), but I don't care that
much as to flame on, it's too hot over here in Central Europe already.
:-)

I will send some documentation patches soon.


By the way, is git log regarded as porcelain or plumbing? That is, are
there any guarantees about stability of git log output format etc.? Can
I use git log in my script and rely on it to behave forever exactly as
it does now? (Modulo bugfixes.)

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

  reply	other threads:[~2008-05-30 21:35 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-30 16:56 git-log vs git-rev-list Petr Baudis
2008-05-30 17:25 ` Linus Torvalds
2008-05-30 19:46   ` Petr Baudis
2008-05-30 20:20     ` Linus Torvalds
2008-05-30 21:34       ` Petr Baudis [this message]
2008-05-30 20:22     ` Linus Torvalds
2008-05-30 20:28 ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080530213443.GJ593@machine.or.cz \
    --to=pasky@suse.cz \
    --cc=git@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).