On Fri, Feb 21, 2025 at 7:18 AM Konstantin Ryabitsev <konstantin@xxxxxxxxxxxxxxxxxxx> wrote: > > On Fri, Feb 21, 2025 at 12:18:09AM +0000, brian m. carlson wrote: > > > My Git repository on GitHub <https://github.com/espindula/br-blfs> has > > > about 23,500 commits. However, there are several old (before Feb, 28 > > > 2022) commits I would like to delete and maintain the newer ones > > > (after Feb, 28 2022). So, Is there any Git command (or combined > > > commands) I could use? > > > > No, Git doesn't offer such a thing. Due to the use of cryptographic > > hashes used, it would be impossible to verify the integrity of the > > repository if it could just be truncated like that. In addition, the > > goal of Git as a version control system is to track history, not to > > destroy it. > > > > However, if the concern is size and not something else (like removing > > personal information), then you could use a shallow clone to just > > download a certain number of revisions and work on that. The full > > history would remain on the server, and you could still push newer > > changes, but the size on your local machine would be smaller. If you > > need more history, you could use a partial clone instead if you're > > willing to be online to work. > > Another approach is to create a new repository and use a graft/replacement > commit to indicate that history continues in a different repository, right? I > do sometimes wish this was a bit easier/more accessible to perform, because > that would allow creating "epochs" for very large repos. Unfortunately, > shallow clones tend to be very heavy on the server-side. I'm totally in support of the "friends don't let friends use shallow-clones" point of view, even if I've had rather less success than I would have liked at promoting it. But throwing shade at shallow clones is just an impulse, not the real reason I'm responding here. Yes, if you're willing to rewrite history, invalidating all hashes and rewriting the recent-enough-ones-that-you-still-want-to-keep, you can go that route too. In fact, doing so is as easy as creating a replace ref graft (or grafts) which make the oldest commit(s) you want to keep look parentless, and then rewriting history to make that graft permanent and remove the graft. (Afterwards, you can make a separate graft from that new root commit to the original real commit if you want.) It turns out this is an example from user filed issues that comes up occasionally in git-filter-repo. While it's an example I documented with the commands to run, just so I can link to it if it's asked again, I really don't like the strategy of destroying history, especially since most users who ask for this kind of capability (Konstantin, you're a notable exception here) don't understand the points that brian brought up in his first paragraph. And I make sure to say as much right before I provide the example in my docs. But, yes, this is a possibility for those that don't mind destroying history.
