New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding rsync to installer #131

Closed
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
7 participants
@ShadowLNC

ShadowLNC commented Feb 14, 2017

Solves #347 (closed), uses the same method as pull #57.

Rationale: I am looking to make backups using rsync, and would like to include it in Git Bash, rather than install other software such as Cygwin. Per #347 there is demand for it. As listed below, the file size increase is negligible (<0.4%).

64-bit compiled version sizes (via wc -c):

Size (Bytes) Build Size (Megabytes)
43508495 Standard 43.51
43678759 With rsync 43.68

Installing rsync via pacman was a 0.25MiB download and 0.46MiB installed, so the 0.17MB difference in the installer checks out.

Adding rsync to installer
This uses the same method as pull #57 and solves the (closed) #347.

Rationale: I am looking to make backups using rsync, and would like to include it in Git Bash, rather than install other software such as Cygwin. Per #347 there is demand for it. As listed below, the file size increase is negligible (<0.4%).

64-bit compiled version sizes (via `wc -c`):

43508495 Standard (43.51MB)
43678759 With rsync (43.68MB)

Installing rsync via pacman was a 0.25MiB download and 0.46MiB installed, so the 0.17MB difference in the installer checks out.

Signed-off-by: Scott Stevens <go.scott.mac@gmail.com>
@nalla

This comment has been minimized.

Show comment
Hide comment
@nalla

nalla Feb 14, 2017

Member

rsync is not required to get git up and running. Out of curiosity, what's stopping you from using the SDK?

Member

nalla commented Feb 14, 2017

rsync is not required to get git up and running. Out of curiosity, what's stopping you from using the SDK?

@dscho

This comment has been minimized.

Show comment
Hide comment
@dscho

dscho Feb 20, 2017

Member

I am really reluctant to add programs to Git for Windows when the intention is specifically not to use the for any Git operation.

We have enough maintenance burden in this project supporting Git already, it would do Git for Windows users a disservice to spread the available resources even thinner by trying to support anything else in addition...

I am sympathetic to the situation, though. And I think @nalla's suggestion makes tons of sense: why not use the SDK? And if that does not work, use the SDK to generate custom installers (including rsync)...

Member

dscho commented Feb 20, 2017

I am really reluctant to add programs to Git for Windows when the intention is specifically not to use the for any Git operation.

We have enough maintenance burden in this project supporting Git already, it would do Git for Windows users a disservice to spread the available resources even thinner by trying to support anything else in addition...

I am sympathetic to the situation, though. And I think @nalla's suggestion makes tons of sense: why not use the SDK? And if that does not work, use the SDK to generate custom installers (including rsync)...

@larsxschneider

This comment has been minimized.

Show comment
Hide comment
@larsxschneider

larsxschneider Feb 25, 2017

Contributor

@dscho I totally understand your maintenance burden argument. However, I found myself in the same situation as @ShadowLNC . A custom Git for Windows installer is an option but it needs to be updated with every new GfW release and my user don't trust custom installers.

Idea

What if we create an installer that adds "pacman" to a regular Git for Windows installation. After pacman is installed, people can install whatever they want (e.g. rsync). We would make it very clear that you are not the maintainer of this "add-on" installer. Do you think that could work? Would you generally endorse such an "add-on" installer (e.g. could it live under "github.com/git-for-windows")?

Contributor

larsxschneider commented Feb 25, 2017

@dscho I totally understand your maintenance burden argument. However, I found myself in the same situation as @ShadowLNC . A custom Git for Windows installer is an option but it needs to be updated with every new GfW release and my user don't trust custom installers.

Idea

What if we create an installer that adds "pacman" to a regular Git for Windows installation. After pacman is installed, people can install whatever they want (e.g. rsync). We would make it very clear that you are not the maintainer of this "add-on" installer. Do you think that could work? Would you generally endorse such an "add-on" installer (e.g. could it live under "github.com/git-for-windows")?

@nalla

This comment has been minimized.

Show comment
Hide comment
@nalla

nalla Feb 26, 2017

Member

@larsxschneider Including pacman into the end-user installer is not an option. That opens way to much problems. E.g. users would uninstall stuff that is required and such.

But shipping pacman is essential the same thing as using the SDK. So just use it :-)

Member

nalla commented Feb 26, 2017

@larsxschneider Including pacman into the end-user installer is not an option. That opens way to much problems. E.g. users would uninstall stuff that is required and such.

But shipping pacman is essential the same thing as using the SDK. So just use it :-)

@larsxschneider

