Hacker News Reader

Comment by notpeter | Hacker News Reader

> 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?

View on HN

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.

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

You can have unrelated commits and roots in a single git repo. No need for empty root commit.

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

Reply on news.ycombinator.com