git@vger.kernel.org mailing list mirror (one of many)
 help / Atom feed
From: John Shahid <jvshahid@gmail.com>
To: Stefan Beller <sbeller@google.com>
Cc: Junio C Hamano <gitster@pobox.com>, Brandon Williams <bmwill@google.com>, "git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: git push recurse.submodules behavior changed in 2.13
Date: Tue, 30 May 2017 08:01:33 -0400
Message-ID: <CAE5=+KWzhhn3b14WoCXQD4Qb2gLd5soQQAUk7NTZeZnGgV61DA@mail.gmail.com> (raw)
In-Reply-To: <CAGZ79kYHNpsasqhTY2WrCYgNU1if-pK7UznJV9AWEhxVf6_GvQ@mail.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

  reply index

Thread overview: 10+ messages in thread (expand / 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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to='CAE5=+KWzhhn3b14WoCXQD4Qb2gLd5soQQAUk7NTZeZnGgV61DA@mail.gmail.com' \
    --to=jvshahid@gmail.com \
    --cc=bmwill@google.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=sbeller@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

git@vger.kernel.org mailing list mirror (one of many)

Archives are clonable:
	git clone --mirror https://public-inbox.org/git
	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:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.org/gmane.comp.version-control.git

 note: .onion URLs require Tor: https://www.torproject.org/
       or Tor2web: https://www.tor2web.org/

AGPL code for this site: git clone https://public-inbox.org/ public-inbox