Building git on Windows and using it without MSYS.
James Russell Moore
Right now I've checked out the latest versions of msysgit, the msvcgit environment and git for Windows. Using them I've built some git executables using both GCC 4.4.0 (4.5.0 won't build it) and VS 2008 SP1.
With GCC I've been able to build 119 executable files, with MSVC 118 (test-parse-options was not built). The 118 executable files built with VS were built using "make MSVC=1", if I chose to build it using the perl created VC project files only 26 executables are built and they don't work properly (for example, a "git init" would give "error: could not commit config file D:/Test/.git/config" kind of errors).
Now I would like to know some things:
1. What are the dependencies of the generated git files? I mean, I know GCC ones need libiconv2.dll (I've already built it) but are any other libs required to use them? And for the MSVC ones?
2. Related to the first one, what extra files would be needed for git to work? For example, if you call a "git init" you'll see a message telling that the templates are needed. Is there anything else?
3. Is there any way to build the rebase command? I need that command...
I would like to have a "full" set of working git executables I could use from a Windows cmd, I wouldn't like to have the complete MSYS set.
Thank you very much for your time, best regards,
J. Russell Moore.
Johannes Sixt
> 1. What are the dependencies of the generated git files? I mean, I know GCC
> ones need libiconv2.dll (I've already built it) but are any other libs
> required to use them? And for the MSVC ones?
>
> 2. Related to the first one, what extra files would be needed for git to
> work? For example, if you call a "git init" you'll see a message telling
> that the templates are needed. Is there anything else?
Run 'make install' from your build that used GCC. Everything that ended up in
$prefix is needed.
> 3. Is there any way to build the *rebase *command? I need that command...
No. git-rebase is a shell script. It requires bash, sed, and probably a lot of
other executables from the MSYS environment. Note that there are other shell
scripts. The hooks hooks shipped with git are also shell scripts (but they
are not enabled by default).
> I would like to have a "full" set of working git executables I could use
> from a Windows cmd, I wouldn't like to have the complete MSYS set.
What do you mean by "a complete MSYS"? The shell scripts do need a number of
executables (and scripts) from MSYS's bin directory. But I don't think that
they need any more files in turn (except for some DLLs, of course). It should
be possible to copy them into $prefix/bin, and then you "only" have a few
more executables, but not a "complete" MSYS.
-- Hannes
Marius Storm-Olsen
> Hi, I'm trying to build git and produce a full build (or at least
> what is considered a full build in Windows) but I don't want to
> have the whole MSYS environment present in order to use git.
Right, but you won't be able to not have *anything* of MSYS, since Git
still consists of plenty of Bash scripts required for its operation.
Not until all the scripts have been rewritten in C can we think about
avoiding MSys all together. I don't see that happening anytime soon.
> Right now I've checked out the latest versions of msysgit, the
> msvcgit environment and git for Windows. Using them I've built some
> git executables using both GCC 4.4.0 (4.5.0 won't build it) and VS
> 2008 SP1.
>
> With GCC I've been able to build 119 executable files, with MSVC
> 118 (test-parse-options was not built). The 118 executable files
> built with VS were built using "make MSVC=1", if I chose to build
> it using the perl created VC project files only 26 executables are
> built and they don't work properly (for example, a "git init" would
> give "error: could not commit config file D:/Test/.git/config" kind
> of errors).
The perl generated VC project only deals with the actual binaries,
which also the Makefile creates. However, the Makefile also create a
ton of 'symlinked' executables, which are identical, to support the
legacy git-<cmd> commands (These days you should be using 'git <cmd>'
instead.
Personally I don't really use the VC projects, but contributes the
generator for those that need it. However, I've never seen the issue
you refer to when I quickly tested it. They should be compiled with
the same parameters, so I'm not quite sure why they are handling
things differently. Might be a small-ish change needed to the VC
generator. If you could dig a bit deeper on this one, it would be great!
> Now I would like to know some things:
>
> 1. What are the dependencies of the generated git files? I mean, I
> know GCC ones need libiconv2.dll (I've already built it) but are
> any other libs required to use them? And for the MSVC ones?
The best is to use the dependency walker on the executables to figure
out what files they require to execute.
http://www.dependencywalker.com/
> 2. Related to the first one, what extra files would be needed for
> git to work? For example, if you call a "git init" you'll see a
> message telling that the templates are needed. Is there anything
> else?
>
> 3. Is there any way to build the /rebase /command? I need that
> command...
It's a script, not an executable; hence my point at the top
> I would like to have a "full" set of working git executables I
> could use from a Windows cmd, I wouldn't like to have the complete
> MSYS set.
Well, get crackin' on rewriting those scripts you want into fully
replacable C commands instead then :-)
--
.marius
Traumflug
application. The limited set of needed features can all be done with
the "git" executable it's self. git-gui, gitk, documentation, etc. is
obsolete.
On Mac OS X and on Windows XP with msysgit installed everything works
fine. My goal is, however, to _not_ require installation of msysgit.
Without msysgit on XP I get files marked as "changed" which in fact
were committed just before on one of the other systems (repo tar'd and
moved from there). Commits of these files, or of new files, appear to
be a no-op.
The new "portable" distribution points into the right direction, but
coming in at 160 MB it's way to heavy. So I have two questions:
- Is there a build script to build the portable distro? I'd like to
hack it to include only what's actually needed for CLI Git.
- Is there a way to find out which CLI tools Git want's to use? DLL
dependencies are easily found by just launching the executable.
Obviously, Git want's more.
Thanks,
Markus
Marius Storm-Olsen
> Chiming in here, I'd like to embed command-line git into another
> application. The limited set of needed features can all be done
> with the "git" executable it's self. git-gui, gitk, documentation,
> etc. is obsolete.
>
> On Mac OS X and on Windows XP with msysgit installed everything
> works fine. My goal is, however, to _not_ require installation of
> msysgit. Without msysgit on XP I get files marked as "changed"
> which in fact were committed just before on one of the other
> systems (repo tar'd and moved from there). Commits of these files,
> or of new files, appear to be a no-op.
This is probably core.autocrlf = true in action, which *you* might
require to be = false, since your repo is messed up. CRLF EOLs
committed to the repo, when they probably should be just LF EOLs, or
at least the files should be marked as crlf in the attributes file
inside the repo.
> The new "portable" distribution points into the right direction,
> but coming in at 160 MB it's way to heavy. So I have two questions:
Remove all the git-* commands, which you shouldn't need, then what is
the size you're left with?
> - Is there a build script to build the portable distro? I'd like to
> hack it to include only what's actually needed for CLI Git.
This leads me to believe that *you* didn't even look into the repos to
see if you could find it *yourself*. Though, I'll be nice and point
you to
http://repo.or.cz/w/msysgit.git?a=tree;f=share/WinGit;h=fdc3f2c6c547bde08de46343b181bbe7908433eb;hb=devel
> - Is there a way to find out which CLI tools Git want's to use? DLL
> dependencies are easily found by just launching the executable.
> Obviously, Git want's more.
This requires some tinkering and testing on your part. There are
scripts. Look at them, and see what they use. There are autotests. Run
them and see where your setup breaks. Skip the tests which tests parts
you're not interested in.
--
.marius
Markus Hitter
Am 12.10.2009 um 13:11 schrieb Marius Storm-Olsen:
> This is probably core.autocrlf = true in action, which *you* might
> require to be = false, since your repo is messed up.
May I bow in front of the genius? Actually, core.filemode needed a
false, but once in the right direction, everything is easy ...
> Remove all the git-* commands, which you shouldn't need, then what
> is the size you're left with?
Yes, there's plenty of room for shrinking. Dozens of duplicates of
git.exe just for allowing "git-add" instead of "git add", each
weighting in at almost one megabyte.
> This leads me to believe that *you* didn't even look into the repos
> [...]
Well, I waded more than a day through all the various incarnations of
"git for Windows" (git#, jgit, git for mingw, git with busybox, ...),
so please bear with me.
I've got the script now, thanks.
Traumflug
needed functionality is pretty limited and can be done by calling the
git executable it's self. git-gui, gitk, documentation, patch-to-mail
handling, etc. is obsolete. Using libraries directly is prohibited by
the GPL, though.
On Windows XP with msysgit installed and on Mac OS X everything works
just fine. On plain XP however, some files get marked as "changed"
which in fact aren't. Commiting these, or commiting new files appears
to be a no-op. For testing, I tar'd and copied a repo from one of the
other systems.
Likely, the new "portable" distribution goes into the right direction
already. Weighting in at 160 MB is a bit heavy, though.
Summing up, I have two questions:
- Is a script to build the portable distro available somewhere? I'd
like to hack it to include only what's actually needed.
- Is there a way to find out which shell stuff git looks for? DLL
dependencies are trivially found by just launching the executable. But
which else is git looking for, leading to the the different behaviour
with or without msysgit installed?
Thanks,
Markus