This comment has been minimized.

Show comment
Hide comment
@larsxschneider

larsxschneider Feb 26, 2017

Contributor

@nalla "uninstall stuff" is a good argument. I haven't considered that!

However, I think I expressed myself not good enough: I don't want to suggest to include pacman into the end-user installer. That would clearly be out of scope for GfW and it would increase the maintenance burdon for @dscho as discussed above.

I am contemplating if it makes sense to create a new, completely separate, installer that finds your GfW installation and just adds pacman. This enables people like @ShadowLNC and myself to easily install tiny tools like rsync and such without the overhead of the SDK. AFAIK the SDK will always download the entire toolchain and it will always build GfW from scratch (please correct me if I am wrong here).

Contributor

larsxschneider commented Feb 26, 2017

@nalla "uninstall stuff" is a good argument. I haven't considered that!

However, I think I expressed myself not good enough: I don't want to suggest to include pacman into the end-user installer. That would clearly be out of scope for GfW and it would increase the maintenance burdon for @dscho as discussed above.

I am contemplating if it makes sense to create a new, completely separate, installer that finds your GfW installation and just adds pacman. This enables people like @ShadowLNC and myself to easily install tiny tools like rsync and such without the overhead of the SDK. AFAIK the SDK will always download the entire toolchain and it will always build GfW from scratch (please correct me if I am wrong here).

@fourpastmidnight

This comment has been minimized.

Show comment
Hide comment
@fourpastmidnight

fourpastmidnight Feb 26, 2017

Contributor

It is a rule that an installer for "another product" cannot modify some other product. Violating this rule as you suggest would make upgrading and removing the original product impossible, essentially breaking those installations of Git for Windows for users who use your suggested "installer".

Furthermore, your suggestion is akin to downloading the GfW SDK which gives you precisely this ability as @nalla already pointed out.

Now that I think about it, I myself proposed something very similar and have an open PR here; but after my vey own comments, and @nalla's above, I'm going to go close that PR---it's just not a good idea. If you want more than what GfW offers, use the SDK---or use MingW or Cygwin instead.

Contributor

fourpastmidnight commented Feb 26, 2017

It is a rule that an installer for "another product" cannot modify some other product. Violating this rule as you suggest would make upgrading and removing the original product impossible, essentially breaking those installations of Git for Windows for users who use your suggested "installer".

Furthermore, your suggestion is akin to downloading the GfW SDK which gives you precisely this ability as @nalla already pointed out.

Now that I think about it, I myself proposed something very similar and have an open PR here; but after my vey own comments, and @nalla's above, I'm going to go close that PR---it's just not a good idea. If you want more than what GfW offers, use the SDK---or use MingW or Cygwin instead.

@dscho

This comment has been minimized.

Show comment
Hide comment
@dscho

dscho Feb 26, 2017

Member

As I said, I am really reluctant to include even more stuff that is not required for Git to run (in the past, a couple of then-active developers needed things like unzip.exe, so we included that, but it only increased my maintenance burden, and it would take a really active contributor these days to merit that kind of favor).

And pacman.exe would fall squarely into that category.

Please note also that the Git for Windows installer makes a point of not including the complete Pacman packages' contents, making it harder to re-initialize a pseudo SDK (the entire point of the SDK is to bootstrap a Pacman setup, with devel packages).

If you absolutely want to, you could contribute a PR to enhance the SDK installer to not install the devel packages. But that kind of goes contrary to the purpose of the SDK...

Member

dscho commented Feb 26, 2017

As I said, I am really reluctant to include even more stuff that is not required for Git to run (in the past, a couple of then-active developers needed things like unzip.exe, so we included that, but it only increased my maintenance burden, and it would take a really active contributor these days to merit that kind of favor).

And pacman.exe would fall squarely into that category.

Please note also that the Git for Windows installer makes a point of not including the complete Pacman packages' contents, making it harder to re-initialize a pseudo SDK (the entire point of the SDK is to bootstrap a Pacman setup, with devel packages).

If you absolutely want to, you could contribute a PR to enhance the SDK installer to not install the devel packages. But that kind of goes contrary to the purpose of the SDK...

@kubark42

This comment has been minimized.

Show comment
Hide comment
@kubark42

kubark42 Apr 3, 2017

I understand the rationale for closing this, but is there a simple way to run this snippet of code and get just rsync? Thoughts, @ShadowLNC?

kubark42 commented Apr 3, 2017

I understand the rationale for closing this, but is there a simple way to run this snippet of code and get just rsync? Thoughts, @ShadowLNC?

