Eyvind Bernhardsen <eyvind-git@xxxxxxxxxxxxxx> writes:
> One solution that occurred to me was to have a branch in each
> submodule for every main module and branch. A branch name would be
> provided for each submodule in .gitmodules, used by "submodule push"
> but not "submodule update". In this case, if the push to the branch
> fails, the main module branch is probably behind too.
>
> This seemed like a good idea, but it's racy.
It's not just racy, but I think it's wrong to limit to _one_ branch in
each submodule..
A submodule is an independent project on its own.
Suppose the commit DAG in the submodule looked like this:
o---o
/ \
--o---o---o---o---o---X---o---Z
\ /
o---o---o---o---o---o
\ /
o---o
and the superproject points at commit X. You may need to tweak the
submodule to make it work better with the change you are making to the
superproject.
You have two choices:
(1) update to some "stable" branch head that is descendant of X first,
and make sure it works with the superproject. Then develop on top of
it, and bind the tip of suc development trail to the superproject:
o---o
/ \
--o---o---o---o---o---X---o---Z---o---o---Y (your changes are Z..Y)
\ /
o---o---o---o---o---o
\ /
o---o
I think this is what you are suggesting. But the superproject may not be
ready to use the submodule with the history from the lower side branch
merged in. You would
(2) fork off of X and develop; bind the tip of such development trail to
the superproject. IOW, you make the submodule DAG like this, and
then "git add" commit Y in superproject.
o---o o---o---Y (your changes)
/ \ /
--o---o---o---o---o---X---o---Z
\ /
o---o---o---o---o---o
\ /
o---o
Sometimes forked branches need to be maintained until it proves stable
(and then your "tip" Y may be merged back to the tip of a public branch
Z). So you would at least need to allow a set of topic branches in
submodules that corresponds to a single lineage of superproject history.
Then when both Z (with the changes from the lower side branch) and Y (your
changes) prove stable, the submodule project may decide to make a merge
between Y and Z.
o---o o---o---Y (your changes)
/ \ / \
--o---o---o---o---o---X---o---Z---W
\ /
o---o---o---o---o---o
\ /
o---o
The superproject may decide to "git add" the result of such a merge, but
that decision is done separately (and obviously after such a merge is
made).
If everybody involved in the superproject forked from whatever happened to
be bound to the superproject, however, the submodule will have
uncontrolled number of unmerged "tips". For the submodule to stay viable
as an independent project, some management has to be done to clean up this
mess. To manage the forked development inside submodule properly, I do
not think you can autocruise from the toplevel superproject and leave the
random branches or unnamed commits unmerged.
That is why I suggested to:
* Leave the HEAD in submodule detached, if you are not working in it;
* Have a project policy regarding the use of branches in the submodule.
When you need to work on submodule, first switch to the branch (the
policy may allow/encourage you to create a new topic branch here), and
commit to it.
* The policy should also say when these forked branches should be merged;
keep them tidy by following that policy.
And by pushing from submodule and then in toplevel, you will never have
"superproject names a commit unreachable from any of the branch tips of
submodules" problem. Nor there is any raciness issue -- only after you
push out the submodule successfully, you push out the toplevel (and if the
former fails, you may need to redo the toplevel commit, but that happens
before you push it out so you can afford to rebase or amend).
--
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
