Hi John,
John Shahid wrote:
> 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"
Thanks for reporting. The old behavior of "git push
--recurse-submodules" was a little loose (it would run "git push" in
the submodule and rely on defaults to determine the behavior) and when
propagating refspecs we considered taking the opportunity to tighten
that by propagating the default refspec when you run "git push
--recurse-submodules" without a refspec.
We didn't make that change. If starting over, it might be a natural
thing to do, but we didn't want to break existing users. So
git push --recurse-submodules=on-demand
should continue to work as before. *puzzled*
[...]
> 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,
[...]
> 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
Aha, you are passing a refspec!
Can you say more about how this change affects you? Would you be able
to push without a refspec, or do you e.g. have scripting that was
relying on the existing loose behavior?
To put this in more context: part of the ideal that
--recurse-submodules options are trying to achieve is to allow
thinking of a repository as a single unit, including submodules, most
of the time. To this end, "git clone --recurse-submodules" clones a
repository including its submodules, "git checkout
--recurse-submodules" checks out submodules as part of a checkout
operation, avoiding a separate "git submodule update --init" operation,
"git fetch --recurse-submodules" fetches upstream changes for both the
parent repository and submodules, and so on.
Unfortunately "git checkout --recurse-submodules" was missing a piece,
impacting this workflow. If I run
git checkout --recurse-submodules -b develop
then today this creates a "develop" branch in the superproject but not
within submodules. This hurts the illusion of the project being a single
unit and makes the meaning of operations like
git push --recurse-submodules develop:master
unclear.
Ideas for next steps:
1. If "git checkout --recurse-submodules -b develop" does the right
thing, then this situation is harder to get in in the first place.
The series at [3] is meant to do that.
2. The error message shown above is very unclear. It leaks
implementation details and doesn't give the user a clear hint
about what to do to resolve it. Would some message like the
following have helped?
$ git push --recurse-submodules origin develop
fatal: branch "develop" does not exist in submodule "sub"
hint: use "git -C sub branch develop <sha1>" to create such a branch
hint: or push without a branch name to push the current branch
3. Outside of the output from any particular command, we are missing
an equivalent of "man gitworkflows" to describe how the
--recurse-submodules options are meant to work. The series at [4]
aims to start addressing that.
Given all the above, this looks like a real and serious bug but I
think to find a different way from --recurse-submodules=propagate to
fix it. The idea, especially with [5], is for submodules to work
intuitively without requiring special options. This can require more
work in the short term getting the default behavior to work well with
a variety of use cases but I think it is time well spent.
Thoughts?
Thanks and hope that helps,
Jonathan
> [1] https://gist.github.com/jvshahid/b778702cc3d825c6887d2707e866a9c8
> [2] https://github.com/git/git/commit/06bf4ad1db92c32af38e16d9b7f928edbd647780
[3] http://public-inbox.org/git/20170501180058.8063-1-sbeller@xxxxxxxxxx/
[4] http://public-inbox.org/git/20170209020855.23486-1-sbeller@xxxxxxxxxx/
[5] http://public-inbox.org/git/20170526191017.19155-1-sbeller@xxxxxxxxxx/