Exploring an alternative to git-subtree
mos6581.org
Exploring an alternative to git-subtree
1–10 of 12 posts
Re: Exploring an alternative to git-subtree
#2Interesting idea. A motivated hacker could turn this into a git wrapper that could act as an intermediary to the real McCoy and make proper subrepo support baked into the commands.
Re: Exploring an alternative to git-subtree
#3Things get even more exciting when you want to push that submodule commit afterwards to fix things, only to find out that someone sneaked in a commit in the meantime! Now you’ll have to create a new commit on the top-level project to point it to your rebased commit, hah!
I don't quite understand this one. "Now you’ll have to create a new commit...". At this point, you haven't yet created a top-level project commit at all.
If the sequence is commit to submodule, push submodule, update top-level module, where is the headache that is unique to submodules here?
If that’s not enough to convince you, you should try branching with this setup. You’ll have to manually branch (and later merge) each of your submodules when you create a new branch. In the past, I have worked with a git repository containing a dozen tightly-coupled submodules for code-sharing with other teams. Needless to say, it didn’t take very long to realize that submodules are not suited for that use case.
Why was submodule better than just using a single repo and multiple remotes in this case? Or put another way, what did you gain by having separate repos if all the repos branch and come back in exactly the same way.
I feel like i can still make a lot of commits on both top-level and submodules but not have a headache, the parallel branching thing seems odd to me.
Re: Exploring an alternative to git-subtree
#4Interesting idea. A motivated hacker could turn this into a git wrapper that could act as an intermediary to the real McCoy and make proper subrepo support baked into the commands.
Yeah, it sounds like wrapping the relevant git commands to make them git-subrepo aware is the solution rather than using hooks.
Re: Exploring an alternative to git-subtree
#5The only downside he lists for git-subtree is that "your history will be complicated unnecessarily" if you use the rejoin option, and subtree pushes are slow if you don't use that option. But his solution also creates more than one commit whenever a change modifies a "subrepo" / library as well as the main codebase. So it doesn't really seem any better from the history point of view. Am I missing something?
Re: Exploring an alternative to git-subtree
#6[deleted]
Re: Exploring an alternative to git-subtree
#7I have anyways seen git submodules (and svn-externals before) to be a quick and dirty workaround for managing dependencies between modules.
I've been under the impression that using an artifact management tool such as Apache Ivy or Bower provides a more manageable and scalable solution, especially in projects with 20+ developers.
How does the solution proposed by the author compare? Does it compliment a managed artefact based solution?
Re: Exploring an alternative to git-subtree
#8This is better than git-subtree, but it unfortunately still results in an ugly commit history graph. I've actually been working on another alternative to git-subtree: https://github.com/laughinghan/git-subhistory
Splitting is the same as git-subtree, but doesn't duplicate commits when merging upstream commits to the library, by inverting split, creating commits in the main project corresponding to the upstream commits made to the library.
This results in a beautiful commit history graph: an upstream commit that adds a file to the library, becomes a commit that adds a file to the path to the library in the main project, that gets merged into the main history, which is exactly what you want. It does currently have the same performance problems git-subtree has, but I believe that is not fundamental.
Re: Exploring an alternative to git-subtree
#9The only downside he lists for git-subtree is that "your history will be complicated unnecessarily" if you use the rejoin option, and subtree pushes are slow if you don't use that option. But his solution also creates more than one commit whenever a change modifies a "subrepo" / library as well as the main codebase. So it doesn't really seem any better from the history point of view. Am I missing something?
git-subtree duplicates history. First you make a regular commit containing both your main project's changes and the subtree changes. Afterwards the subtree change is merged in again (or "subtree split --rejoin" or "subtree merge").
The advantage of git-subrepo is that your changes are immediately split up between the main project and the subrepo. Eventually, you should also be able to supply a separate commit message for the subrepo change (see "random ideas" section in the article).
Re: Exploring an alternative to git-subtree
#10This is better than git-subtree, but it unfortunately still results in an ugly commit history graph. I've actually been working on another alternative to git-subtree: https://github.com/laughinghan/git-subhistory Splitting is the same as git-subtree, but doesn't duplicate commits when merging upstream commits to the library, by inverting split, creating commits in the main project corresponding to the upstream commit…
Interesting. This will indeed result in a more linear history, but I don't agree that the commits from the external repo should be absorbed into the main project's history, just as the subtree changes should not be present in new commits made in the main project (hence git-subrepo). So, no, git-subhistory is not exactly what I want :)
However, git-subhistory will produce a history better suited for consumption by gitk (and other tools, I assume). I would like to argue though, that these tools should be aware of subrepos instead.