Most git executables are hard links to git.exe?

[Adam Dinwoodie]

On Fri, 21 Jul 2023 at 22:54, Jim Garrison via Cygwin wrote:
>
> On 07/21/23 14:52, Brian Inglis wrote:
> > On 2023-07-21 14:59, Jim Garrison via Cygwin wrote:
> >> Git comes with over 100 executables, mostly in /usr/libexec/git-core,
> >> that all appear to be *hard* links to /bin/git, in both Cygwin and
> >> Windows. The Windows fsutil command shows they're all hard linked:
> [snip]
> >> I'm curious to know if there's a specific reason for this implementation
> >> that would make it the choice over symbolic links.
> >
> > For the same reason you are complaining about backups not taking
> > hardlinks into account: to avoid distributing 400MB instead of 3MB.
> >
> > Cygwin backup utilities should be able to deal with these e.g. rsync -H,
> > --hard-links, although it appears xcopy and robocopy may not under
> > Windows 10; don't know about other utilities or Windows 11.
>
> But why not use symbolic links to accomplish the same thing?

A few reasons off the top of my head:

- This is what the Git build tooling does out of the box. Minimising
the number of changes we're making as a downstream packager makes my
life easier as package maintainer.

- This is what happens on *nix systems, and Cygwin generally
prioritises matching function with *nix systems over interoperability
with Windows tools; if you want interoperability with Windows tools,
you might be better off with Git for Windows. That's not trying to
brush you off; the reason Cygwin Git and Git for Windows both exist is
that they're both serving different user needs.

- As others have said, Windows in general has good support for
hardlinks, while it has no inherent support for Cygwin's symlinks.
That means a Windows application would need to be aware of Cygwin to
have any chance of usefully interacting with those files if they were
symlinks, whereas a Windows application doesn't need to be aware of
Cygwin at all to be able to handle hardlinks, it only needs to know
how to handle hardlinks on Windows.

- Although I've not measured it, I expect there's a small runtime cost
from using symlinks over hardlinks. Cygwin's Git is already slow, for
a variety of difficult-to-solve reasons, and I'm reluctant to do
anything that might make that worse.

- Inertia. The current situation works well for most people, and
changing things takes effort and risks breaking other folks' use
cases.

I do acknowledge that while many Windows tools *could* handle
hardlinks, many don't. I'm not at all surprised that some backup
utilities don't handle them well and back up each file separately. I
think switching to using symlinks for Cygwin's executables is the
wrong solution, though.

Instead, I'd suggest (a) finding a backup tool that can handle
hardlinks, (b) finding a backup tool that uses compression so the
"duplicate" data gets deduplicated as part of the backup process, (c)
not backing up most of Cygwin's /usr directory in the first place – in
most cases I wouldn't expect there to be anything in that folder that
couldn't be readily recovered elsewhere anyway – or (d) switching to a
disk imaging backup system rather than a file-based one if it's really
important that you have everything on disk ready to restore.

Hopefully that's all useful and/or interesting, even if it's not the
answer you were hoping for!