Seth Robertson <in-gitvger@xxxxxxxx> writes: > In message <CA+P+rLcWT0SZQjW2LtFXXCDRwjMp8daJ2hVup=7cnsRGbKw7xw@xxxxxxxxxxxxxx>, Yuval Adam writes: > > On Fri, Mar 30, 2012 at 6:10 PM, Seth Robertson <in-gitvger@xxxxxxxx> wrote: > > Revision control shouldn't be used to change the past (even if git > > allows this with sufficient amounts of pain/warning to all users). > > What it is extremely good at is preserving the past and tracking the > > changes that are made. > > This is exactly what we _do_ want to do. > > Is this something that is definitively complicated with git? > > Ah, I understand now. I imagine others will chime in as well, but > this should not be too complex with git. You can easily go back into > history and change it. The problem comes in when you have shared your > repository with other people. > > In general, rewriting public history is a bad idea because git cannot > tell the difference between someone adding to history for good reasons > (expanding on known history) and bad reasons (retroactively rewriting > the law to add a loophole). > > You can absolutely do it, For example using `git filter-branch`, or grafts mechanism plus said git-filter-branch, or interactive rebase for changes closer to current version, or `git commit --amend` for latest version (latest commit). > but then you have to "force push" your > changes to the master server to override the history (assuming that is > allowed, and it typically is not by default) and then everyone else > would have to do special things (`git pull --rebase` in the simple > case, rebuilding branches and tags in more complex cases) to get the > new history. Clearly for something like the law and the probable > complex workflow it will have, this isn't a good method. Well, if nobody is basing their work on this repository, and it is meant as read-only source of information, that doesn't matter much. > > What I would probably suggest is having either a historical branch or > a historical repository which is allowed and expected to be rewritten. [...] Yet another solution would be to fix mistakes using `git replace` mechanism. It doesn't as much rewrite history, as paste on fixes; this of course requires setting up sharing of those replacements (fixes). See git-replace(1) manpage for more information. -- Jakub Narebski -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html