Re: Feature Request: Branch-Aware Submodules

Stefan Beller [off-list ref] writes:

quoted

quoted

So you roughly do

    git checkout -b new-topic
    # change the submodule to point at the latest upstream version:
    git submodule update --remote <submodule-path>
    git commit -a -m "update submodule"
    git checkout master
    git merge new-topic
    # here seems to be your point of critic?
    # now the submodule pointer would still point to the latest
upstream version?

Isn't <submodule-path> subject to the usual 3-way merge when the
last step (i.e. a merge of new-topic branch into master in the
superproject) is made?  If 'master' hasn't changed <submodule-path>
since 'new-topic' forked from it, because 'new-topic' updated the
commit bound at <submodule-path>, doesn't "git merge new-topic" just
take that change as the normal "One side updated, the other did not
touch; take the update" merge?

Yes. I was unclear here.
By "latest upstream version" I meant the version you pulled in in the new-topic
branch via the "submodule update --remote" and that is preserved as is.

I do not think you were unclear at all.

What else is desired?  "git merge new-topic" leaves a result that is
not a merge of the changes made on that new-topic branch, by leaving
a stale <submodule-path> that was in 'master' as-is?

After all, the new-topic branch committed that "update submodule",
showing its desire that the latest-from-upstream commit it just
obtained must be at <submodule-path> from then on in the top-level
project.  If that change is not propagated (or at least "taken into
account") when merging it to 'master', the result is not a proper
"merge".  If new-topic didn't want the updated commit from the
submodule, it shouldn't have recorded that in its commit in the
first place.