Re: [PATCH] rev-parse --show-prefix: add in trailing newline

Ross Lagerwall [off-list ref] writes:

fc68875 (t1501 (rev-parse): clarify, 2010-07-24) says it is a "possible
bug", but I do not think the expectation of the new test added by that
commit is entirely correct.

Because the assignment will strip the trailing LF away adding an extra
newline at the end would not matter in practice in many scripts, e.g.

	a=$(git rev-parse --show-prefix)
        if test -z "$a"
        then
		echo we are at toplevel
	fi

or

	pfx=$(git rev-parse --show-prefix)
	cd_to_toplevel
	for arg
        do
		case "$arg" in
                /*)
                       	user refers to "$arg" that is a full path ;;
		*)
			user refers to "$pfx$arg" ;;
		esac
	done

But it will break existing scripts if they expect the following to work:

	file="$(git rev-parse --show-prefix)/$1"
        cd_to_toplevel
        test -f "$file"

On 2012/04/09 21:07, Junio C Hamano wrote:

fc68875 (t1501 (rev-parse): clarify, 2010-07-24) says it is a "possible
bug", but I do not think the expectation of the new test added by that
commit is entirely correct.

Because the assignment will strip the trailing LF away adding an extra
newline at the end would not matter in practice in many scripts, e.g.

True, and the current behavior does exactly what the man page says:
"When the command is invoked from a subdirectory, show the path of the 
current directory relative to the top-level directory."

So then perhaps the test should be removed?

Also, --show-cdup has a similar description for the man page but does 
output a newline when invoked from the root dir. Should this behavior be 
made consistent?

-- 
Ross Lagerwall

Junio C Hamano wrote:

But it will break existing scripts if they expect the following to work:

	file="$(git rev-parse --show-prefix)/$1"
        cd_to_toplevel
        test -f "$file"

Huh?  I tried this:

	$ foo="$(printf '\n')/bar"
	$ printf '%s\n' "$foo"
	/bar

If that didn't work, it would mean that "git rev-parse --show-prefix"
would never work when the prefix is nonempty, because it is followed
by a newline.