The biggest and weirdest commits in Linux kernel Git history (2017)

Re:The biggest and weirdest commits in Linux kernel Git hist... by masklinn on Friday December 25, 2020 @11:35AM (#25537366)

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

[ Parent | on HN ]

Re:The biggest and weirdest commits in Linux kernel Git hist... by dmurray on Friday December 25, 2020 @12:29PM (#25537736)

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.

[ Parent | on HN ]

Re:The biggest and weirdest commits in Linux kernel Git hist... by Hello71 on Friday December 25, 2020 @01:50PM (#25538235)

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.

[ Parent | on HN ]