{"thread":{"id":"30110","subject":"Maintaining historical data in a git repo","startedAt":"2012-03-30T13:34:08Z","lastAt":"2012-04-03T19:45:11Z","messageCount":13,"participants":["Yuval Adam","Seth Robertson","Jakub Narebski","Junio C Hamano","david@lang.hm","Mark Lodato","Holding, Lawrence","Ævar Arnfjörð Bjarmason","Andreas Stricker","Markus Elfring"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"188157","messageId":"CA+P+rLeyEcZPudhLWavB74CiDAqpn+iNkk4F8=NK_yGaJPMmyA@mail.gmail.com","threadId":"30110","inReplyTo":null,"subject":"Maintaining historical data in a git repo","fromName":"Yuval Adam","fromEmail":"yuv.adm@gmail.com","sentAt":"2012-03-30T13:34:08Z","receivedAt":"2012-03-30T13:34:08Z","isPatch":false,"sender":{"key":"yuv.adm@gmail.com","avatar":"https://gravatar.com/avatar/321e7ce50efd0a61a91e2065c2bc4171019421c961f7702c0310a29de4374a36?d=mp&s=160"},"body":"As part of a public project to open-source the Israeli law code, we\nare looking into ways of represent such data in a git repository.\n\nThe main challenge is to represent historical data _in a semantically\ncorrect way_ within a git repository, while having the ability to\nchange data that has occurred in the past.\nFor example, we might have revisions B and C of a certain legal\ndocument, commit to repo, and at a later time want to add revision A\nto the proper place in the git commit tree (probably with rebasing or\nreplacing).\nAllowing decentralization and updates is a major requirement.\n\nWe're trying to map out the various pros and cons of the different\noptions of maintaining such a repo.\nHas anyone ever attempted something like this?\nAre there any projects that build on the git plumbing which provide\nwrapper APIs to handle historic data?\n\nWe really could use any reference or advice we can get on this subject.\n\nThanks,\n\n--\nYuval Adam\nhttp://y3xz.com\n"},{"id":"188163","messageId":"201203301510.q2UFAqn6003864@no.baka.org","threadId":"30110","inReplyTo":"CA+P+rLeyEcZPudhLWavB74CiDAqpn+iNkk4F8=NK_yGaJPMmyA@mail.gmail.com","subject":"Re: Maintaining historical data in a git repo","fromName":"Seth Robertson","fromEmail":"in-gitvger@baka.org","sentAt":"2012-03-30T15:10:52Z","receivedAt":"2012-03-30T15:10:52Z","isPatch":false,"sender":{"key":"in-gitvger@baka.org","avatar":null},"body":"\nIn message , Yuval Adam writes:\n\n As part of a public project to open-source the Israeli law code, we\n are looking into ways of represent such data in a git repository.\n\nThis is extremely cool. I wish others were forward thinking enough\nto do this.\n\n The main challenge is to represent historical data _in a semantically\n correct way_ within a git repository, while having the ability to\n change data that has occurred in the past.\n\nRevision control shouldn't be used to change the past (even if git\nallows this with sufficient amounts of pain/warning to all users).\nWhat it is extremely good at is preserving the past and tracking the\nchanges that are made.\n\n For example, we might have revisions B and C of a certain legal\n document, commit to repo, and at a later time want to add revision A\n to the proper place in the git commit tree (probably with rebasing or\n replacing).\n\nThere is no problem doing this. I'll make up a mythical workflow\nwhich might be realistic. Someone proposes a bill, so a branch for\nthe proposal is created. In many of the laws I am familiar with,\nthere is the text of the law and then the text says \"Amend V.5.12.A.b\nto add '25: or to commit a nasal offense (as defined in V.5.12.A) with\na shoe'\". So the branch might contain the text of the proposed law\nand then actually go through to the document V.5.12.A.b and add the\nnew data to the appropriate file (in an ideal world that might be an\nautomatic process, but laws are rarely so precise). The proposed law\nchanges and the bill text changes would be committed onto the branch.\n\nAs the bill goes through committee people make changes, adding things,\nremoving things, etc. Each change is a commit. One example change\nmight be a new change saying \"remove the change made 2 days ago\" or\n\"make the current version the version from 10 days ago\". Both of\nthose specific changes would ideally be positive changes. You would\nnot actually be deleting the change made two days ago or removing all\nchanges made between 10 days ago and now, you would be making a new\ncommit to remove the effects of the unwanted changes.\n\nWhen the negotiations are over and assuming the bill gets all three\nreadings (each reading could be a \"tag\" to document exactly what was\nread) and voted into a law, you would then merge the bill branch into\nthe \"law\" branch which represents the actual legally active laws.\nThis could be done as a \"squash\" merge which hides all of the\ncommittee negotiations or it could be done as a normal merge which\nallows the history of the negotiations to be visible, or, depending on\nthe visibility of the committee negotiations, you could even do a\ncombination of the two.\n\nAnd yes, git supports more complex processes automatically, like each\nKnesset member making their own proposed changes and the committee\nchair merging the appropriate version in if it was approved and the\nothers being either discarded or archived for history but not\nincorporated.\n\n Allowing decentralization and updates is a major requirement.\n\ngit is extremely good at this.\n\n We're trying to map out the various pros and cons of the different\n options of maintaining such a repo.\n\nIdeally the data being represented would be structured, textual, and\nsomewhat line oriented, plain text/UTF-8 files (no matter the word\ndirection) like this email are ideal. Committing binary Office\ndocuments (Word, OpenXML, ODF, etc) is not ideal, since under most\ncircumstances/without a lot of work you are not going to get good\ndifferences so that you can easily see the history of the law. You\ncan write custom binary drivers to extract this difference information\nfrom these binary documents, but that is the \"lot of work\" I was\ntalking about.\n\nYou additionally might want to have separate repositories for separate\ngroups of laws to prevent repositories from getting unwieldy. There\nare tools which let you group repositories together.\n\n Has anyone ever attempted something like this?\n\nMany people use git to track living documents. Perhaps not law per\nse, but I don't particularly see why that would matter.\n\n Are there any projects that build on the git plumbing which provide\n wrapper APIs to handle historic data?\n\nAre you talking about \"get rid of that change, it was bad\" and\n\"restore this version of the document as the good one\" or \"how do I\nimport 64 years of law into git\"? Git provides native tools to handle\nboth.\n\n We really could use any reference or advice we can get on this subject.\n\nI'll point you at http://progit.org/book/ as a general reference about\ngit and http://sethrobertson.github.com/GitBestPractices/ as a\nreference about best practices.\n\n\t\t\t\t\t-Seth Robertson\n"},{"id":"188167","messageId":"CA+P+rLcWT0SZQjW2LtFXXCDRwjMp8daJ2hVup=7cnsRGbKw7xw@mail.gmail.com","threadId":"30110","inReplyTo":"201203301510.q2UFAqn6003864@no.baka.org","subject":"Re: Maintaining historical data in a git repo","fromName":"Yuval Adam","fromEmail":"yuv.adm@gmail.com","sentAt":"2012-03-30T15:55:51Z","receivedAt":"2012-03-30T15:55:51Z","isPatch":false,"sender":{"key":"yuv.adm@gmail.com","avatar":"https://gravatar.com/avatar/321e7ce50efd0a61a91e2065c2bc4171019421c961f7702c0310a29de4374a36?d=mp&s=160"},"body":"On Fri, Mar 30, 2012 at 6:10 PM, Seth Robertson wrote:\n>\n> Revision control shouldn't be used to change the past (even if git\n> allows this with sufficient amounts of pain/warning to all users).\n> What it is extremely good at is preserving the past and tracking the\n> changes that are made.\n\nThis is exactly what we _do_ want to do.\n\nOur use case for this is like so:\n\"ok, this is how the law is today, and we're not quite sure how it got\nto this point\"\nBut then some X time later:\n\"so we found out that clauses (1), (e) and (X) were changed on March\n30, 1957, and we want to know this for future reference\"\n\nSo, yes, we do need a way of knowing (blaming?) what happened in the\npast and how the law was shaped over time.\n\nIs this something that is definitively complicated with git?\n\n-- \nYuval Adam\nhttp://y3xz.com\n"},{"id":"188172","messageId":"201203301618.q2UGIF3Q005388@no.baka.org","threadId":"30110","inReplyTo":"CA+P+rLcWT0SZQjW2LtFXXCDRwjMp8daJ2hVup=7cnsRGbKw7xw@mail.gmail.com","subject":"Re: Maintaining historical data in a git repo","fromName":"Seth Robertson","fromEmail":"in-gitvger@baka.org","sentAt":"2012-03-30T16:18:15Z","receivedAt":"2012-03-30T16:18:15Z","isPatch":false,"sender":{"key":"in-gitvger@baka.org","avatar":null},"body":"\nIn message , Yuval Adam writes:\n\n On Fri, Mar 30, 2012 at 6:10 PM, Seth Robertson wrote:\n > Revision control shouldn't be used to change the past (even if git\n > allows this with sufficient amounts of pain/warning to all users).\n > What it is extremely good at is preserving the past and tracking the\n > changes that are made.\n\n This is exactly what we _do_ want to do.\n\n Is this something that is definitively complicated with git?\n\nAh, I understand now. I imagine others will chime in as well, but\nthis should not be too complex with git. You can easily go back into\nhistory and change it. The problem comes in when you have shared your\nrepository with other people.\n\nIn general, rewriting public history is a bad idea because git cannot\ntell the difference between someone adding to history for good reasons\n(expanding on known history) and bad reasons (retroactively rewriting\nthe law to add a loophole).\n\nYou can absolutely do it, but then you have to \"force push\" your\nchanges to the master server to override the history (assuming that is\nallowed, and it typically is not by default) and then everyone else\nwould have to do special things (`git pull --rebase` in the simple\ncase, rebuilding branches and tags in more complex cases) to get the\nnew history. Clearly for something like the law and the probable\ncomplex workflow it will have, this isn't a good method.\n\nWhat I would probably suggest is having either a historical branch or\na historical repository which is allowed and expected to be rewritten.\nThe changes would then be confined to places where active\n\"development\" would not be occurring and the process to recover from\nthe retroactive changes could be automated. The \"git replace\" and\n\"git grafts\" (the last might be deprecated) functionality could be\nused to merge the two histories together so it is transparent to those\nwho need a consistent view from now to the beginning. With a separate\nrepo then the normal users who only care about the recent changes and\ncurrent state don't ever have to do anything special or worry about\nthe history changes, but it should work in either case.\n\n\t\t\t\t\t-Seth Robertson\n"},{"id":"188177","messageId":"m3boneaw27.fsf@localhost.localdomain","threadId":"30110","inReplyTo":"201203301618.q2UGIF3Q005388@no.baka.org","subject":"Re: Maintaining historical data in a git repo","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2012-03-30T16:32:51Z","receivedAt":"2012-03-30T16:32:51Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Seth Robertson writes:\n\n> In message , Yuval Adam writes:\n> \n> On Fri, Mar 30, 2012 at 6:10 PM, Seth Robertson wrote:\n> > Revision control shouldn't be used to change the past (even if git\n> > allows this with sufficient amounts of pain/warning to all users).\n> > What it is extremely good at is preserving the past and tracking the\n> > changes that are made.\n> \n> This is exactly what we _do_ want to do.\n> \n> Is this something that is definitively complicated with git?\n> \n> Ah, I understand now. I imagine others will chime in as well, but\n> this should not be too complex with git. You can easily go back into\n> history and change it. The problem comes in when you have shared your\n> repository with other people.\n> \n> In general, rewriting public history is a bad idea because git cannot\n> tell the difference between someone adding to history for good reasons\n> (expanding on known history) and bad reasons (retroactively rewriting\n> the law to add a loophole).\n> \n> You can absolutely do it, \n\nFor example using `git filter-branch`, or grafts mechanism plus said\ngit-filter-branch, or interactive rebase for changes closer to current\nversion, or `git commit --amend` for latest version (latest commit).\n\n> but then you have to \"force push\" your\n> changes to the master server to override the history (assuming that is\n> allowed, and it typically is not by default) and then everyone else\n> would have to do special things (`git pull --rebase` in the simple\n> case, rebuilding branches and tags in more complex cases) to get the\n> new history. Clearly for something like the law and the probable\n> complex workflow it will have, this isn't a good method.\n\nWell, if nobody is basing their work on this repository, and it is\nmeant as read-only source of information, that doesn't matter much.\n\n> \n> What I would probably suggest is having either a historical branch or\n> a historical repository which is allowed and expected to be rewritten.\n[...]\n\nYet another solution would be to fix mistakes using `git replace`\nmechanism. It doesn't as much rewrite history, as paste on fixes;\nthis of course requires setting up sharing of those replacements\n(fixes).\n\nSee git-replace(1) manpage for more information.\n\n-- \nJakub Narebski\n"},{"id":"188180","messageId":"7vehsam3pn.fsf@alter.siamese.dyndns.org","threadId":"30110","inReplyTo":"CA+P+rLcWT0SZQjW2LtFXXCDRwjMp8daJ2hVup=7cnsRGbKw7xw@mail.gmail.com","subject":"Re: Maintaining historical data in a git repo","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-30T16:52:04Z","receivedAt":"2012-03-30T16:52:04Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Yuval Adam writes:\n\n> Is this something that is definitively complicated with git?\n\nThat's not really \"is it complicated with git\" question, I would have to\nsay. Any version control system you would build history starting from one\npoint going _forward_, never inserting past event as you dig back.\n\nSurely, you could fake it by rewriting history, but I do not think SCM is\nparticularly geared towards such a use case *while* investigating the\nhistory of the law and recording your findings.\n\nI do agree that once such a discovered history is *complete*, it would be\nnice to record it in a SCM with a powerful history digging capability in\nchronological order, though.\n"},{"id":"188203","messageId":"CA+P+rLeDFu4KgEZPw=k67iMWVVGcZ3q48VZjgXNLXn3NdyQnow@mail.gmail.com","threadId":"30110","inReplyTo":"7vehsam3pn.fsf@alter.siamese.dyndns.org","subject":"Re: Maintaining historical data in a git repo","fromName":"Yuval Adam","fromEmail":"yuv.adm@gmail.com","sentAt":"2012-03-30T20:39:38Z","receivedAt":"2012-03-30T20:39:38Z","isPatch":false,"sender":{"key":"yuv.adm@gmail.com","avatar":"https://gravatar.com/avatar/321e7ce50efd0a61a91e2065c2bc4171019421c961f7702c0310a29de4374a36?d=mp&s=160"},"body":"On Fri, Mar 30, 2012 at 7:52 PM, Junio C Hamano wrote:\n> That's not really \"is it complicated with git\" question, I would have to\n> say.  Any version control system you would build history starting from one\n> point going _forward_, never inserting past event as you dig back.\n\nThat is true.\nIt is very clear to us that an SCM is optimized for the prevalent use\ncase, which is tracking code (well, mostly code) as it is written.\nNaturally this always starts at some point in time and progresses into\nthe future.\n\nHowever, we perceive git as a very powerful tool, that can fit\nbeautifully with the way legislation works today.\nThe challenge for us - should we choose to accept it ;) - is to build\na set of wrapper tools that allow us to use git in such a way, while\nenabling us to build up past history.\n\nYes, this is not the usual use case, but we're highly motivated on\nmaking this work.\nWe believe this could also be an interesting experience for the git\ncommunity in seeing how the git plumbing can be used for other cases,\neven if they veer off on some weird tangent.\n\nWe'll definitely be back with more questions and updates, as we progress.\nThanks, everyone, for your responses and feedback!\n\n--\nYuval Adam\nhttp://y3xz.com\n"},{"id":"188217","messageId":"alpine.DEB.2.02.1203301513480.5814@asgard.lang.hm","threadId":"30110","inReplyTo":"CA+P+rLeDFu4KgEZPw=k67iMWVVGcZ3q48VZjgXNLXn3NdyQnow@mail.gmail.com","subject":"Re: Maintaining historical data in a git repo","fromName":"","fromEmail":"david@lang.hm","sentAt":"2012-03-30T22:29:12Z","receivedAt":"2012-03-30T22:29:12Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Fri, 30 Mar 2012, Yuval Adam wrote:\n\n> On Fri, Mar 30, 2012 at 7:52 PM, Junio C Hamano wrote:\n>> That's not really \"is it complicated with git\" question, I would have to\n>> say.  Any version control system you would build history starting from one\n>> point going _forward_, never inserting past event as you dig back.\n>\n> That is true.\n> It is very clear to us that an SCM is optimized for the prevalent use\n> case, which is tracking code (well, mostly code) as it is written.\n> Naturally this always starts at some point in time and progresses into\n> the future.\n>\n> However, we perceive git as a very powerful tool, that can fit\n> beautifully with the way legislation works today.\n> The challenge for us - should we choose to accept it ;) - is to build\n> a set of wrapper tools that allow us to use git in such a way, while\n> enabling us to build up past history.\n>\n> Yes, this is not the usual use case, but we're highly motivated on\n> making this work.\n> We believe this could also be an interesting experience for the git\n> community in seeing how the git plumbing can be used for other cases,\n> even if they veer off on some weird tangent.\n>\n> We'll definitely be back with more questions and updates, as we progress.\n> Thanks, everyone, for your responses and feedback!\n\nyou may want to take a hint from how the linux repository works.\n\nWhen git was created, the as-of-then current version was commited as the \nbase and development went on from there.\n\nLater on the linux historical repository was created (and re-created over \ntime as other versions were found).\n\nThe git graft command can be used to join the 'current' repository to the \n'historical' repository so that they can be treated as one.\n\nI strongly suspect that something along these lines is what you are \nneeding.\n\nDavid Lang"},{"id":"188225","messageId":"CAHREChiNbEVGR1+xvOhAa2Yg35N2O+JreF-mVm793bZGWzu+rw@mail.gmail.com","threadId":"30110","inReplyTo":"CA+P+rLeDFu4KgEZPw=k67iMWVVGcZ3q48VZjgXNLXn3NdyQnow@mail.gmail.com","subject":"Re: Maintaining historical data in a git repo","fromName":"Mark Lodato","fromEmail":"lodatom@gmail.com","sentAt":"2012-03-31T01:04:18Z","receivedAt":"2012-03-31T01:04:18Z","isPatch":false,"sender":{"key":"lodatom@gmail.com","avatar":"https://avatars.githubusercontent.com/u/58860?v=4"},"body":"On Fri, Mar 30, 2012 at 4:39 PM, Yuval Adam wrote:\n> However, we perceive git as a very powerful tool, that can fit\n> beautifully with the way legislation works today.\n> The challenge for us - should we choose to accept it ;) - is to build\n> a set of wrapper tools that allow us to use git in such a way, while\n> enabling us to build up past history.\n\nIf you're willing to put some time into either writing new tools or\ndoing complicated work by hand, you could use git to keep track of the\nhistory's history. Have two branches: a real \"master\" branch and a\n\"meta\" branch to keep track of master's history. The former is what\nend users would see: the most accurate history of the code to date.\nThe latter is what \"developers\" would use to rebuild the master branch\nwith new information (say, adding A before B and C).\n\nTo do this, you could try the following: Use normal git commands on\nthe master branch, but every time you change master (say, commit or\nrebase), also make a special commit on the meta branch with the first\nparent being a reference to the new value of master. Use the\nremaining parents as \"normal\" references to previous meta commits, and\nuse an empty tree. Now, the meta branch contains a complete history\nof the history, though viewing it will be extremely ugly unless you\ndevelop a custom tool to deal with its special form.\n\nOptionally, on the server, you could set up an update hook to disallow\nupdates of the master branch and disallow non-fast-forward updates of\nthe meta branch, and a post-receive hook to the master branch to point\nto the first parent of the meta branch each time the meta branch is\nupdated.\n\nOne caveat is that you must be careful about merges on the meta\nbranch, since git's default strategy will automatically do the wrong\nthing. You could write your own merge strategy to handle this.\n(Sadly there does not appear to be a way to use this strategy\nautomatically on per-branch basis.) Another workaround would be to\nuse something that is unmergable in the tree of the meta commit,\nrather than an empty tree - say, a single file with the commit ID of\nthe master branch - which would prevent the default strategy from\ntrivially and incorrectly merging.\n\nUsing such a system would be awkward by hand but not terribly\ndifficult to automate. You could create a \"git-meta-commit\" command\nto create a meta commit for the current branch. You might find\ncontrib/examples/git-merge.sh useful as a guide for how to do this.\nIf you'd like more details, please ask.\n\nIt would be nice if you could write a hook that automatically creates\na meta commit every time master's reflog is updated, but this does not\nseem possible at the moment.\n"},{"id":"188273","messageId":"A5E8E180685CEF45AB9E737A010799805DFAA8@cdnz-ex1.corp.cubic.cub","threadId":"30110","inReplyTo":"CAHREChiNbEVGR1+xvOhAa2Yg35N2O+JreF-mVm793bZGWzu+rw@mail.gmail.com","subject":"RE: Maintaining historical data in a git repo","fromName":"Holding, Lawrence","fromEmail":"lawrence.holding@cubic.com","sentAt":"2012-04-01T04:14:27Z","receivedAt":"2012-04-01T04:14:27Z","isPatch":false,"sender":{"key":"lawrence.holding@cubic.com","avatar":null},"body":"> Mark Lodato wrote:\n> On Fri, Mar 30, 2012 at 4:39 PM, Yuval Adam wrote:\n> > However, we perceive git as a very powerful tool, that can fit\n> > beautifully with the way legislation works today.\n> > The challenge for us - should we choose to accept it ;) - is to build\n> > a set of wrapper tools that allow us to use git in such a way, while\n> > enabling us to build up past history.\n> \n> If you're willing to put some time into either writing new tools or\n> doing complicated work by hand, you could use git to keep track of the\n> history's history. Have two branches: a real \"master\" branch and a\n> \"meta\" branch to keep track of master's history. The former is what\n> end users would see: the most accurate history of the code to date.\n> The latter is what \"developers\" would use to rebuild the master branch\n> with new information (say, adding A before B and C).\n> \nWhy 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.\n\n\n"},{"id":"188304","messageId":"CACBZZX46d8rx4ueY3-mNHfZ7T-zrw8rKsRG7VAoGZSbYEvOpiw@mail.gmail.com","threadId":"30110","inReplyTo":"CA+P+rLeDFu4KgEZPw=k67iMWVVGcZ3q48VZjgXNLXn3NdyQnow@mail.gmail.com","subject":"Re: Maintaining historical data in a git repo","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2012-04-02T11:38:17Z","receivedAt":"2012-04-02T11:38:17Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Fri, Mar 30, 2012 at 22:39, Yuval Adam wrote:\n> However, we perceive git as a very powerful tool, that can fit\n> beautifully with the way legislation works today.\n> The challenge for us - should we choose to accept it ;) - is to build\n> a set of wrapper tools that allow us to use git in such a way, while\n> enabling us to build up past history.\n\nYou can always solve this by having two repositories, you have one\ncanonical Git repository with your laws using some text-based format\nto describe when each change was added.\n\nYou'd never rewrite the history of this repository since it would\nrepresent the history of your project to give a commit timeline to the\nlaw, and not attempt to make your commit log reflect changes in the\nlaw.\n\nYou could then have tools to export another Git history from that\noriginal repository, that one would be constantly rewritten and nobody\nwould base changes on that.\n\nYou could also make the two one and the same, but you don't have to.\n"},{"id":"188399","messageId":"4F7AC1F8.4080702@futurelab.ch","threadId":"30110","inReplyTo":"CA+P+rLeyEcZPudhLWavB74CiDAqpn+iNkk4F8=NK_yGaJPMmyA@mail.gmail.com","subject":"Re: Maintaining historical data in a git repo","fromName":"Andreas Stricker","fromEmail":"astricker@futurelab.ch","sentAt":"2012-04-03T09:25:12Z","receivedAt":"2012-04-03T09:25:12Z","isPatch":false,"sender":{"key":"astricker@futurelab.ch","avatar":"https://gravatar.com/avatar/007ac93f9abc20ee78c5169783fcf3f065d470d6b53d47050e30cf7ebad5025b?d=mp&s=160"},"body":"Am 30.03.12 15:34, schrieb Yuval Adam:\n> As part of a public project to open-source the Israeli law code, we\n> are looking into ways of represent such data in a git repository.\n\nI remember a discussion about to US constitution [1] a while ago.\nThere are a few projects still available on github [2,3]. Maybe\nthis helps as a starting point.\n\nRegards, Andy\n\n\n[1] http://thread.gmane.org/gmane.comp.version-control.git/152433\n[2] https://github.com/jcsalomon/constitution\n[3] https://github.com/zorz/InternetFreedomAmendment\n\n"},{"id":"188430","messageId":"4F7B5347.3010701@web.de","threadId":"30110","inReplyTo":"CA+P+rLcWT0SZQjW2LtFXXCDRwjMp8daJ2hVup=7cnsRGbKw7xw@mail.gmail.com","subject":"Re: Maintaining historical outlines","fromName":"Markus Elfring","fromEmail":"markus.elfring@web.de","sentAt":"2012-04-03T19:45:11Z","receivedAt":"2012-04-03T19:45:11Z","isPatch":false,"sender":{"key":"markus.elfring@web.de","avatar":null},"body":"> Our use case for this is like so:\n> \"ok, this is how the law is today, and we're not quite sure how it got\n> to this point\"\n> But then some X time later:\n> \"so we found out that clauses (1), (e) and (X) were changed on March\n> 30, 1957, and we want to know this for future reference\"\n\nI imagine that technical challenges come from a different view for your use \ncase. Content management systems can eventually show differences for \nline-oriented text files easily. But I guess that you are also interested in the \nmaintenance of higher level semantic data structures that are usually contained \nin outlines.\n\nHow would you like to build relationships between commit logs and changes to \nitems like chapters, sections, paragraphs and sentences?\n\nDo you need to combine several information sources to generate a document query \nand result representation you desire?\n\nRegards,\nMarkus\n"}]}