"Frans Klaver" <fransklaver@xxxxxxxxx> writes:
> Actually I went through diagnosing and fixing it. After tracking it
> down, I did wonder about this question myself and I didn't come to a
> definitive conclusion on it. On one hand I do agree that it may be an
> incentive for the user to fix his path. On the other hand I found it
> an obscure one to track down; git's behavior doesn't match bash
> behavior:
>
> $ git config --global alias.aliasedinit init &&
> mkdir searchpath && chmod 400 searchpath &&
> PATH=$(pwd)/searchpath:$PATH && export PATH &&
> mkdir someproject && cd someproject &&
> git aliasedinit
> fatal: cannot exec 'git-aliasedinit': Permission denied
Imagine you did not have alias.aliasedinit in ~/.gitconfig but had a
script called $(pwd)/searchpath/git-aliasedinit which we would fail to
execute. What message would we get in that case? Currently I think we get
permission denied.
Would we get the same with your patch, or something that does not hint
at all that there is a permission problem?
See also the "tangent" part of
http://thread.gmane.org/gmane.comp.version-control.git/171755
and the discussion that follows it. I do not think we reached any
conclusion nor a patch.
--
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