Remove command-line Git from Windows and Mac binaries

[tkelman]

It's taking up space (~50% of the size in the windows binaries), and packages should transition to using libgit2 functionality now that it's available in 0.5. Mainly blocked on JuliaPackaging/Homebrew.jl#95, needs to be finished before 0.5.0.

edit: I should also put busybox back for Windows, except in no-GPL builds, along with maybe some spawn rewriting to use it for coreutils type commands.

[tkelman]

If we absolutely need a pure-Julia way of ensuring command line git is present then we could move it to a package that manages downloading and calling git, instead of entirely switching to libgit2-based solutions for everything.

[StefanKarpinski]

I really don't get the motivation for removing command-line git. Why do we care about this? Download size seems like an incredibly thin reason for something that's really useful to have around.

[tkelman]

Julia is a programming language, not a git delivery mechanism. We're not using it for Pkg any more, it isn't mandatory for anything - until someone needs to do an interactive rebase, but that's a dev concern not a mandatory thing that every user has to do.

Since pieces of Git are implemented in shell, perl, and tcl/tk it has to lug around an entire posix system from cygwin/msys2 to work on windows. It's a mess. Small Base, #5155.

make and gfortran are also really useful to have around, and we don't bundle those.

[StefanKarpinski]

Ok, ok. Carry on.

[amellnik]

Re transitioning to libgit2: is there still a way to specify http and https proxies, and to use https:// over git:// ? Right now those of us behind corporate proxies need to do this through the command-line Git.

[tkelman]

#11312

[KristofferC]

I was going to whine that the package manager is still so slow in Windows but then I realized I am downloading DOOM at 11.5 MB/s from Steam... Just posting to show my stupidness.

[tkelman]

The package manager on nightlies is using libgit2 everywhere. I'm going to put command-line git into a package in case anyone still wants to use it. Master of Homebrew.jl could use some testing on osx though, I think it's not entirely working yet.

[tkelman]

Looks like I'll need ssh access to a mac if no one else can look at the issues on master of Homebrew.jl so we can get that tagged. @andreasnoack is the unused mac mini turned on and connected to the internet? While we decide what to do with it permanently, I could use it here.

[vtjnash]

What's the status of this? I heard recently that Homebrew.jl was upgraded recently, so what help does this require now to make happen?

[tkelman]

I'm on it, my personal to-do list is basically:

1. filter the history of the Git module from base to preserve authorship (done)
2. move it to a package that will also handle the installation of command-line git if not present
   • portable git on windows
   • have homebrew.jl (will need to be declared ready to tag post-rewrite done) do it on mac when command-line tools aren't present
   • probably use conda's binaries as a non-root option on linux
   • register it
3. disable (on windows) or put in place a workaround for the spawn and similar tests that assume coreutils are present, maybe using busybox-w32 again when the gpl-allowed flag is set
4. delete the julia code and makefiles here (RFC: Remove command-line Git from Mac and Windows binaries #17294)

[tkelman]

Anybody want to bikeshed on what the package should be called? Git.jl is the obvious choice. Maybe GitCmd.jl or something similarly a tiny bit more descriptive could also be appropriate.

[StefanKarpinski]

Is this really release-blocking? Can we get this done, please?

[tkelman]

Would rather not release .0 with it in and .1 without it, so yes. See the PR, making progress.