0

To my knowledge there is no such thing in git as a built-in setting for 'max-history-length', i.e. a maximum number of commits after which the oldest ones will start to be 'dropped' into oblivion and the depth would be automatically adjusted in some sort of 'lossy history' compression, similar to how git clone --depth=42 limits the number of commits to include into a local 'lossy' clone.

Are there alternative ways of achieving an automatic or semi-automatic truncation of old commits in a repo in a way that will not require push --force?

I am aware of approaches like git clone --depth=1 or git-filter-repo as covered in other questions:

All of these solutions require manual interventions that need to be applied on a regular basis. Is there a better way that would achieve the objective of keeping a maximum of NN commits in a live repo while still allowing it to be synched in the usual way while preventing it from growing indefinitely?

ccpizza
  • 28,968
  • 18
  • 162
  • 169

1 Answers1

4

Are there alternative ways of achieving an automatic or semi-automatic truncation of old commits in a repo in a way that will not require push --force?

No. By definition, you are modifying the history of the repo so that it no longer shares a common ancestry with the remote repo. You must push --force your branch overtop of the remote state, breaking history for all other consumers of the repo.

Generally there is no reason to do this. Git history is compressed and stored as deltas. You are not meant to discard history, this is antithetical to how Git models change over time.

LeGEC
  • 46,477
  • 5
  • 57
  • 104
user229044
  • 232,980
  • 40
  • 330
  • 338
  • thanks for clarifying; I suspect that I am probably misusing/abusing git for its easy synching mechanism and great tooling while not needing the history and ancestry part; in the way git exists today it's apparently impossible to decouple something like a `shallow-git` with an fixed tail length, unless someone comes up with a compatible 'shallow git' fork.. – ccpizza Feb 28 '23 at 17:27
  • 1
    Just to clarify, though: commits themselves are _not_ deltas. It's just the compressed version that is effectively deltas; it gets made automatically when the history seems to require it. – matt Feb 28 '23 at 18:20
  • 1
    @ccpizza It would probably be possible to turn the manual action into a script. But I agree totally with the spirit of this answer: don't use Git wrong, just stop worrying and be happy and let the history grow. "Fellow citizens, we cannot escape history." – matt Feb 28 '23 at 18:22
  • @ccpizza Seems like maybe you just want [`rsync`](https://en.wikipedia.org/wiki/Rsync)? Efficient syncing of directories across a network predates Git by decades. There are far better tools, if that's what you're actually trying to do. – user229044 Feb 28 '23 at 18:36
  • @user229044: one (but not the only) use case is keeping in sync a few hundred/thousands of files between different devices, headless boxes, desktops and mobiles and git is easily available on all of them, `rsync` would be too indiscriminate as it won't allow to cleanly keep track of updates especially when changes are coming from more than two devices. – ccpizza Feb 28 '23 at 18:44