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

List:       git
Subject:    Re: Maintaining historical data in a git repo
From:       Seth Robertson <in-gitvger () baka ! org>
Date:       2012-03-30 16:18:15
Message-ID: 201203301618.q2UGIF3Q005388 () no ! baka ! org
[Download RAW message or body]


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, 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.

What I would probably suggest is having either a historical branch or
a historical repository which is allowed and expected to be rewritten.
The changes would then be confined to places where active
"development" would not be occurring and the process to recover from
the retroactive changes could be automated.  The "git replace" and
"git grafts" (the last might be deprecated) functionality could be
used to merge the two histories together so it is transparent to those
who need a consistent view from now to the beginning.  With a separate
repo then the normal users who only care about the recent changes and
current state don't ever have to do anything special or worry about
the history changes, but it should work in either case.

					-Seth Robertson
--
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]