Skip Menu |

This queue is for tickets about the Dist-Zilla-Plugin-Git CPAN distribution.

Report information
The Basics
Id: 88139
Status: open
Priority: 0/
Queue: Dist-Zilla-Plugin-Git

People
Owner: Nobody in particular
Requestors: DOHERTY [...] cpan.org
STEVENL [...] cpan.org
Cc: ether [...] cpan.org
AdminCc:

Bug Information
Severity: Normal
Broken in: 2.014
Fixed in: (no value)



Subject: dzil Git::Push hangs
When releasing a distribution to CPAN, the process hangs at the last stage when it is supposed to be doing a git push. The following was printed to screen: [@Filter/UploadToCPAN] PAUSE add message sent ok [200] [@Git/Commit] Committed Changes dist.ini [@Git/Tag] Tagged v0.12 [@Git/Push] pushing to origin No error messages were output. Nor did it ask for my github authentication details. It just hangs indefinitely (or is that information meant to go in some file?). In the end I had to kill the process and push it manually.
On Mon Aug 26 09:28:06 2013, STEVENL wrote: Show quoted text
> When releasing a distribution to CPAN, the process hangs at the last > stage when it is supposed to be doing a git push. The following was > printed to screen: > > [@Filter/UploadToCPAN] PAUSE add message sent ok [200] > [@Git/Commit] Committed Changes dist.ini > [@Git/Tag] Tagged v0.12 > [@Git/Push] pushing to origin > > No error messages were output. Nor did it ask for my github > authentication details. It just hangs indefinitely (or is that > information meant to go in some file?). In the end I had to kill the > process and push it manually.
I've had the same problem for a while now. Typically, I open another terminal in that directory, do a manual 'git push --tags origin master', then kill the ssh connection that hung with 'ssh git@github.com -Oexit'. I'm actually glad to hear I'm not alone, as I was wondering whether my ssh config was causing this problem. That seemed unlikely, since it hasn't changed in ages, but I figured I would have heard if other people were having problems with such a commonly-used Dist::Zilla plugin. And here we are :)
I've never encountered this before. It's basically just doing system("git push origin") followed by system("git push --tags origin") except that it uses Git::Wrapper, not system. Does "git push origin" prompt you for a password when you type it in a shell? I'm not sure Git::Wrapper handles that. What version of Git are you using? What version of Git::Wrapper? What OS?
On Mon Aug 26 22:03:47 2013, CJM wrote: Show quoted text
> Does "git push origin" prompt you for a password when you type it in a > shell? I'm not sure Git::Wrapper handles that.
On my system, if a passphrase is required, it'll be a graphical prompt. However, this hangs both after prompting for a passphrase, and not (the key is already decrypted). Moreover, there is sometimes a master SSH connection already open to the server, and it still hangs. As I mentioned, my current workaround is to simply open a new terminal to do the push, and then kill the SSH connection -- so, clearly, git can actually push, it just isn't doing so. Is there a way to get some debugging data from Git::Wrapper? Show quoted text
> What version of Git are you using? What version of Git::Wrapper? > What OS?
git is 1.8.3.4, on Ubuntu 13.04. Git::Wrapper is 0.030.
You can try "dzil release -v Git::Push" (where Git::Push is whatever appears between the brackets at the start of the "pushing to ..." message (mine says [CJM/@Git/Push]). But it doesn't log anything until Git exits, so you'd still have to kill the stuck ssh process. What does "git config push.default" say? It might be getting confused by the complaint about that not being set. (See http://article.gmane.org/gmane.linux.kernel/1496493 ).
I've had this for a while too. The Change log for Devel::Cover also mentions this issue. On Mon Aug 26 22:03:47 2013, CJM wrote: Show quoted text
> I've never encountered this before. It's basically just doing > system("git push origin") followed by system("git push --tags origin") > except that it uses Git::Wrapper, not system. > > Does "git push origin" prompt you for a password when you type it in a > shell? I'm not sure Git::Wrapper handles that.
I've been using TortoiseGit to push, which does prompt for a username and password. Show quoted text
> What version of Git are you using? What version of Git::Wrapper? > What OS?
OS is Windows 7 Git is MSysGit 1.8.3 Git::Wrapper is 0.029 push.default isn't set. Will let you know if that fixes it, though this issue was around before 1.8.3.
Setting push.default did fix the issue. I now get prompted for github username and password and it doesn't hang. I'll probably log a bug against Git::Wrapper to warn us about this. On Tue Aug 27 03:01:35 2013, STEVENL wrote: Show quoted text
> I've had this for a while too. The Change log for Devel::Cover also > mentions this issue. > > On Mon Aug 26 22:03:47 2013, CJM wrote:
> > I've never encountered this before. It's basically just doing > > system("git push origin") followed by system("git push --tags > > origin") > > except that it uses Git::Wrapper, not system. > > > > Does "git push origin" prompt you for a password when you type it in > > a > > shell? I'm not sure Git::Wrapper handles that.
> > I've been using TortoiseGit to push, which does prompt for a username > and password. >
> > What version of Git are you using? What version of Git::Wrapper? > > What OS?
> > OS is Windows 7 > Git is MSysGit 1.8.3 > Git::Wrapper is 0.029 > > push.default isn't set. Will let you know if that fixes it, though > this issue was around before 1.8.3.
On Mon Aug 26 22:50:14 2013, CJM wrote: Show quoted text
> What does "git config push.default" say? It might be getting confused > by the complaint about that not being set. (See > http://article.gmane.org/gmane.linux.kernel/1496493 ).
I checked that push.default is set (to "simple") prior to doing a release. The push hung. I didn't ask for verbose logging - I'll try to remember for next time.
On Tue Nov 12 01:07:38 2013, DOHERTY wrote: Show quoted text
> On Mon Aug 26 22:50:14 2013, CJM wrote:
> > What does "git config push.default" say? It might be getting > > confused > > by the complaint about that not being set. (See > > http://article.gmane.org/gmane.linux.kernel/1496493 ).
> > I checked that push.default is set (to "simple") prior to doing a > release. The push hung. I didn't ask for verbose logging - I'll try to > remember for next time.
I asked for verbose logging and your plugin doesn't log anything extra when you do that, so I'm not going to bother providing the output. I should also ask, why would push.default matter? That is the default for when you don't provide a refspec to push. Surely this plugin should be specifying that, no?
I have push.default set to "simple", and pushing still hangs. This time, I watched the processes in htop, and saw that a git push was spawned. When it exited, the ssh connection hangs around in another process that gets reparented to init. Another git process gets created, which more or less immediately becomes a zombie. After killing the ssh process that is keeping the connection open, the hung git process is reaped. The push is then retried a second time. This is done for every remote dzil pushes to. I will try to get strace output for you next time.