Re: PROPOSAL: Move to git, now that bzr is no longer a req.

[Óscar Fuentes]

Eli Zaretskii <address@hidden> writes:

>> Whatever environment variables it sets are effective only until the
>> command finishes, and for that sole command.
>
> Yes, and what happens if that command then invokes something that is
> not in the git's bin directory?

How could that happen? MSYSGit is self-contained. You can set some git
configuration params for using external diff tools, for instance, but
then you should make sure that those tools are compatible with MSYSGit
(which means, essentially, that no Cygwin or MSYS binaries allowed.)

>> As previously mentioned, there is no git.cmd anymore but a git.exe that
>> knows where the other commands are located.
>
> I still have git.cmd after installing the latest msysgit, FWIW.  Not
> that I'm using it.

I'm using MSYSGit 1.8.4.msysgit.0 and int Git/cmd there is git.exe and
gitk.cmd. There is no git.cmd anywhere. Maybe they reverted that change.

>> Are you sure about this? Windows allows multiple DLLs with the same
>> names and every application will load one of them as per the effective
>> environment when the application is launched.
>
> Not if they have the same name.  An application that was linked
> against FOO.DLL will ask the OS to load the first FOO.DLL on the DLL
> search path.  If a DLL with the same base name is already in memory,
> Windows doesn't look for it, it just uses what's already in memory.
> See this page for the details:
>
>   
> http://msdn.microsoft.com/en-us/library/windows/desktop/ms682586%28v=vs.85%29.aspx

Those rules affects a given process. That means that the fact that
process `foo' loaded certain DLLs does not affect which DLLs are loaded
for process `bar', even when `bar' is executed from `foo'.

For Cygwin and MSYS processes the incompatibility doesn't come from the
DLL loading system (assuming that each executable loads the correct DLL,
as it should because they live on the same directory) but from
collisions on objects that are used or created by Cygwin/MSYS.

[snip]

> Well, I run git from Bash, so an MSYS binary is already in the air
> when I invoke any git commands.

It would be quick enough to run some common git commands from MSYS shell
to see if it works: clone, pull, status, log...

BTW, there is MSYS2 [1], that comes with lots of packages (managed with
pacman, an awesome package manager) including git. I built Emacs from
MSYS2 a few days ago and it worked (just a small compile issue related
to MinGW-w64.) MSYSGit is quite faster than MSYS2 git, though.

[1] https://sourceforge.net/projects/msys2/