Johannes Sixt <j6t@xxxxxxxx> writes:
> On Samstag, 23. Januar 2010, Robin Rosenberg wrote:
>> It seems this function does something unhealthy when you pass a path of the
>> form //server/share. On windows dropping the double // at the beginning
>> makes it a different path since // is the UNC prefix.
>
> There is no problem in practice.
>
> The function returns either the input unmodified, or it strips also at least
> one directory component, except when base is only "/" (or "//" or "///"...).
> I said in practice, because on Windows it does not make sense to invoke git
> with (literally)
>
> git --git-dir=//server/share/repo.git --work-tree=/ ...
>
> i.e., without a drive prefix before the slash of --work-tree.
If you did this:
git --git-dir=//reposerver/repo.git --work-tree=//buildserver/workarea
then we would say "one is not a prefix of the other", so it would be
fine. At least I don't think the "recover from unintentionally doubled
slashes in user supplied path" fix is introducing any new problem in that
case.
If on the other hand, if you did this:
git --git-dir=//server/repo.git --work-tree=//server/workarea
that also would be Ok.
I think one issue is what happens when you did this:
cd //server
git --git-dir=//server/repo/repo.git --work-tree=repo
Does msysgit implementation figures out that the work tree is located at
"//server/repo" when get_git_work_tree() is asked to produce an absolute
path so that it can be compared with //server/repo/repo.git with the code?
If it does (with the leading double slash), then "doubled slahses fix" is
a regression we should do something about it. If it doesn't, then it
probably doesn't matter.
--
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