Junio, sorry for the poor report. I totally forgot to describe the behavior that i'm currently getting vs what i expect.
Expected behavior: We have a parent repo on a branch called "develop" and a submodule on a branch called "master". Prior to git version 2.13 if we had an unpushed commit in the submodule and ran "git push origin develop --recurse-submodules=on-demand" git would happily push the develop branch of the parent repo and the master branch of the submodule, e.g.: > Pushing submodule 'sub' > Counting objects: 2, done. > Delta compression using up to 4 threads. > Compressing objects: 100% (2/2), done. > Writing objects: 100% (2/2), 242 bytes | 0 bytes/s, done. > Total 2 (delta 0), reused 0 (delta 0) > To /home/jvshahid/codez/git/t/trash > directory.t9904-diff-branch-submodule-push/sub.git > 3cd2129..69cbc06 master -> master > Counting objects: 2, done. > Delta compression using up to 4 threads. > Compressing objects: 100% (2/2), done. > Writing objects: 100% (2/2), 283 bytes | 0 bytes/s, done. > Total 2 (delta 0), reused 0 (delta 0) > To ../pub.git > 7ff6fca..945bc12 develop -> develop > ok 2 - push if submodule has is on a different branch Actual behavior: After the change mentioned in my previous email, git would propagate the refspec from the parent repo to the submodule, i.e. it would try to push a branch called "develop" in the submodule which would error since no branch with that name exist in the submodule. Here is a sample output with git v2.13.0: > pushing to ref refs/heads/develop:refs/heads/develop > pushging to remote origin > fatal: src refspec 'refs/heads/develop' must name a ref > fatal: process for submodule 'sub' failed > fatal: The remote end hung up unexpectedly I hope this clarifies my bug report. Stefan, one little correction. I don't think the commit called out this behavior. The commit message was talking about unconfigured remotes (i.e. pushing to a url or local path) to not propagate the refspec and preserve the current behavior. Judging from the code and a test case that I wrote, this behavior is working as expected. That is, git won't propagate the refspec. Cheers, JS On Mon, May 29, 2017 at 12:20 AM, Stefan Beller <sbel...@google.com> wrote: > On Sun, May 28, 2017 at 7:44 PM, Junio C Hamano <gits...@pobox.com> wrote: >> John Shahid <jvsha...@gmail.com> writes: >> >>> It looks like the git push recurse-submodules behavior has changed. >>> Currently with 2.13 you cannot run "git push >>> --recurse-submodules=on-demand" if the parent repo is on a different >>> branch than the sub repos, e.g. parent repo is on "develop" and >>> sub-repo on "master". I created a test that can be found here [1]. >>> >>> A bisect shows that the change to propagate refspec [2] to the >>> submodules is the culprit. imho this is an undesired change in >>> behavior. I looked at the code but couldn't see an easy way to fix >>> this issue without breaking the feature mentioned above. The only >>> option I can think of is to control the refspec propagation behavior >>> using a flag, e.g. "--propagate-refspecs" or add another >>> recurse-submodules option, e.g. "--recurse-submodules=propagate" >>> >>> What do you all think ? >>> >>> [1] https://gist.github.com/jvshahid/b778702cc3d825c6887d2707e866a9c8 >>> [2] >>> https://github.com/git/git/commit/06bf4ad1db92c32af38e16d9b7f928edbd647780 >> >> Brandon? I cannot quite tell from the report what "has changed" >> refers to, what failures "you cannot run" gets, and if that is a >> desirable thing to do (i.e. if letting the user run it in such a >> configuration would somehow break things, actively erroring out may >> be a deliberate change) or not (i.e. an unintended regression). >> > > Before the refspec was passed down into the submodules, > we'd just invoke "git push" in the submodule assuming the user > setup a remote tracking branch and a push strategy such that > "git push" would do the right thing. > And because the submodule is configured independently, it > doesn't matter which branch you're on in the superproject. > > Looking at the test[1], you run "git push --recurse-submodules" > without any remote/branch that was called out in the commit > message[2] to not have changed. Is that understanding correct? > > Looking at the test cases of [2] we did not test for explicit > "still works with no args given", though one could have expected > we'd have a test for that already. :/ > > Thanks, > Stefan
