Re: Most git executables are hard links to git.exe?

[Larry <cygwin@verizon.net>]

On 7/21/23 17: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?

If you're wondering what the limitations and complications of symbolic links
on Windows are, I'd recommend reading item 5.8 in the FAQ - "How do symbolic
links work?" (https://cygwin.com/faq.html#faq.api.symlinks)  Keep in
mind that this applies to symbolic links in the Cygwin world.  As long as
that's all you care about, then the various trade-offs and limitations can
certainly be mitigated in your personal environment to the extent that you
might actually prefer and choose to use Cygwin symbolic links over hard
links for your needs.  But in the general case, they really don't compare to
simplicity of hard links which are fully supported in Windows on NTFS file
systems along with all Cygwin tools and transparently degrade to duplicated
files on file systems and with software that doesn't support them.  In these
degraded use cases, they take up more space because the link semantics
aren't maintained but they are still 100% valid and useful.  The same cannot 
be said of symbolic links.