Hacker News Reader

Comment by Bromskloss | Hacker News Reader

Hmm, so this is a case where a Git repository, with all its commit history, is the final product. Would it be feasible to develop this product within a different Git repository? How would one best do that? Is such a repository also available on GitHub?

View on HN

That's how the Unix History Repository was built, at least (a really cool project that reconstructed a synthetic git commit history for Unix from the initial Bell Labs source onward):

https://github.com/dspinellis/unix-history-make (a repo with the scripts to build the final repo)

https://github.com/dspinellis/unix-history-repo (the final repo -- check out all of the different branches/tags)

You can track a git repo inside another, as long as the "inner repo" is bare (otherwise git will add it as a submodule instead).

OK. How do you edit the inner repository, if it's bare? Do you have to clone it to a different directory, make changes, and then push it back to the original place?

Yeah, I think so.

I'd represent it as a sequence of git commands that turn an empty repository into the final product. Then I'd version control the shell script.

No. The properties added to a project by putting it under version control (versioning, diffs, development workflows, etc.) already exist in a git repo.

To put it another way, what is missing in a git repo that would make you want to put it in another git repo?

I think you're missing the point of the question. The entire history and metadata of this repo are all part of the final product in its current state, not representative of intermediate states of development. Essentially, this is a timeline of events being represented as a git repository. If the timeline were represented as a single text file, it would be easy to version in git. However, since it is already represented as a git repo, versioning it becomes problematic. Suppose you discovered an error in the ordering of events. You would fix the error by rewriting the history of the git repo. But how would you represent the action of you fixing the timeline? You need a second git repo for that.

In that case, amend a commit, push a new branch, add a new tag, and force push a new HEAD.

That sequence of actions is how you would fix the timeline represented by the git repo, but each time you make a fix, the previous version of the timeline is erased[1] by the force push. There is no mechanism to record the history of all the modifications you have made to the timeline. For this, you need a second git repo.

It might help to think of it in terms of time travel and alternate universes. You go back in time and kill Hitler, and now the entire timeline from that point onward is different. But maybe you decide that you need to go back in time and make further changes to history, e.g. preventing the assassination that triggered WW1. Every change you make creates a new universe, and now you need a way to keep track of all the alternate universes that you created, in case one of your changes turns out to make things worse. You need to keep track of the history of each universe, and you also need to keep track of the history of alternate universes that you created by changing history. There's now two levels of history, hence two git repos.

[1] Technically it's not erased until the next garbage collection, but that's beside the point.

Sure, check out git-subtree (different than submodule).

Reply on news.ycombinator.com