
Exploring an alternative to git-subtree - brechtm
http://www.mos6581.org/git_subtree_alternative
======
nwg
_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
_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
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](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
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](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...](https://github.com/ingydotnet/git-
subrepo/blob/master/doc/intro-to-subrepo.md#clean-history)

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

------
weaksauce
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
Yeah, it sounds like wrapping the relevant git commands to make them git-
subrepo aware is the solution rather than using hooks.

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

