Re: git push failing when push.recurseSubmodules on-demand and git commit --amend was used in submodule.

On Sun, Jan 29, 2017 at 5:00 PM, Junio C Hamano [off-list ref] wrote:

Carlo Wood [off-list ref] writes:

quoted

there seems to be a problem with using 'git commit --amend' in
git submodules when using 'git push --recurse-submodules=on-demand'
in the parent.

The latter fails, saying "The following submodule paths contain changes
that can not be found on any remote:" for such submodule, even though
the submodule is clean, pushed and reports 'Everything up-to-date'
when trying to push it.

I believe that the reason has to be that the parent repository thinks
that the comment that was amended, but not pushed, must be on the remote
too, while the whole point of amend is that this commit is not pushed.

I am not super familiar with the actualy implementation of the
codepaths involved in this, so CC'ed the folks who can help you
better.

I suspect the submodule folks would say it is working as intended,
if \

 - you made a commit in the submodule;
 - recorded the resulting commit in the superproject;
 - you amended the commit in the submodule; and then
 - you did "push, while pushing out in the submodule as needed" from
   the superproject.

Yes, for the current state of affairs, this is it.

There are two commits in the submodule that are involved in the
above scenario, and the first one before amending is needed by the
other participants of the project in order for them to check out
what you are trying to push in the superproject, because that is
what the superproject's tree records.  You somehow need to make that
commit available to them, but after you amended, the original commit
may no longer be reachable from any branch in your submodule, so
even if you (or the "on-demand" mechanism) pushed any and all
branches out, that would not make the needed commit available to
others.  If you push your top-level superproject out in such a
situation, you would break others.

In the long term future, we may want to reject non-fastforward
submodule updates. (Not sure if that is feasible)

I think you have two options.

 1. If the amend was done to improve things in submodule but is not
    quite ready, then get rid of that amended commit and restore the
    branch in the submodule to the state before you amended, i.e.
    the tip of the branch will become the same commit as the one
    that is recorded in the superproject.  Then push the submodule
    and the superproject out.  After that, move the submodule branch
    to point at the amended commit (or record the amended commit as
    a child of the commit you pushed out).

 2. If the amend is good and ready to go, "git add" to update the
    superproject to make that amended result the one that is needed
    in the submodule.

yup.