Re: [PATCH] Support ent:relative_path

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.