Re: git push recurse.submodules behavior changed in 2.13

[John Shahid <jvshahid@gmail.com>]

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 <sbeller@google.com> wrote:
> On Sun, May 28, 2017 at 7:44 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> John Shahid <jvshahid@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