On Wed, Jul 21, 2010 at 19:56, Avery Pennarun <apenwarr@xxxxxxxxx> wrote:
> No amount of bugfixing in git submodule can fix this workflow, because
> it's not a result of bugs. (The bugs, particularly the
> disconnected-by-default HEADs on submodule checkouts, do make it a bit
> worse :( ) It would require a fundamental redesign to make this work
> nicely with submodules.
I think most of those can be fixed, actually. The only requirement
that the git plumbing imposes on git-submodules is that a "commit"
entry exist in your tree, the rest is just (ugly plumbing).
Thus, we could:
* Hack git-submodule (or its replacement) to check import the tree
that contains that "commit" into one central .git
* Fix git status / git commit so that you could commit into
submodules, i.e.:
for each submodule in this-commit:
chdir $submodule && commit
done && cd $root && commit -m"bumping sumbodules"
* Make git-push push the submodule contents and the
superprojects. You'd just need to have commit access to the url
listed in .gitmodules.
What's missing from that (which would be nice) is the ability to check
out a subdirectory from another repository. That could (I think) be
done by just adding a normal "tree" entry, and then specifying that
that tree can be found in git://... instead of the main tree.
> If we can get some kind of consensus in principle that git-subtree is
> a good idea to merge into git core, I can prepare some patches and we
> can talk about the details.
>From having looked at it briefly it looks very nice. But it looks to
me as if the main differences between git-submodule and git-subtree
are in the porcelain, not the plumbing.
It would be a lot less confusing to users of Git in the long term if
we would at least try to unify these two approaches instead of having
two mutually incompatible ways of doing essentially the same thing.
--
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