You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@ferventcoder I would like to ask for your help here. As you maintain the NuGet packages, and as we are considering getting away from mingw-get, would you please detail what we would need to do in order to switch to chocolatey/NuGet?
@ferventcoder primarily for the end user (but remember, we need a shell and Perl with Subversion bindings, so we probably need to ship a minimal MSys).
As for msysGit: we are switching to the SDK (have a look at the org in which this ticket lives).
@dscho As an aside - I personally love all of the tools provided in the bin folder with Git for Windows.
For the end user on Chocolatey's end, right now the state of the world is that there is a handoff - the installer is created (by your team) and the Chocolatey package (git.install) knows how to download the installer and install/upgrade Git silently. From my perspective, that is it. If there was/is a way to use mingw-get from within git, I've never used it (or at least realized I was using if it is used by git under the covers).
There is also the portable version, which the Chocolatey package (git.commandline) knows how to download and put on the PATH.
choco install git has a dependency on git.install, so things just get installed.
Are these the details you are looking for or more of an internal switch?
Well, the discussion revolves around the problem that Git users currently need to use a full-blown installer to upgrade Git to a new version, and if they only need, say, an upgrade of bash, they still need a complete new version of the Git installer that only upgrades the bash. So we're looking for ways to make this more efficient, in particular from a maintenance and contribution point of view.
I think for that, you can start to split things out and depend on git subpackages, that way you can update those out of band. Like git-bash or maybe just bash - I'm not sure if there is a package out there at the moment that is just bash.
@ferventcoder okay, so basically the NuGet ecosystem does not provide the packages that we would require yet... not sure we have the manpower to conjure those packages into existence.
What I envision is a traditional route of installation, where a user can download an AIO (all in one) package (the current) and install it. And then you provide all of the subpackages that go into that AIO so each can be upgraded separately. Those would work with the current install location of git on the user system (which can be found by the registry install location).
This also allows for when the next tool has a CVE, you can be much quicker to patch just that tool.
Perhaps ultimately move away from the AIO and just provide the smaller packages, providing instructions on how to install all of them (or to use Chocolatey) - the side effect of this is that outside of Chocolatey it complicates the user experience.
@ferventcoder okay, so basically the NuGet ecosystem does not provide the packages that we would require yet... not sure we have the manpower to conjure those packages into existence.
Correct. Right now, I'm not sure if the ecosystem is at that level, yet.
Again... I was looking for a way to reduce the maintenance burden, not to increase it 😄
:) One thing to consider is that mingw-get will likely become part of what chocolatey can intuitively install from as well. All of the alternative sources (cygwin, python, gems, etc) will likely get better in the next incarnation of Chocolatey (which I'm just about to add back in the alternative sources for) so that they do a better job of installing the alternative pkg mgr, then installing packages from (which is currently user driven, not specified from packages themselves).
Then we'll likely enhance the nuspec that describes the package and the dependencies to allow for taking dependencies on these alternative sources, thus
Activity
dscho commentedon Dec 1, 2014
@ferventcoder I would like to ask for your help here. As you maintain the NuGet packages, and as we are considering getting away from mingw-get, would you please detail what we would need to do in order to switch to chocolatey/NuGet?
ferventcoder commentedon Dec 1, 2014
Hi @dscho - Is this for the consumer end of Git for Windows or mSysGit?
dscho commentedon Dec 2, 2014
@ferventcoder primarily for the end user (but remember, we need a shell and Perl with Subversion bindings, so we probably need to ship a minimal MSys).
As for msysGit: we are switching to the SDK (have a look at the org in which this ticket lives).
ferventcoder commentedon Dec 2, 2014
@dscho As an aside - I personally love all of the tools provided in the bin folder with Git for Windows.
For the end user on Chocolatey's end, right now the state of the world is that there is a handoff - the installer is created (by your team) and the Chocolatey package (git.install) knows how to download the installer and install/upgrade Git silently. From my perspective, that is it. If there was/is a way to use mingw-get from within git, I've never used it (or at least realized I was using if it is used by git under the covers).
There is also the portable version, which the Chocolatey package (git.commandline) knows how to download and put on the PATH.
choco install githas a dependency on git.install, so things just get installed.Are these the details you are looking for or more of an internal switch?
dscho commentedon Dec 2, 2014
Well, the discussion revolves around the problem that Git users currently need to use a full-blown installer to upgrade Git to a new version, and if they only need, say, an upgrade of bash, they still need a complete new version of the Git installer that only upgrades the bash. So we're looking for ways to make this more efficient, in particular from a maintenance and contribution point of view.
ferventcoder commentedon Dec 2, 2014
Ah, I see. So you are looking to use more of the Chocolatey ecosystem versus adding everything and the kitchen sink to the installer.
ferventcoder commentedon Dec 2, 2014
I think for that, you can start to split things out and depend on git subpackages, that way you can update those out of band. Like
git-bashor maybe justbash- I'm not sure if there is a package out there at the moment that is just bash.dscho commentedon Dec 2, 2014
@ferventcoder okay, so basically the NuGet ecosystem does not provide the packages that we would require yet... not sure we have the manpower to conjure those packages into existence.
ferventcoder commentedon Dec 2, 2014
What I envision is a traditional route of installation, where a user can download an AIO (all in one) package (the current) and install it. And then you provide all of the subpackages that go into that AIO so each can be upgraded separately. Those would work with the current install location of git on the user system (which can be found by the registry install location).
This also allows for when the next tool has a CVE, you can be much quicker to patch just that tool.
Perhaps ultimately move away from the AIO and just provide the smaller packages, providing instructions on how to install all of them (or to use Chocolatey) - the side effect of this is that outside of Chocolatey it complicates the user experience.
dscho commentedon Dec 2, 2014
Again... I was looking for a way to reduce the maintenance burden, not to increase it 😄
ferventcoder commentedon Dec 2, 2014
Correct. Right now, I'm not sure if the ecosystem is at that level, yet.
:) One thing to consider is that mingw-get will likely become part of what chocolatey can intuitively install from as well. All of the alternative sources (cygwin, python, gems, etc) will likely get better in the next incarnation of Chocolatey (which I'm just about to add back in the alternative sources for) so that they do a better job of installing the alternative pkg mgr, then installing packages from (which is currently user driven, not specified from packages themselves).
Then we'll likely enhance the nuspec that describes the package and the dependencies to allow for taking dependencies on these alternative sources, thus
ferventcoder commentedon Dec 2, 2014
That is probably about six months out at the moment.
dscho commentedon Dec 2, 2014
Okay. So we're stuck with
mingw-getfor the moment, although there are already signs thatmingw-get's ecosystem is dying...89 remaining items
connect: plug protocol capability leak
connect: plug protocol capability leak
builtin/gc: fix condition for whether to write commit graphs
odb: properly close sources before freeing them
Merge virtualfilesystem hook
Fix rare segfault in sparse-index (git-for-windows#690)
builtin/gc: fix condition for whether to write commit graphs
odb: properly close sources before freeing them
Merge virtualfilesystem hook
Fix rare segfault in sparse-index (#690)
reftable/table: fix NULL pointer access when seeking to bogus offsets
reftable/table: fix NULL pointer access when seeking to bogus offsets
reftable/block: fix OOB read with bogus block size
reftable/table: fix NULL pointer access when seeking to bogus offsets
builtin/history: unuse the commit buffer after use