On Wed, 8 Jun 2016 08:24:10 -0700 (PDT)
Derell Licht <derell.li...@gmail.com> wrote:
> Here at my company, we are moving from Subversion to Git. I have
> converted several of our projects over to Git, with submodules, and
> all is working fine...
>
> for me, on Windows 7 64-bit...
>
> However, I have a co-worker who uses Linux, and there we have a
> problem.
>
> All of the repositories are on a network drive: //ntws4/Git
Before we begin, is there any real pressing reason to keep things this
way? Accessing Git repos via shares should work (and the devs try to
make it work) but it was and is a source of subtle bugs.
The reason is that when you access a repository on a share it's not
remote but is rather local: because pushes/fetches are served solely by
a Git instance running on your local computer.
This poses two problems:
* Any network glitch occuring when that Git instance writes data is
roughly equivalent of the failure of your hard disk drive when Git
works locally. Sure, Git is written in a smart way to try to minimize
the damage in such situations but still a failure of the HDD is highly
less likely.
* There is the possibility of "impedance mismatch" between the
filesystem backed by the share and the capabilities of the local
system. Say, filesystem on a POSIX systems support executable bit
on files, and Git is able to record it and restore it on checkout
but CIFS/SMB shares do not support it. Another issue is case
sensitivity which is normally off on CIFS shares. I dunno whether
Git running on a POSIX system is able to reliably detect all this when
working with a repo located on a Windows share.
> When I check out Svr10 project, which has a submodule named der_libs,
> I use:
>
> git clone //ntws4/git/Svr10 -b develop Svr10_dev --recursive
>
> However, my co-worker on Linux, has to use:
>
> *git clone
> /run/user/1000/gvfs/smb-share:server=192.168.1.122,share=git/Svr10 -b
> develop Svr10 --recursive*
You could suggest them take a look at the smbnetfs program which allows
to use a slightly more convenient naming scheme. For instance, I have
all my corporate Windows network "mounted" under ~/Network.
> This works, except for the submodule(s)... for this
> project, .gitmodules contains:
>
> [submodule "der_libs"]
> path = der_libs
> url = //ntws4/Git/der_libs
> branch = develop
>
> but that URL is not valid under Linux... How do I resolve this??
> Is there some way to convert the Samba path into a conventional URL
> path ??
>
> On a slightly different tack, when I previously worked at a company
> that used bitbucket.org, the path that they used was:
> g...@bitbucket.org:company_name/project.git
>
> rather than a URL. What would I have to do differently here, to be
> able to access our repository via the latter syntax ??
Try playing with the url.<base>.insteadOf configuration variables.
(Run `git help config` and search for "insteadOf".)
Supposedly something like
[url "/run/user/1000/gvfs/smb-share:server=192.168.1.122,share=git/Svr10"]
insteadOf = "//ntws4/Git/der_libs"
in the .git/config of a repository (or right in ~/.gitconfig for that
developer -- to be "global") might work.
--
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
