All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <junkio@cox.net>
To: Martin Waitz <tali@admingilde.org>
Cc: git@vger.kernel.org
Subject: Re: [RFC] move --show-cdup, --show-prefix, and --show-git-dir out of git-rev-parse.
Date: Sat, 07 Oct 2006 22:43:54 -0700	[thread overview]
Message-ID: <7vvemvmkf9.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <20061007213603.GB2871@admingilde.org> (Martin Waitz's message of "Sat, 7 Oct 2006 23:36:03 +0200")

Martin Waitz <tali@admingilde.org> writes:

> I thought doing the same for these commands as for --help and --version
> but wanted to hear some opinions first...
>
> After all, the comment in front of --version talked about legacy,
> so I was afraid to add more legacy ;-)

Nothing to fear; legacy is about "version" vs "--version".

By the way, rev-parse is not about "refs" at all.  It is about
"revs".

A possibly useless comment for people unfamiliar with history I
should add is that git-rev-parse serves two completely different
purposes.  One is to separate command line parameters into four
category and output only specified kind.  Four categories come
from flags vs non-flags and arguments related to revision
traversal vs other arguments.  The "parse" in rev-parse actually
stands for this feature.  Many git Porcelainish were implemented
as shell scripts that pipes rev-list output into diff-tree, and
rev-parse was originally invented as a helper for them.

We made many "rev-list | diff-tree --stdin" pattern into
built-in commands, by introducing revision.c, so this first
feature of rev-parse has become less useful.

But as a side-feature, when showing "non-flag, revision
traversal argument", it is told how to show the object name, and
also it acquired --verify option to make sure "extended sha1
expression" (refname, refname followed by ^n, ~n etc.) are
valid.

These days, the command is used primarily to get the object name
from an extended sha1 expression.  But some commands (most
notably, bisect) still rely on the "parse" aspect of the
command.

However, in its history it has also become a kitchen sink
command.  I think it may make sense to move these kitchen-sink
features such as --show-cdup etc. out of it and give it the
direct options to git wrapper these days.  When these features
were added, git wrapper did not even exist.

      reply	other threads:[~2006-10-08  5:44 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-07 21:04 [RFC] move --show-cdup, --show-prefix, and --show-git-dir out of git-rev-parse Martin Waitz
2006-10-07 21:14 ` Jakub Narebski
2006-10-07 21:36   ` Martin Waitz
2006-10-08  5:43     ` Junio C Hamano [this message]

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=7vvemvmkf9.fsf@assigned-by-dhcp.cox.net \
    --to=junkio@cox.net \
    --cc=git@vger.kernel.org \
    --cc=tali@admingilde.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.