4 ms·

You can do this but rebasing plays havoc on a lot of git integrations. Every time you insert a commit into an earlier spot, it changes the hash of every commit

You can do this but rebasing plays havoc on a lot of git integrations. Every time you insert a commit into an earlier spot, it changes the hash of every commit after it which has the potential to cause all kinds of problems for systems assuming git hashes are permanent.

progman32 6y ago
For sure, this is very bad practice when using git for forward development. When working in reverse, a lot of things go out the window :) The way I see it, git's main role here would simply be a way to standardize patch format, not its usual role as a distributed software development aid.
- bsdimp 6y ago
  Git's role would be to record the system incrementally as each patch is applied. I've already worked all the way back to the unpatched system. I assume that if I got it right, then I'll be able to rebuild. I've mostly been able to, and I'm investigating the mostly. Plus, I'm making sure that it's 100% reproducible so anybody can down the TUHS artifacts, run my scripts and have release 0 tapes, and a git repo of all the changes. And historians will be able to see what's definitely original, and my reconstructions of missing changes to programs. Those we'll never know to a higher degree of 'consistent with everything else'