Hi,

On Sat, 01 Feb 2025 at 13:28, Leo Famulari <l...@famulari.name> wrote:
> On Sat, Feb 01, 2025 at 10:44:40AM +0100, Lars-Dominik Braun wrote:
>> > ## Repository Migration Path
>> 
>> do we want to take this opportunity to start off fresh without migrating
>> the main repository’s history? It looks like we have accumulated more
>> than 500MB of commit data so far and everyone who runs `guix pull` the
>> first time has to download all of that and authenticate a pretty large
>> number of commits. (Plus, ~/.cache/guix keeps on growing and growing.)
>
> I'm not sure this is worth it, but maybe we can do better! If we were to
> prune the repo in this way, it would break `guix time-machine`, which is
> a nice selling point of Guix and really valuable.

I agree that’s an opportunity for trimming all the commits before ~2019:
They are not reachable by ’guix time-machine’ and will never be because
we cannot go back in time before the invention of the time-travel
mechanism (inferior, etc.).

Even, the module (guix scripts time-machine) contains:

--8<---------------cut here---------------start------------->8---
;;; The required inferiors mechanism relied on by 'guix time-machine' was
;;; firmed up in v1.0.0; it is the oldest, safest commit that can be travelled
;;; to.
(define %oldest-possible-commit
  "4a0b87f0ec5b6c2dcf82b372dd20ca7ea6acdd9c") ;v0.16.0
--8<---------------cut here---------------end--------------->8---

All these commits before v0.16 could be archived.  And the “new”
repository would start at this 4a0b87f0ec5b6c2dcf82b372dd20ca7ea6acdd9c.

This would save some resource that are downloaded for nothing at the
first “guix pull”.

Well, for some files, ’git blame’ and ’git log’ would be “broken” but if
I count the number of times that I dug the history before 2019, it would
not be an issue for me to use another archived / separated repository.

Cheers,
simon

Reply via email to