On Sun, Jan 29, 2017 at 5:00 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Carlo Wood <carlo@xxxxxxxxxx> writes: > >> 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.