Re: Deleting first commits; maintaining last commits

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2025-02-21 at 16:05:59, Emily Shaffer wrote:
> For hosts which support it - which I believe includes GitHub - partial
> clone is generally easier on the server and a little bit less
> bug-prone than shallow clone.

The really expensive thing is fetching into a shallow clone.  A simple
shallow clone itself is not very expensive, and at $DAYJOB we encourage
large-scale users (such as CI systems) to use shallow clones for that
reason, since they're cheaper to serve than full clones, provided that
they never fetch into them.

Now, I agree that the particular use case here is probably going to be
fetching into a shallow clone, and that's okay if it's one particular
user doing that occasionally, which it sounds like it is.  It's
definitely a problem if it's thousands of CI jobs, though.

It may be that a partial clone does perform better overall, but it has
the downside that it effectively requires you to be online during usage,
whereas a shallow clone does not.  Whether that is a problem depends on
your use case: for work, I am effectively always online, so that's not a
problem, but for personal work, I want to be able to work on an
airplane (where there may be no Internet and the Wi-Fi, if any, is very
slow), in a hotel room with bad connectivity, or even on a retreat in
the middle of nowhere without Internet at all.

So that's why I mentioned both: both options have some upsides and some
downsides, and there's no one-size-fits-all solution.
-- 
brian m. carlson (they/them or he/him)
Toronto, Ontario, CA

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux