Producing a User-Facing Installer

[Doug Kelly]

Hey all,

Are there any plans, or has anyone been involved in creating the user installer (basically, what is the "Git for Windows" installer today)?  I was thinking of starting with the current InnoSetup scripts and modifying them to work here, but I wanted to check if anyone else had thoughts or current progress before I go too far.  Just to give an idea of how far I've gotten, it seems like right now, documentation and Git Cheetah don't exist and won't work yet, but there's also a bit to do with regards to capturing the list of files to copy, too (I know a number of versions have changed and files have moved, so I'm not surprised). git-svn also isn't present, and I recall that's currently listed as a todo item as well.

Thanks,

Doug

[Sebastian Schuberth]

Hi Doug,

I thought we had a discussion about creating an end-user installer on
the list already but I'm unable to find it right now. Anyway, AFAIK no
one has started working on this yet. I myself did not do so mainly
because I do not yet feel mingwGitDevEnv to be mature enough to create
something to be shipped to end users. Still, I have some clear ideas
about how such an installer should work. In particular, I do not want
to use any of the copy-files.sh logic in msysgit, but package files
from where they are. Also, the files needs to be packaged and
installed in a way that the resulting environment can be upgraded
using mingw-get. Also, I really think that we should not ship Git
Cheetah at all. It's mostly unmaintained, and IMHO users who really
want an Explorer shell extension should use TortoiseGit or similar
instead.

As there now seems to be a demand for such an end user installer,
maybe I can prototype something i the next two weeks that others can
build upon.

--
Sebastian Schuberth

> --
> You received this message because you are subscribed to the Google Groups
> "mingwGitDevEnv" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mingwgitdeven...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Thomas Braun]

Am 23.06.2014 21:46, schrieb Sebastian Schuberth:
> Hi Doug,
>
> I thought we had a discussion about creating an end-user installer on
> the list already but I'm unable to find it right now. Anyway, AFAIK no
> one has started working on this yet. I myself did not do so mainly
> because I do not yet feel mingwGitDevEnv to be mature enough to create
> something to be shipped to end users. Still, I have some clear ideas
> about how such an installer should work. In particular, I do not want
> to use any of the copy-files.sh logic in msysgit, but package files
> from where they are. Also, the files needs to be packaged and
> installed in a way that the resulting environment can be upgraded
> using mingw-get. Also, I really think that we should not ship Git
> Cheetah at all. It's mostly unmaintained, and IMHO users who really
> want an Explorer shell extension should use TortoiseGit or similar
> instead.
>
> As there now seems to be a demand for such an end user installer,
> maybe I can prototype something i the next two weeks that others can
> build upon.
>

I second the thought about git cheetah.
I think we should also have a GfW-installer which does not require a
internet connection. This can be easily done by copying the relevant
mingw packages to \mingw\var\cache\mingw-get\packages before calling
mingw-get. This approach also has the additional benefit that the mingw
people can not so interfere with our end user installer by just
upgrading a package or two.

@Doug: A starting point for subversion might be
https://github.com/t-b/mingwGitDevEnv-packages/tree/msys-subversion-and-deps.
From my POV we could also drop the subversion support for the first
release and look how many people still need that bridge.

The documentation will be built from scratch, see
https://github.com/sschuberth/mingwGitDevEnv-packages/pull/5.

[Sebastian Schuberth]

On Mon, Jun 23, 2014 at 10:02 PM, Doug Kelly <doug...@gmail.com> wrote:

> potential in mingwGitDevEnv -- it's very friendly to update and maintain.

That was exactly the purpose why I had started the project. I was
simply tired of the "msysgit has outdated grep / tail / whatever" type
of feature requests ;-)

> With the pending patches, it also passes more of the regression test suite
> than Git for Windows has previously -- which certainly excites me!

BTW, thanks for you PRs, I'll try to find the time to look at them soon.

> So, using mgwport to contain the build steps? As far as I can tell, mgwport
> doesn't contain dependency logic, as nice as that would be... :(

Hmm, I'm not sure how mgwport comes into the picture here, but yes, it
has dependency management. At the example of msys-openssh, the mgwport
build script is at [1] and it's dependencies are listed in [2].

> Hm, that's an interesting point regarding mingw-get. Now I think I see what
> you mean: you can specify a base set of packages to install and basically
> recycle the current mingwGitDevEnv installer for end-users -- you just don't
> select the "development" packages. As a side note, we actually use a

Exactly. The packages in mingwGitDevEnv are just a super-set of what
the user will get. And whereas the mingwGitDevEnv installer downloads
all packages in their current version at installation time, the GfW
installer should just package the non-development packages that are
already there.

> slightly-modified Git for Windows installer internally, and I could see
> advantages even if we used completely unmodified installers, we wouldn't
> want to expose users to the bleeding edge unexpectedly (not to mention, we
> have some interesting proxy restrictions). A small "net installer" that can

Absolutely agree.

> fetch via mingw-get would be fine for many users, but I could also see
> advantages to a "fat installer" that contains a snapshot of the packages at
> a point in time, for testing and archival purposes. Not to mention, such a

As the current msysgit-based GfW installer is a "fat" installer too
(in the sense that it does not download anything at install time) I
think we should go for a "fat" installer, too.

> tool would be handy for using a flash drive without any network connection
> or unattended network installs.

An Inno Setup installer can be quite easily made to behave like a
self-extracting archive via the "Uninstallable" option, see [3].
That's handy for portable installations.

> Certainly no rush from my end, so please don't feel pressured. At the same
> time, I would enjoy seeing this project continue to grow and thrive (and I
> hope you would, too), and I would like to believe this is a good step!

I'd love to spend more time working on mingwGitDevEnv, but
unfortunately by day job doe snot currently permit me to do so :-/

[1] https://github.com/sschuberth/mingwGitDevEnv-packages/blob/master/msys-openssh/openssh-6.6p1-1.msysport
[2] https://github.com/sschuberth/mingwGitDevEnv-packages/blob/master/msys-openssh.xml.lzma
[3] https://github.com/sschuberth/mingwGitDevEnv/blob/master/installer/installer.iss#L48

--
Sebastian Schuberth