4 ms·

> This repository will be often automatically regenerated from scratch, so this is not a place to make contributions. To ensure replicability its users are enco

> This repository will be often automatically regenerated from scratch, so this is not a place to make contributions. To ensure replicability its users are encouraged to fork it or archive it. I've run into this with source code archeology projects. Git is ill-suited to integrating newly discovered pre-history/missing intermediary history steps. Any new historical change, out of necessity, alters all subsequent commit hashes. This means collaboration and permalinks can't happen like with "normal" Git repos. Does anyone know of any tooling or an alternate vcs which has the ability to integrate new pre-history or alternate history (e.g. original branch commits alongside a squash and merge commit) without requiring completely breaking/re-writing the entire tree?

Rondom 8y ago
Git has a mechanism to declare two commits equal and replace one with the other: man git-replace This comes at the cost of having intentionally multiple histories and is not well-suited for complicate cases, but for the common case of "we want to stitch this old CVS-history to this commit", it does a good job. Usability-wise, replace refs are not cloned automatically and some web-based tools lack support for it.
- yebyen 8y ago
  You can also use the 'magic empty tree object' to make your repo more amenable to joining disparate histories of other trees. It requires both the source and destination repo to abide by this practice, but I do this on all of my repos... Immediately after `git init`, do `git commit --allow-empty -m"initial empty commit"`. Now you have an empty commit, and any other repo which has this empty commit has some history in common with your repo. The SHA-1 hash is well-known and there are plenty of articles you can find about it, if you search for 4b825dc642cb6eb9a060e54bf8d69288fbee4904 Here's one for example: https://stackoverflow.com/questions/9765453/is-gits-semi-secret-empty-tree-object-reliable-and-why-is-there-not-a-symbolic https://stackoverflow.com/questions/9765453/is-gits-semi-sec... I'm not sure this helps for projects which have a shared development history, but not a shared commit history. But within an organization, where you have projects which may split and/or merge, it can help to bridge some gaps.
  - dearrifling 8y ago
    You can have unrelated commits and roots in a single git repo. No need for empty root commit.
    - yebyen 8y ago
      I think the payoff is for merging unrelated histories, that you can then rebase one history on the other, and present a new unified history. Is the really only reason why people do this, so that you can rewrite your initial working commit in a rebase? I think that might be it. (You can't easily rewrite the initial commit with a rebase.)

Rondom 8y ago

Git has a mechanism to declare two commits equal and replace one with the other: man git-replace This comes at the cost of having intentionally multiple histories and is not well-suited for complicate cases, but for the common case of "we want to stitch this old CVS-history to this commit", it does a good job. Usability-wise, replace refs are not cloned automatically and some web-based tools lack support for it.

yebyen 8y ago
You can also use the 'magic empty tree object' to make your repo more amenable to joining disparate histories of other trees. It requires both the source and destination repo to abide by this practice, but I do this on all of my repos... Immediately after `git init`, do `git commit --allow-empty -m"initial empty commit"`. Now you have an empty commit, and any other repo which has this empty commit has some history in common with your repo. The SHA-1 hash is well-known and there are plenty of articles you can find about it, if you search for 4b825dc642cb6eb9a060e54bf8d69288fbee4904 Here's one for example: https://stackoverflow.com/questions/9765453/is-gits-semi-secret-empty-tree-object-reliable-and-why-is-there-not-a-symbolic https://stackoverflow.com/questions/9765453/is-gits-semi-sec... I'm not sure this helps for projects which have a shared development history, but not a shared commit history. But within an organization, where you have projects which may split and/or merge, it can help to bridge some gaps.
- dearrifling 8y ago
  You can have unrelated commits and roots in a single git repo. No need for empty root commit.
  - yebyen 8y ago
    I think the payoff is for merging unrelated histories, that you can then rebase one history on the other, and present a new unified history. Is the really only reason why people do this, so that you can rewrite your initial working commit in a rebase? I think that might be it. (You can't easily rewrite the initial commit with a rebase.)