Re: Maintaining historical data in a git repo

Seth Robertson [off-list ref] writes:

In message [ref], Yuval Adam writes:

    On Fri, Mar 30, 2012 at 6:10 PM, Seth Robertson [off-list ref] 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