4 ms·

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 differen

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?

icebraining 10y ago
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).
- Bromskloss 10y ago
  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?
  - icebraining 10y ago
    Yeah, I think so.
humanrebar 10y ago
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?
- rcthompson 10y ago
  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.
hendzen 10y ago
Sure, check out git-subtree (different than submodule).
MichaelBurge 10y ago
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.
cfallin 10y ago
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 https://github.com/dspinellis/unix-history-make (a repo with the scripts to build the final repo) https://github.com/dspinellis/unix-history-repo https://github.com/dspinellis/unix-history-repo (the final repo -- check out all of the different branches/tags)

icebraining 10y ago

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).

Bromskloss 10y ago
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?
- icebraining 10y ago
  Yeah, I think so.

humanrebar 10y ago

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?

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

hendzen 10y ago

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

MichaelBurge 10y ago

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.

cfallin 10y ago

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 https://github.com/dspinellis/unix-history-make (a repo with the scripts to build the final repo) https://github.com/dspinellis/unix-history-repo https://github.com/dspinellis/unix-history-repo (the final repo -- check out all of the different branches/tags)