mailing list mirror (one of many)
 help / Atom feed
From: John Shahid <>
To: Stefan Beller <>
Cc: Junio C Hamano <>, Brandon Williams <>, "" <>
Subject: Re: git push recurse.submodules behavior changed in 2.13
Date: Tue, 30 May 2017 08:01:33 -0400
Message-ID: <> (raw)
In-Reply-To: <>

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,

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



On Mon, May 29, 2017 at 12:20 AM, Stefan Beller <> wrote:
> On Sun, May 28, 2017 at 7:44 PM, Junio C Hamano <> wrote:
>> John Shahid <> 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]
>>> [2]
>> 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

  reply index

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-27 13:31 John Shahid
2017-05-29  2:44 ` Junio C Hamano
2017-05-29  4:20   ` Stefan Beller
2017-05-30 12:01     ` John Shahid [this message]
2017-05-30 17:05       ` Brandon Williams
2017-05-30 18:10 ` Jonathan Nieder
2017-05-31 14:50   ` John Shahid
2017-06-10 13:28     ` John Shahid
2017-06-12 17:27       ` Stefan Beller
2017-06-16 14:11         ` John Shahid

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link mailing list mirror (one of many)

Archives are clonable:
	git clone --mirror
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Newsgroups are available over NNTP:

 note: .onion URLs require Tor:
       or Tor2web:

AGPL code for this site: git clone public-inbox