emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: Re: PROPOSAL: Move to git, now that bzr is no longer a req.
Date: Fri, 03 Jan 2014 17:55:38 +0200

> From: Óscar Fuentes <address@hidden>
> Date: Fri, 03 Jan 2014 16:32:46 +0100
> 
> Eli Zaretskii <address@hidden> writes:
> 
> >> git.cmd can be used from the command line.
> >
> > Did you actually try that, for real?  git.cmd sets PATH to include
> > git's binaries, which include MSYS DLL.  This means you cannot use in
> > the same session any commands that might conflict.  E.g., consider
> > what would happen if you invoke git.cmd from a Makefile, or the other
> > way around.  I tried that, and got stuck and crashing programs.  No,
> > thanks.
> 
> git.cmd is not meant to permanently set any variable. It is invoked from
> a shell as
> 
> `git <args>'
> 
> 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?

> 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.

> >> > No, but some git commands need Bash and shell scripts, and thus invoke
> >> > MSYS programs that do need the MSYS DLL.
> >> 
> >> You don't need MSYS on the PATH, so whatever those commands use is an
> >> interal implementation detail.
> >
> > No, it isn't.  When MSYS DLL is loaded, any other program that is
> > linked to that DLL will try to use it -- and will fail if it needs an
> > incompatible version of that DLL.  Therefore, you can't invoke, say,
> > the MSYS 'make' from the Git Bash shell, or from any Git command.
> 
> 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

You _can_ have different DLLs with the same functionality, but they
must have different names, as in libpng13.dll and libpng16.dll, and
each executable should specify the name it wants in its import table.

When you install both msysgit and MSYS that uses a different MSYS DLL,
you have a small DLL hell on your hands.  That's why I keep them
separate: to avoid that.

> A different history is if you invoke an MSYS (or Cygwin) executable
> from MSYSGit, or vice-versa, but that is an improbable scenario
> (please keep in mind that git.exe is not a MSYS binary, so invoking
> it from Cygwin/MSYS shouldn't be problematic, at least for the usual
> git commands.)

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]