From: Junio C Hamano <junkio@cox.net>
Date: Fri, 04 May 2007 08:21:04 GMT
Subject: Re: [PATCH] Support ent:relative_path
Message-ID: <7v7irpuhhr.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <56b7f5510705040022x2e4903d3hbe4ac1ee1a2e096f@mail.gmail.com>

I do not think it is wrong per-se, to want to make this hold true:

	A=$(git rev-parse :somedir/file)
	B=$(cd somedir && git rev-parse :file)
        test "$A" = "$B"

One thing I am reasonably certain however is that this should
NOT be conditional to a config setting.  Doing so would force
scripts that take (or compute) path and commit and concatenate
them to make "${commit}:${path}" to name a blob (or tree) to
first inspect the current setting of core.relativepaths and undo
what the new code does by prefixing/subtracting the prefix
string depending on the config.

In other words, having that config is not really helping scripts
or compatibility.

I think the choices are:

 (1) we say it was a mistake that we did not make it relative to
     the current directory when we introduced the X:<path>
     syntax (X could be empty or :[0-3]: for index, or a commit
     or tree object name), and change the semantics in a future
     major release for everybody, apologizing for potentially
     breaking existing scripts; or

 (2) keep the current behaviour as is, and come up with a
     different syntax to use relative; or

 (3) do nothing.

My preference is (2), (3) and then (1), but I do not have
offhand a suggestion for a good metacharacter we could use.