Rename WorkingDirectoryBackingRootPath constants#1119
Rename WorkingDirectoryBackingRootPath constants#1119chrisd8088 merged 2 commits intomicrosoft:masterfrom
Conversation
Since on Linux the relative location of the working directory backing store will be a short path (i.e., ".gvfs/lower") and not a single filename, rename the WorkingDirectoryBackingRootPath constants appropriately. Also fixup the internal name of the workingDirectoryBackingRoot argument to the common Enlistment class.
| return new Result(true); | ||
| } | ||
|
|
||
| // TODO(Linux), TODO(Mac): either adjust to "git" or remove entirely |
There was a problem hiding this comment.
Good call! An equivalent shell script could be:
#!/bin/sh
echo This repo was cloned using VFS for Git, and the git repo is in the 'src' directory
echo Switching you to the 'src' directory and rerunning your git command
cd src
git "$@"
There was a problem hiding this comment.
Of course, there are some special characters in the git.cmd that probably do color stuff, but I'm too lazy to figure out how to do that in POSIX.
There was a problem hiding this comment.
Well, and the other consideration is that where Windows will (I believe; I'm no expert) search the current directory first for an executable, on Unix systems, unless someone happens to have put . in their PATH (which is generally frowned upon), that's unlikely.
So I'm not sure if there's really any value to this kind of "redirector" script on Mac or Linux, even if we named it git. Plus I feel like it would be confusing for folks who know that VFSForGit requires a custom git binary to work properly if we also have a script named the same thing but which isn't actually that binary.
Anyway, I just wanted to flag it because it was something I bumped into along the road to GVFS.Platform.Linux. :-)
There was a problem hiding this comment.
Good point! Then, it's worth leaving as a TODO until we have a concrete decision about what to do with this step. Apparently, it was an important feature for users confused about where to go after a gvfs clone step.
There was a problem hiding this comment.
I could also open an issue on this to track it for future work, if that's useful.
There was a problem hiding this comment.
I could also open an issue on this to track it for future work, if that's useful.
I think it's worthwhile to have an issue tracking this, could you file one?
Add a TODO note regarding the "git.cmd" script which is ignored on macOS (and also Linux) as it's not in $PATH and will not override the "git" binary because the ".cmd" extension is not ignored as it is on Windows.
fa75ff7 to
8c366d0
Compare
|
Thanks very much @wilbaker! |
This PR primarily is a followup to #1102 to accommodate the fact that on Linux, the relative location of the working directory backing store will be a short path (i.e.,
.gvfs/lower) and not a single filename likesrc. Hence we rename theWorkingDirectoryBackingRootNameconstants toWorkingDirectoryBackingRootPath, akin to how other short relative path constants are constructed inGVFS.Common.GVFSConstants.DotGVFS.We also fix up the internal name of the
workingDirectoryBackingRootargument to theGVFS.Common.Enlistmentclass; it was possibly missed in #1102 because of the lowercaselinlocalStorageRoot.And we add a
TODOcomment regarding thegit.cmdscript, which is presumably unused on non-Windows platforms and would be ignored even if renamedgitas it's unlikely to be in the user'sPATH.These housekeeping changes are all in preparation, along with
#1104(DONE), #1123, and #1128 (still WIP) for #1125, which adds theGVFS.Platform.Linuxclasses and related build tooling./cc @jrbriggs, @kivikakk