On 5/4/07, Junio C Hamano <junkio@xxxxxxx> wrote:
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.
Let us require:
* No config settings as you prefer
* Current interpretations are unchanged.
The current path supports
:fullpath
:/string
:./relpath
[assuming core.relativepaths=no always since it goes away].
(:/string is the "find string in commit msg" feature.)
A new metacharacter lets us drop the "./" ,
and I think that's desirable.
How about = ? It's not even shifted on my keyboard:
ent=relpath
ent=2=relpath
ent=/fullpath
1. We would accept the same new metacharacter before stage if any.
2, You could still use ent:/string , or ent:fullpath .
The patch should also be extended so relpath can start
with a sequence of ./ or ../ prefixes,
which is easily handled in prepend_prefix()..
What do you think of "=" ?
--
Dana L. How danahow@xxxxxxxxx +1 650 804 5991 cell
-
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