From: "Theodore Ts'o" <tytso@mit.edu>
To: git@vger.kernel.org
Subject: Questions about git-rev-parse
Date: Tue, 27 Feb 2007 21:23:37 -0500 [thread overview]
Message-ID: <E1HMETh-0004BO-Lw@candygram.thunk.org> (raw)
So I was looking at git-rev-parse trying to understand the man page, as
I was trying to understand how various commands can accept lists (or
ranges) of commits, and the man page raised a number of questions.
First of all, the DESCRIPTION section doesn't quite parse as English:
Many git porcelainish commands take mixture of flags (i.e. parameters
that begin with a dash -) and parameters meant for underlying
git-rev-list command they use internally and flags and parameters for
other commands they use as the downstream of git-rev-list.
But, as best as I can gather that it's a helper function meant to do
some basic options parsing for those git porcelain commands that expect
to take a set of revision ID's.
This raises some additional questions, though. If the goal of this
command is to parse out those options and arguments which are meant for
git-rev-list, why does it translate tag names to SHA id's:
% git-rev-parse v1.5.0..v1.5.0.1
dedb0faa48787839dbc47b7ca2507bda5924ec2c
^6db027ffe03210324939b3dd655c4223ca023b45
After all, git-rev-list can just as easily accept:
git-rev-list dedb0faa48787839dbc47b7ca2507bda5924ec2c \
^6db027ffe03210324939b3dd655c4223ca023b45
as
git-rev-list v1.5.0..v1.5.0.1
Also, there are a number of options in git-rev-list which make it appear
to be a general dumping ground of miscellaneous options.
For example, it's not clear what
git-rev-parse --show-prefix
and
git-rev-parse --show-cdup
have to do with the description of git-rev-parse as described in the
DESCRIPTION section. It seems to be completely miscellaneous extras
that were tacked on. Or am I missing something?
Finally, it seems rather unfortunate that certain bits of functionality
such as --since and --until were hidden into git-rev-parse, since it
means that some commands which are implemented as shell scripts are more
likely to use git-rev-parse, and will therefore support --since and
--until, where as other commands which are implemented as built-in's,
such as git-log, don't accept --since and --until.
So I'm wondering if I'm missing something about historical context,
since from looking at git-rev-parse, it looks like not a lot of thought
went into its design, and it has a bunch of stuff that grew via
accretion; or maybe I'm not understanding why it was designed the way it
was?
Regards,
- Ted
next reply other threads:[~2007-02-28 2:23 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-28 2:23 Theodore Ts'o [this message]
2007-02-28 2:40 ` Questions about git-rev-parse Junio C Hamano
2007-02-28 2:52 ` Theodore Tso
2007-02-28 3:33 ` Linus Torvalds
2007-02-28 6:40 ` Theodore Tso
2007-02-28 8:54 ` Andy Parkins
2007-02-28 16:00 ` Linus Torvalds
2007-02-28 3:19 ` Linus Torvalds
2007-03-01 2:16 ` Willhelm Busch
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=E1HMETh-0004BO-Lw@candygram.thunk.org \
--to=tytso@mit.edu \
--cc=git@vger.kernel.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.