3 ms·

Linus' words from the linked mailing list thread: > I'm very annoyed, because while the multi-root situation can be useful, it can also be confusing as hell. I

Linus' words from the linked mailing list thread: > I'm very annoyed, because while the multi-root situation can be useful, it can also be confusing as hell. It can cause bisection problems, and it can just cause people to go "WTF?" http://lkml.iu.edu/hypermail/linux/kernel/1603.2/01890.html http://lkml.iu.edu/hypermail/linux/kernel/1603.2/01890.html I guess history visualization tools would have a hard time with it as well. But in general, you normally start writing your changes from an existing commit anyways so why not branch from that?

masklinn 6y ago
> I guess history visualization tools would have a hard time with it as well. But in general, you normally start writing your changes from an existing commit anyways so why not branch from that? The case where that feature can legitimately be used is systems which started as completely separate (possibly with no idea that they even could get merged ever) and then got integrated e.g. TFA provides the example of btrfs which started development out of tree. In that case, just copying the project you're importing is obviously unacceptable (as it loses all history), and rewriting the entire history in order to "rebase" it has its own issues e.g. conflicts with existing files, loss of traceability since the commits get rewritten entirely and their hashes change, … So while it has its own issues (which you note), there are situations where merging a separate root does have advantages which outweigh the issues. The other alternatives (e.g. submodules) but all of them have their own drawbacks.
- dmurray 6y ago
  It doesn't seem fundamentally harder than pretending all of the changes happened in a different directory, and then that directory got moved from being a sibling to a subdirectory of the nominal project root.
  - Hello71 6y ago
    it's a problem in the git model, since all the commit hashes would change. that means that all existing references become invalid, including emails, commit messages, and pull requests.

masklinn 6y ago

> I guess history visualization tools would have a hard time with it as well. But in general, you normally start writing your changes from an existing commit anyways so why not branch from that? The case where that feature can legitimately be used is systems which started as completely separate (possibly with no idea that they even could get merged ever) and then got integrated e.g. TFA provides the example of btrfs which started development out of tree. In that case, just copying the project you're importing is obviously unacceptable (as it loses all history), and rewriting the entire history in order to "rebase" it has its own issues e.g. conflicts with existing files, loss of traceability since the commits get rewritten entirely and their hashes change, … So while it has its own issues (which you note), there are situations where merging a separate root does have advantages which outweigh the issues. The other alternatives (e.g. submodules) but all of them have their own drawbacks.

dmurray 6y ago
It doesn't seem fundamentally harder than pretending all of the changes happened in a different directory, and then that directory got moved from being a sibling to a subdirectory of the nominal project root.
- Hello71 6y ago
  it's a problem in the git model, since all the commit hashes would change. that means that all existing references become invalid, including emails, commit messages, and pull requests.