On Fri, Mar 30, 2012 at 4:39 PM, Yuval Adam <yuv.adm@xxxxxxxxx> 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). To do this, you could try the following: Use normal git commands on the master branch, but every time you change master (say, commit or rebase), also make a special commit on the meta branch with the first parent being a reference to the new value of master. Use the remaining parents as "normal" references to previous meta commits, and use an empty tree. Now, the meta branch contains a complete history of the history, though viewing it will be extremely ugly unless you develop a custom tool to deal with its special form. Optionally, on the server, you could set up an update hook to disallow updates of the master branch and disallow non-fast-forward updates of the meta branch, and a post-receive hook to the master branch to point to the first parent of the meta branch each time the meta branch is updated. One caveat is that you must be careful about merges on the meta branch, since git's default strategy will automatically do the wrong thing. You could write your own merge strategy to handle this. (Sadly there does not appear to be a way to use this strategy automatically on per-branch basis.) Another workaround would be to use something that is unmergable in the tree of the meta commit, rather than an empty tree - say, a single file with the commit ID of the master branch - which would prevent the default strategy from trivially and incorrectly merging. Using such a system would be awkward by hand but not terribly difficult to automate. You could create a "git-meta-commit" command to create a meta commit for the current branch. You might find contrib/examples/git-merge.sh useful as a guide for how to do this. If you'd like more details, please ask. It would be nice if you could write a hook that automatically creates a meta commit every time master's reflog is updated, but this does not seem possible at the moment. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html