git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: John Keeping <john@keeping.me.uk>
Cc: git@vger.kernel.org
Subject: Re: [RFC/PATCH] rev-parse(1): logically group options
Date: Fri, 19 Jul 2013 13:35:10 -0700	[thread overview]
Message-ID: <7v4nbquw3l.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <8ab5f3c276e6f623a8056674c9306334efc9fefe.1374174438.git.john@keeping.me.uk> (John Keeping's message of "Thu, 18 Jul 2013 20:07:29 +0100")

John Keeping <john@keeping.me.uk> writes:

> The options section of the git-rev-parse manual page has grown
> organically so that there now does not seem to be much logic behind the
> ordering of the options.  It also does not make it clear that certain
> options must appear first on the command line.
>
> Address this by reorganising the options into groups with subheadings.
> The text of option descriptions does not change.
>
> Signed-off-by: John Keeping <john@keeping.me.uk>

The idea to introduce a general grouping makes a lot of sense, I think.

> +Operation Modes
> +~~~~~~~~~~~~~~~
> +
> +Each of these options must appear first on the command line.
> +
> +--local-env-vars::
> +	List the GIT_* environment variables that are local to the
> +	repository (e.g. GIT_DIR or GIT_WORK_TREE, but not GIT_EDITOR).
> +	Only the names of the variables are listed, not their value,
> +	even if they are set.

Honestly speaking, "must appear first" for "--local-env-vars" is a
bug in implementations of this option, I think.  It does not make
sense to ask

	git rev-parse --local-env-vars -- Makefile

and the command operates on "--" and "Makefile" in the normal
operation mode, not "local-env-vars" mode.

> +
>  --parseopt::
>  	Use 'git rev-parse' in option parsing mode (see PARSEOPT section below).
>  
> +--resolve-git-dir <path>::
> +	Check if <path> is a valid repository or a gitfile that
> +	points at a valid repository, and print the location of the
> +	repository.  If <path> is a gitfile then the resolved path
> +	to the real repository is printed.
> +
> +--sq-quote::
> +	Use 'git rev-parse' in shell quoting mode (see SQ-QUOTE
> +	section below). In contrast to the `--sq` option below, this
> +	mode does only quoting. Nothing else is done to command input.

> +Options for Input
> +~~~~~~~~~~~~~~~~~
>  
> +--show-toplevel::
> +	Show the absolute path of the top-level directory.
> +
> +--show-cdup::
> +	When the command is invoked from a subdirectory, show the
> +	path of the top-level directory relative to the current
> +	directory (typically a sequence of "../", or an empty string).
> +
>  --is-inside-git-dir::
>  	When the current working directory is below the repository
>  	directory print "true", otherwise "false".
> @@ -188,17 +219,10 @@ print a message to stderr and exit with nonzero status.
>  --is-bare-repository::
>  	When the repository is bare print "true", otherwise "false".
>  
> +--show-prefix::
> +	When the command is invoked from a subdirectory, show the
> +	path of the current directory relative to the top-level
> +	directory.

I am not sure if --show-*, --is-*, and --git-dir belongs to "options
for input".  They are truly kitchen sink options to ask for various
aspects of the repository and directory, and it may be equally valid
(or even more valid) to consider them as separate operation modes.

  reply	other threads:[~2013-07-19 20:35 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-18 19:07 [RFC/PATCH] rev-parse(1): logically group options John Keeping
2013-07-19 20:35 ` Junio C Hamano [this message]
2013-07-21 12:49   ` [PATCH v2 0/2] Improvements to rev-parse option handling John Keeping
2013-07-21 12:49     ` [PATCH v2 1/2] rev-parse: remove restrictions on some options John Keeping
2013-07-21 12:49     ` [PATCH v2 2/2] rev-parse(1): logically group options John Keeping
2013-07-22 22:30       ` 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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=7v4nbquw3l.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=john@keeping.me.uk \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).