Re: git push recurse.submodules behavior changed in 2.13

On 05/30, John Shahid wrote:

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.:

Yeah my patches would definitely break that kind of workflow because
they assumed that if you actually provided a refspec + --recurse that
you would want it propagated down.  When developing those patches I was
trying to avoid needing to add an additional flag to do the propagation
but given people were already relying on this behavior it looks like
that may be the only course of action.

quoted

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:

quoted

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 [off-list ref] wrote:

quoted

On Sun, May 28, 2017 at 7:44 PM, Junio C Hamano [off-list ref] wrote:

quoted

John Shahid [off-list ref] writes:

quoted

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

-- 
Brandon Williams