On Fri, Feb 13, 2026 at 06:43:37PM +0100, Marc Haber wrote:
The monk in me would like to rebuild the full repository that way,
retroactivly joining the past release tags that are now in the
repository with the points in the past when gbp import-orig
--pristine-tar /path/to/tarball was called on a release tarball.
Has this ever been done, or is it just too much work?
It's certainly possible to do that sort of repository surgery, at the
cost of changing commit IDs for everything after the first point in
history where you add an additional parent, and so meaning anyone who
already has your repository checked out would have to force-pull or
re-clone. This will necessarily include rewriting all your existing
tags.
I've only done this sort of thing myself when I was changing revision
control systems anyway, and I hope that's all in the past for me now.
However, I think "git filter-repo" (in the separate git-filter-repo
package) could probably do most of it for you, since I don't think you
want the trees associated with any of these commits to change; you just
want to graft an extra parent onto each of the commits on your current
upstream/latest branch and then rewrite all their descendants to match.
See the two sections in git-filter-repo(1) headed "Parent rewriting",
and do this in a separate clone of your repository and read at least the
"DISCUSSION" section before doing anything. I would definitely not do
it by manually re-committing everything as you suggest, even in some
kind of script - there are much better tools than that available.
I'm not personally sure that it's worth the effort and consequences
though.
--
Colin Watson (he/him) [[email protected]]
