3 ms·

> git it and empty root commit Why doesn't git init does this by default? It would be nice if every repo had an empty root commit (with no author, date,... so

by leni536 10y ago

> git it and empty root commit Why doesn't git init does this by default? It would be nice if every repo had an empty root commit (with no author, date,... so it has the same commit hash), then every two repos would have a common commit. Semantically it would mean that repos would be just specific branches of a hypotetical large repo.

Symbiote 10y ago
That would prevent merging a second repository into the first in its entirity.
geofft 10y ago
You can already merge two divergent histories with the --allow-unrelated-histories option. (At the data level, merge commits don't care that their parents have a common ancestor, but the git merge command does this as a safety check.) In other words, all repos already are subsets of the ur-repo. The semantically-interesting data in git is not the commits themselves, but the branch names given to specific commits in specific (groups of) repos. :)
- leni536 10y ago
  Interesting, now I learned that a git repo can have any number of commits that have no parents. It can be achieved by fetching an unrelated repo and merging with --allow-unrelated-histories or by using git checkout --orphan. > safety check Why is this considered unsafe? Only to avoid pulling from unrelated repos by accident? The man says for --allow-unrelated histories: > As that is a very rare occasion, no configuration variable to enable this by default exists and will not be added. Well this is quite harsh, it looks like it's considered to be rather unsafe.
  - geofft 10y ago
    Yeah, I imagine it's unsafe because "git pull" implicitly creates a merge commit when it can't otherwise update, and your remote URL might now be pointing at a different history. Maybe github.com/someproject/somecode got replaced by a clean rewrite and you're actually looking for someproject/somecode-old. Maybe you were pointing at an unofficial git-svn import and now there's an official git migration. And so forth. (Personally, I think the right way to address this is for "git pull" not to implicitly create merge commits...)

by leni536 10y ago

Symbiote 10y ago

That would prevent merging a second repository into the first in its entirity.

geofft 10y ago

You can already merge two divergent histories with the --allow-unrelated-histories option. (At the data level, merge commits don't care that their parents have a common ancestor, but the git merge command does this as a safety check.) In other words, all repos already are subsets of the ur-repo. The semantically-interesting data in git is not the commits themselves, but the branch names given to specific commits in specific (groups of) repos. :)

leni536 10y ago
Interesting, now I learned that a git repo can have any number of commits that have no parents. It can be achieved by fetching an unrelated repo and merging with --allow-unrelated-histories or by using git checkout --orphan. > safety check Why is this considered unsafe? Only to avoid pulling from unrelated repos by accident? The man says for --allow-unrelated histories: > As that is a very rare occasion, no configuration variable to enable this by default exists and will not be added. Well this is quite harsh, it looks like it's considered to be rather unsafe.
- geofft 10y ago
  Yeah, I imagine it's unsafe because "git pull" implicitly creates a merge commit when it can't otherwise update, and your remote URL might now be pointing at a different history. Maybe github.com/someproject/somecode got replaced by a clean rewrite and you're actually looking for someproject/somecode-old. Maybe you were pointing at an unofficial git-svn import and now there's an official git migration. And so forth. (Personally, I think the right way to address this is for "git pull" not to implicitly create merge commits...)