RE: Maintaining historical data in a git repo
Show 16 quoted lines
> Mark Lodato wrote:
> On Fri, Mar 30, 2012 at 4:39 PM, Yuval Adam <yuv.adm@gmail.com> wrote:
> > However, we perceive git as a very powerful tool, that can fit
> > beautifully with the way legislation works today.
> > The challenge for us - should we choose to accept it ;) - is to build
> > a set of wrapper tools that allow us to use git in such a way, while
> > enabling us to build up past history.
>
> If you're willing to put some time into either writing new tools or
> doing complicated work by hand, you could use git to keep track of the
> history's history. Have two branches: a real "master" branch and a
> "meta" branch to keep track of master's history. The former is what
> end users would see: the most accurate history of the code to date.
> The latter is what "developers" would use to rebuild the master branch
> with new information (say, adding A before B and C).
>
Why not just skip the master branch altogether? Create a branch named for today's date and commit to it the history of the law as seen at today. When historic changes are discovered, create a branch where it fits into the record (named for the date of the discovery), commit the new version, then cherry pick the remainder of the history from then on top of it. Ending up with two parallel historic records showing what you thought the history of the document was up until last Wednesday and the new branch of what we know now. Having the same version of the document in multiple branches has no storage penalties in git.