3 ms·

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 repre

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.

humanrebar 10y ago
In that case, amend a commit, push a new branch, add a new tag, and force push a new HEAD.
- rcthompson 10y ago
  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.

humanrebar 10y ago

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

rcthompson 10y ago
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.