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.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html