From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oo1-xc29.google.com (mail-oo1-xc29.google.com [IPv6:2607:f8b0:4864:20::c29]) by sourceware.org (Postfix) with ESMTPS id 9C9043858CDA for ; Sat, 22 Jul 2023 17:33:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9C9043858CDA Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=dinwoodie.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=dinwoodie.org Received: by mail-oo1-xc29.google.com with SMTP id 006d021491bc7-5666a2b7f55so306474eaf.0 for ; Sat, 22 Jul 2023 10:33:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dinwoodie.org; s=google; t=1690047227; x=1690652027; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=MLY31MEuz8dpJBdxIjo1l4uq2SPHNyiTFwW1iZ5MQuw=; b=LYnbWCSL/i5Dam8OgOkfWHapv9UMUAM1ONB+q7wkifaCPSb8L0YC7pV3BaqUoDqq7y K+wVNAs26tp8nBhU5XZk7NpnAMwNrvP9kMujaW0cJ027kC2rlRmW8wv/w5gPjLOi0L8y 1DEpDe9FzcVzlE21DtPMbp+0KeFgtzYtmtGiYJpPJxbfd9P6W/XQPahnTqi8po/5XO+3 I5G8DlY8YH5StX6XEw+NCRFlU+AndpJ1oNzGcTtjKpEUv9pdJVmJndun7Jcltg1xLUGK e8tpmot+cfP5pKL7lHwyqrZPhL8EsXBqlLCCei80JXGXrIYYNMBD39IJTeBmY0Wx5hcM 9bJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690047227; x=1690652027; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=MLY31MEuz8dpJBdxIjo1l4uq2SPHNyiTFwW1iZ5MQuw=; b=Spfk1+fCICu7BYreW0hXYabI+WBMGklYvbzsb/iAV1iCJovjKbYCTg54nC4tsVhNuR vLo4tL1/MYfEhDnUONZ6iL9LP1/ZmpQLMine6yNgOQMATBsMsMqRfJ4+iegGJLvcBiFR v27A4YH+v6NR2IfNAF5DWoy9JASRfJpJo0MKX3g56KO1J7ZcANXmzBtGhLGubPEz+p78 5qdl691hJtsAkHuZa/zZ319RairkxHCipe9qrchcqoKa427rzjYdl6FoQWO8/aolGmcC XYuBaL6Pvy27otd0FTDZN4oFFRxoJjBU0IG3WgjPX5YwWux26J0+G2/DoHghdjyTWK6E KIJg== X-Gm-Message-State: ABy/qLYE8HhAVHp5XkXkxd6uNhdwNwpYMAPT58k50QdwKgpGcRonKUYO 8NHmADcRnVs2nzG3iU723HO5jMtBhbDSbJHGxNBYs46CTY4Yka5u X-Google-Smtp-Source: APBJJlHmRSAXd801mUgTuooGd6x7dsZF4GYmHwQyTiKXDqcEA6mXvFYcpALtD2PPSFGz26eVfqUtRiePBU3LK613594= X-Received: by 2002:a4a:dcd1:0:b0:569:a08a:d9c5 with SMTP id h17-20020a4adcd1000000b00569a08ad9c5mr3311948oou.0.1690047226928; Sat, 22 Jul 2023 10:33:46 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Adam Dinwoodie Date: Sat, 22 Jul 2023 18:33:31 +0100 Message-ID: Subject: Re: Most git executables are hard links to git.exe? To: jhg@acm.org Cc: cygwin@cygwin.com, Jim Garrison Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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 implementati= on > >> 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 =E2=80=93= in most cases I wouldn't expect there to be anything in that folder that couldn't be readily recovered elsewhere anyway =E2=80=93 or (d) switching t= o 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!