Exploring an alternative to git-subtree

Exploring an alternative to git-subtree(mos6581.org)

46 points by brechtm 12 years ago | 10 comments

nwg 12 years ago |

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

brechtm 12 years ago | |

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.

That sentence intends to illustrate what can happen when you forget to push your submodule commit before commiting on the top-level repository.

Why was submodule better than just using a single repo and multiple remotes in this case?

I'm not sure what you mean with this.

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.

We used submodules because the code in the submodules was shared with another team.

You want to also branch the submodules so as not to break another branch.

laughinghan 12 years ago |

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

ingy 12 years ago | |

Serendipitously, I've been working on a new Git command called `git-subrepo` for the last 3 months that deals with all these concerns and more. The command became fully usable about a week ago.

The https://github.com/ingydotnet/git-subrepo addresses all the known concerns of the project owner, project collaborators, and end users. It keeps state in `path/subdir/.gitrepo` which means that git commands like `git mv` just work.

It also has squeaky clean history, which I've documented here: https://github.com/ingydotnet/git-subrepo/blob/master/doc/in...

Feel free to contact me by GitHub, IRC ingy@irc.freenode.net or email ingy@ingy.net.

brechtm 12 years ago | |

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.

weaksauce 12 years ago |

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

freshhawk 12 years ago | |

Yeah, it sounds like wrapping the relevant git commands to make them git-subrepo aware is the solution rather than using hooks.

phase_9 12 years ago |

I 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?

colin_mccabe 12 years ago |

The 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?

brechtm 12 years ago | |

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