Re: [PATCH v2 1/2] rev-parse: add --filename-prefix option

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 9, 2013, 20:57 UTC
Message-ID: <7vtxnfpglq.fsf@alter.siamese.dyndns.org>
In-Reply-To: <0d570e110dbf714310f9cbc4fa47e711630707f2.1365539059.git.john@keeping.me.uk>

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

Show 5 quoted lines

> This adds a prefix string to any filename arguments encountered after it
> has been specified.
>
> Signed-off-by: John Keeping <john@keeping.me.uk>
> ---

Stale subject?

Show 14 quoted lines

> +--prefix <arg>::
> +	Behave as if 'git rev-parse' was invoked from the `<arg>`
> +	subdirectory of the working tree.  Any relative filenames are
> +	resolved as if they are prefixed by `<arg>` and will be printed
> +	in that form.
> ++
> +This can be used to convert arguments to a command run in a subdirectory
> +so that they can still be used after moving to the top-level of the
> +repository.  For example:
> ++
> +----
> +prefix=$(git rev-parse --show-prefix)
> +cd "$(git rev-parse --show-toplevel)"
> +eval "set -- $(git rev-parse --sq --prefix "$prefix" "$@")"

I think you should tighten rev-parse parameter to reject options and revisions, especially as an example to teach how to use it. When the user said

	git mylog -U20 master..next -- README

inside Documentation/ directory, "git-mylog" script would want to see README prefixed with Documentation/ but want to see -U20 or master..next untouched. Historically, rev-parse was a way to sift options and args meant for rev-list from those mant for diff-tree so that a variant of

	git rev-list $(git rev-parse --revs) "$@" |
        git diff-tree --stdin $(git rev-parse --no-revs)

can be used to implement such "git mylog" script.

I think "--no-revs --no-flags" is how you ask it to give you only the paths, but I am writing from memory so please double check.

Having said all that.

Existing scripts (e.g. "git am") do this kind of things without such an option added to rev-parse. They first do:

    prefix=$(git rev-parse --show-prefix)

and refer to "$prefix/$1", "$prefix/$2", etc., I think.

Is this option really necessary to update "git submodule"? Don't we have a much better idea which parameter holds user-supplied path in the script than having rev-parse make a guess on the entire "$@"?