[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    Re: Maintaining historical data in a git repo
From:       Jakub Narebski <jnareb () gmail ! com>
Date:       2012-03-30 16:32:51
Message-ID: m3boneaw27.fsf () localhost ! localdomain
[Download RAW message or body]

Seth Robertson <in-gitvger@baka.org> writes:

> In message <CA+P+rLcWT0SZQjW2LtFXXCDRwjMp8daJ2hVup=7cnsRGbKw7xw@mail.gmail.com>, Yuval Adam writes:
> 
>     On Fri, Mar 30, 2012 at 6:10 PM, Seth Robertson <in-gitvger@baka.org> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]