Every so often I find it necessary to move things from one repo to another and preserve history along the way. I've made do with a janky shell script that recreates all the commits touching relevant files in the new repo, but this looks like a much less sketchy way to do it. It even sends changes back to the original repo if I understand the code right.
Git can already do that with subtree, no other tools needed.
(Note that subtree is a user-contributed script, but it's been made to ship with most git installations)
Every so often I find it necessary to move things from one repo to another and preserve history along the way. I've made do with a janky shell script that recreates all the commits touching relevant files in the new repo, but this looks like a much less sketchy way to do it. It even sends changes back to the original repo if I understand the code right.
Git can already do that with subtree, no other tools needed.
git-subtree is for incorporating an entire repo. To cherry-pick a single directory from another repo you probably need git-filter-branch to split that out into a standalone repo first, followed by git-subtree. Still, this is just two commands so I don’t see why a third party tool is warranted, especially since the third-party tool here seems to require a more complicated process (maybe it achieves more than what I think it achieves, I just don’t see it from the description, especially considering the problem it set out to solve seems to be exactly what I had in mind).
Every so often I find it necessary to move things from one repo to another and preserve history along the way. I've made do with a janky shell script that recreates all the commits touching relevant files in the new repo, but this looks like a much less sketchy way to do it. It even sends changes back to the original repo if I understand the code right.
Git can already do that with subtree, no other tools needed.
I'm still not too familiar with the differences between subtree and submodule. When should I use either?
Every so often I find it necessary to move things from one repo to another and preserve history along the way. I've made do with a janky shell script that recreates all the commits touching relevant files in the new repo, but this looks like a much less sketchy way to do it. It even sends changes back to the original repo if I understand the code right.
Yeah, when I include code from gists I try to include the history as well. I'm going to try this next time.
What's the architecture of this idea? Is there a reasonable assumption that it would keep the complexity for maintainers low in 3+ repos having a relationship with each other? If so, how?
Not sure I understand the question correctly, but here goes: My personal bias is to keep using submodules or at least subtrees where possible, mainly because it's builtin and because it's written by smart people. This is mostly for when repositories are pretty big and you don't want to submodule/subtree the entirety. But that's just me. I hope the maintainer complexity is as low as any other git solution, all the reb…
My impression is that monorepo got popular because submodules are too complicated to use on 3+ projects combined together. And I don't mean that the user interface sucks or that it's illogical to use, but most people will tend to use rather less submodules than more, even experienced git users. Therefore I think the breakthrough will come with someone who really understands submodules but has a great idea how to simplify the process. I hope this project may be a step in the right direction. Therefore I want to know more about the internals.
Git can already do that with subtree, no other tools needed.
git-subtree is for incorporating an entire repo. To cherry-pick a single directory from another repo you probably need git-filter-branch to split that out into a standalone repo first, followed by git-subtree. Still, this is just two commands so I don’t see why a third party tool is warranted, especially since the third-party tool here seems to require a more complicated process (maybe it achieves more than what I th…
Filter-branch / subtree doesn't let you move files outside the subdirectory, as far as I'm aware. Happy to be corrected on this point though.
Every so often I find it necessary to move things from one repo to another and preserve history along the way. I've made do with a janky shell script that recreates all the commits touching relevant files in the new repo, but this looks like a much less sketchy way to do it. It even sends changes back to the original repo if I understand the code right.
Git can already do that with subtree, no other tools needed.
How can I use subtree to move a file into a repo preserving history?
Git can already do that with subtree, no other tools needed.
I'm still not too familiar with the differences between subtree and submodule. When should I use either?
subtree is more transparent to users of the repo as it is basically pulling in a copy of the repository during the clone. submodules on the other hand are only storing the metadata pointer to the child repo and require users to manually clone. I have more information regarding subtree (and subtree merge strategy) on this answer: https://stackoverflow.com/a/33579069/2105636
git-subtree is for incorporating an entire repo. To cherry-pick a single directory from another repo you probably need git-filter-branch to split that out into a standalone repo first, followed by git-subtree. Still, this is just two commands so I don’t see why a third party tool is warranted, especially since the third-party tool here seems to require a more complicated process (maybe it achieves more than what I th…
Filter-branch / subtree doesn't let you move files outside the subdirectory, as far as I'm aware. Happy to be corrected on this point though.
There's basically nothing you can't do with filter-branch and the variety of filters it can execute. Moving a subdirectory to the root is trivial with --subdirectory-filter, but even without that, you could do it with --index-filter or --tree-filter.