Re: git push recurse.submodules behavior changed in 2.13

2017-06-16 Thread John Shahid
On Mon, Jun 12, 2017 at 1:27 PM, Stefan Beller wrote: > On Sat, Jun 10, 2017 at 6:28 AM, John Shahid wrote: >> bump. it's been a while and I'm still not clear what the next steps >> are. I'm happy to send a patch but I would like to get a consensus >>

Re: git push recurse.submodules behavior changed in 2.13

2017-06-12 Thread Stefan Beller
On Sat, Jun 10, 2017 at 6:28 AM, John Shahid wrote: > bump. it's been a while and I'm still not clear what the next steps > are. I'm happy to send a patch but I would like to get a consensus > first. What do you want a consensus on? (Is the change in 2.13 a bug or feature? I

Re: git push recurse.submodules behavior changed in 2.13

2017-06-10 Thread John Shahid
bump. it's been a while and I'm still not clear what the next steps are. I'm happy to send a patch but I would like to get a consensus first. On Wed, May 31, 2017 at 10:50 AM, John Shahid wrote: > Hi Jonathan. Thanks a lot for the detailed and interesting response. I >

Re: git push recurse.submodules behavior changed in 2.13

2017-05-31 Thread John Shahid
Hi Jonathan. Thanks a lot for the detailed and interesting response. I included my comments/replies inline. tl;dr; 1. I love the idea of having tools treat the repo as a unit. 2. I think propagating the refspec when no refspec is passed on the CLI is very surprising action that should be

Re: git push recurse.submodules behavior changed in 2.13

2017-05-30 Thread Jonathan Nieder
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

Re: git push recurse.submodules behavior changed in 2.13

2017-05-30 Thread Brandon Williams
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

Re: git push recurse.submodules behavior changed in 2.13

2017-05-30 Thread John Shahid
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

Re: git push recurse.submodules behavior changed in 2.13

2017-05-28 Thread Stefan Beller
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

Re: git push recurse.submodules behavior changed in 2.13

2017-05-28 Thread Junio C Hamano
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 >

git push recurse.submodules behavior changed in 2.13

2017-05-27 Thread John Shahid
Hi all, 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