Wincent Colaiuta [off-list ref] writes:
Oh, I wouldn't like that at all. I think it would be a very ugly UI
wart, because it would basically make Git behave differently than
every other command line tool that accepts paths. If it is to deviate
from the extremely widespread convention that paths starting with /
refer to absolute paths rooted at the root of the filesystem, then the
justification for it would need to be very strong indeed.
There are at least two flaws in that argument.
- git does not accept paths (it lets you specify patterns that match,
e.g. t/ to name ptahs under t/ directory).
- "/pathspec" does follow the widespread convention that a string that
begin with a "/" refer to a path rooted at the root _in the context_;
the definition of root may or may not match the filesystem root.
Think of things like <a href="/$path">Top</a>. Does "/$path" mean at
the root of filesystem? No.
I am not married to the "git grep -e frotz /Documentation" notation, by
the way. I just didn't think of a different notation that is equally
short, sweet and logical. We could do //Documentation if it makes it more
distinct, but I do think it is worse than a single slash.
Junio C Hamano wrote:
- git does not accept paths (it lets you specify patterns that match,
e.g. t/ to name ptahs under t/ directory).
Here is where it get interesting!
Our users, new and old alike, are wanting consistency. Consistency
amongst the git commands. Consistency with their platform of choice.
Consistency with what they are familiar with, Consistency with their
expectations.
Declaring that git commands (all?!) do not take paths but patterns does
not help the situation; however technically correct it may be.
- "/pathspec" does follow the widespread convention that a string that
begin with a "/" refer to a path rooted at the root _in the context_;
the definition of root may or may not match the filesystem root.
But the users are almost always dealing with things (objects) that
started as files, act like files and may be files again. Why should they
not expect filesystem semantics.
On Wed, Nov 25, 2009 at 5:00 PM, Junio C Hamano [off-list ref] wrote:
- git does not accept paths (it lets you specify patterns that match,
e.g. t/ to name ptahs under t/ directory).
That's not entirely true, unfortunately:
$ echo >> unpack-trees.c
$ git diff --name-status unpack-trees.c
M unpack-trees.c
$ git diff --name-status $PWD/unpack-trees.c
M unpack-trees.c
$ git diff --name-status $PWD/../git/unpack-trees.c
M unpack-trees.c
$ git diff --name-status ../git/unpack-trees.c
fatal: '../git/unpack-trees.c' is outside repository
So it seems that 'git diff' accepts absolute paths as long as they end up
in the repository, but oddly enough, doesn't do so for relative paths.
It's possible that some users have scripts that use absolute paths, and
changing the interpretation would break those scripts. Such scripts
*should* be rare, so maybe it's ok to break them, but it needs to be
considered.
James