@dscho

This comment has been minimized.

Show comment
Hide comment
@dscho

dscho Apr 3, 2017

Member

@kubark42 you can always fudge things by copying rsync.exe directly out of a Git for Windows SDK (which is now easier because I adjusted my Continuous Testing to mirror its formerly-internal Git repositories that track the SDKs here and here. And you can always build your own custom installers.

If you decide that you want to stay with the vanilla Git for Windows releases, though, I am afraid that adding rsync.exe (and all the other things occasionally asked for, but unnecessary for Git to work) would simply add too much maintenance burden.

Member

dscho commented Apr 3, 2017

@kubark42 you can always fudge things by copying rsync.exe directly out of a Git for Windows SDK (which is now easier because I adjusted my Continuous Testing to mirror its formerly-internal Git repositories that track the SDKs here and here. And you can always build your own custom installers.

If you decide that you want to stay with the vanilla Git for Windows releases, though, I am afraid that adding rsync.exe (and all the other things occasionally asked for, but unnecessary for Git to work) would simply add too much maintenance burden.

@kubark42

This comment has been minimized.

Show comment
Hide comment
@kubark42

kubark42 Apr 3, 2017

I looked in those git repos, it's not immediately obvious where I can grab the rsync binary. I've prowled around inside every directory that's called bin, but didn't see it. Should I be doing this differently, e.g. installing the entire SDK and then grabbing the binary after it comes in?

If you decide that you want to stay with the vanilla Git for Windows releases, though, I am afraid that adding rsync.exe (and all the other things occasionally asked for, but unnecessary for Git to work) would simply add too much maintenance burden.

Wholeheartedly agree. I'm using Git for Windows like many people, as a great way to get working Unix CLI tools, and not necessarily use Git on Windows (although I do that as well.) It's awesome that it works so well for these side needs, but it's massively out of scope so no support is expected.

kubark42 commented Apr 3, 2017

I looked in those git repos, it's not immediately obvious where I can grab the rsync binary. I've prowled around inside every directory that's called bin, but didn't see it. Should I be doing this differently, e.g. installing the entire SDK and then grabbing the binary after it comes in?

If you decide that you want to stay with the vanilla Git for Windows releases, though, I am afraid that adding rsync.exe (and all the other things occasionally asked for, but unnecessary for Git to work) would simply add too much maintenance burden.

Wholeheartedly agree. I'm using Git for Windows like many people, as a great way to get working Unix CLI tools, and not necessarily use Git on Windows (although I do that as well.) It's awesome that it works so well for these side needs, but it's massively out of scope so no support is expected.

@dscho

This comment has been minimized.

Show comment
Hide comment
@dscho

dscho Apr 4, 2017

Member

I've prowled around inside every directory that's called bin, but didn't see it.

Hitting t followed by typing rsync.exe would have sped that up...

And you're absolutely correct, it is not in there. I forgot that Git does not need rsync, and therefore the SDK does not install this package.

However, what you can do very easily is to clone the repository (a shallow clone should do just fine) and then call git-bash.exe in its top-level directory followed by pacman -Syy rsync to install usr\bin\rsync.exe. And then you have it. And you also have the SDK. And a current git.exe in the PATH.

Member

dscho commented Apr 4, 2017

I've prowled around inside every directory that's called bin, but didn't see it.

Hitting t followed by typing rsync.exe would have sped that up...

And you're absolutely correct, it is not in there. I forgot that Git does not need rsync, and therefore the SDK does not install this package.

However, what you can do very easily is to clone the repository (a shallow clone should do just fine) and then call git-bash.exe in its top-level directory followed by pacman -Syy rsync to install usr\bin\rsync.exe. And then you have it. And you also have the SDK. And a current git.exe in the PATH.

@kubark42

This comment has been minimized.

Show comment
Hide comment
@kubark42

kubark42 Apr 4, 2017

Hitting t followed by typing rsync.exe would have sped that up...

Nice tip. I had tried search field, but hadn't realized t was a hotkey.

Thanks for the detailed instructions, that's very simple and can be run in a portable format, i.e. it avoids an installation procedure.

kubark42 commented Apr 4, 2017

Hitting t followed by typing rsync.exe would have sped that up...

Nice tip. I had tried search field, but hadn't realized t was a hotkey.

Thanks for the detailed instructions, that's very simple and can be run in a portable format, i.e. it avoids an installation procedure.

@ShadowLNC

This comment has been minimized.

Show comment
Hide comment
@ShadowLNC

ShadowLNC Jun 6, 2017

I agree that the SDK is the preferred option and I am likely to migrate to that next time I update Git for Windows on my primary machine (currently running off a custom installer).

However, this is not always viable on computers with limited disk space, or portable versions running off older USBs:

Product Size
SDK (with rsync) >6GB
Self-Compiled Installation >2GB
2.11.1 Installation ~200MB

To further my rationale, here's what happens when you install Git on Debian:

~$ sudo apt-get --dry-run install git
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
  git-man libcurl3-gnutls liberror-perl rsync
Suggested packages:
  git-daemon-run git-daemon-sysvinit git-doc git-el git-email git-gui gitk gitweb git-arch git-cvs git-mediawiki git-svn
The following NEW packages will be installed:
  git git-man libcurl3-gnutls liberror-perl rsync
0 upgraded, 5 newly installed, 0 to remove and 0 not upgraded.

As you can see, rsync is installed when you install git.

On the topic of uncluttering Git for Windows, I believe that tools like dd (which admittedly I use) are not relevant to source control and I would suggest that there is some pruning that can be done in that regard.

Either way, thanks for making a product which has become integral to my work (Git Bash has replaced CMD for me) 😄

ShadowLNC commented Jun 6, 2017

I agree that the SDK is the preferred option and I am likely to migrate to that next time I update Git for Windows on my primary machine (currently running off a custom installer).

However, this is not always viable on computers with limited disk space, or portable versions running off older USBs:

Product Size
SDK (with rsync) >6GB
Self-Compiled Installation >2GB
2.11.1 Installation ~200MB

To further my rationale, here's what happens when you install Git on Debian:

~$ sudo apt-get --dry-run install git
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
  git-man libcurl3-gnutls liberror-perl rsync
Suggested packages:
  git-daemon-run git-daemon-sysvinit git-doc git-el git-email git-gui gitk gitweb git-arch git-cvs git-mediawiki git-svn
The following NEW packages will be installed:
  git git-man libcurl3-gnutls liberror-perl rsync
0 upgraded, 5 newly installed, 0 to remove and 0 not upgraded.

As you can see, rsync is installed when you install git.

On the topic of uncluttering Git for Windows, I believe that tools like dd (which admittedly I use) are not relevant to source control and I would suggest that there is some pruning that can be done in that regard.

Either way, thanks for making a product which has become integral to my work (Git Bash has replaced CMD for me) 😄

@dscho

This comment has been minimized.

Show comment
Hide comment
@dscho

dscho Jun 6, 2017

Member

when you install Git on Debian:

[,..]

As you can see, rsync is installed when you install git.

Git used to support an rsync:// protocol for fetching/pushing. This support has been removed with Git v2.8.0.

Meaning that you either installed Git <v2.8.0, or that the Debian Git maintainers have not yet noticed that they install a stale dependency.

In any case, this ticket is not about a Git for Windows bug. It is purely for your pleasure, and the pleasure of your users who happen to require both Git and RSync.

You can easily make your custom Git installer to make it easy for your users. It does not require a lot more space on their machines, just on yours, where you build your custom installer.

Now, I would really like to suggest that we put this ticket to rest, as it does distract me from maintaining Git for Windows itself.

Member

dscho commented Jun 6, 2017

when you install Git on Debian:

[,..]

As you can see, rsync is installed when you install git.

Git used to support an rsync:// protocol for fetching/pushing. This support has been removed with Git v2.8.0.

Meaning that you either installed Git <v2.8.0, or that the Debian Git maintainers have not yet noticed that they install a stale dependency.

In any case, this ticket is not about a Git for Windows bug. It is purely for your pleasure, and the pleasure of your users who happen to require both Git and RSync.

You can easily make your custom Git installer to make it easy for your users. It does not require a lot more space on their machines, just on yours, where you build your custom installer.

Now, I would really like to suggest that we put this ticket to rest, as it does distract me from maintaining Git for Windows itself.

@dlong500

This comment has been minimized.

Show comment
Hide comment
@dlong500

dlong500 Sep 7, 2017

@kubark42 I found the rsync package directly in the MSYS2 package repository. Not sure if that's a newly available repo, but it's there at the moment. I also just wrote a post about manually adding rsync in an old feature request issue.

dlong500 commented Sep 7, 2017

@kubark42 I found the rsync package directly in the MSYS2 package repository. Not sure if that's a newly available repo, but it's there at the moment. I also just wrote a post about manually adding rsync in an old feature request issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment