On 10-07-26 12:41 PM, Linus Torvalds wrote:
On Mon, Jul 26, 2010 at 9:37 AM, Marc Branchaud<marcnarc@xxxxxxxxxxx> wrote:
I think I should mention one aspect of what we're doing, which is that a lot
of our submodules are based on external code, and that we occasionally need
to modify or customize some of that code. So it's quite nice for us to
maintain private git mirrors of the external repos, with our own private
branches that contain our modifications. Although we want to get much of our
changes incorporated into the upstream code bases, upstream release cycles
are rarely in sync with ours.
THIS.
This is why I always thought that submodules absolutely have to be
commits, not trees. It's why the git submodule data structures are
done the way they are. Anything that makes the submodule just a tree
is fundamentally broken, I think.
That said, I'm not competent to comment on the actual user interface
issues. I can well believe that git-subtree has a nicer interface.
Linus
To me, that's what git-subtree is: an internal private mirror of an
external repo. Using git submodule moves that into a separately
managed repo, which is just unnecessary hassle. Why maintain repo
called "clone of library X for project A" when you can just stick it
inside of project A without any downsides?
For us, changes are made in the superproject and tested in the
superproject. Once they're tested, a git subtree push or a git subtree
split pushes the patches to the subproject. Once the subproject has
accepted the patches, a git subtree pull merges them. Same workflow as
the "private git mirror of external repo" listed above, just without the
hassle of having another repo to manage.
Bryan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html