Hi Dave, > Eric, can reposurgeon retroactively add an earlier release to git > without changing all the existing git hashes (which are referenced all > over the place, in the bug tracker and elsewhere)? I know nothing > about how these hashes are generated, so this may be utterly > infeasible.
A Git commit ID is effectively a hash of its ancestry so that history can't be changed in this case without the unwanted ripple. If the groff Git repository had an empty ‘epoch’ commit from which everything descended then other old versions could descend from that without affecting existing descendants, but I don't think it has. The oldest commit looks to be for 1.02. https://git.savannah.gnu.org/cgit/groff.git/commit/?h=1.04&id=351da0dcdf702cf243d26ffa998961bce2aa8653 If the epoch commit had existed then the new contributions wouldn't have been in their correct location, e.g. 1.03 wouldn't be between 1.02 and 1.04, but Git's various searches could still have included them. The alternative is to have a Git repo specifically for maintaining historical versions, not for development, and then the commit IDs can be completely regenerated as new discoveries are inserted. This is what Spinellis does for his https://github.com/dspinellis/unix-history-repo#readme -- Cheers, Ralph.