that's really a patch :)
but no choice..
I create a post on java.net Hope to get more feedback, to get this problem
solve soon.
Unix users are making fun of us :)
Tomás Staig wrote:
>
> survivant wrote:
>> Does anyone one have an answer for this problem ? (I saw lot of threads
>> in
>> di
survivant wrote:
Does anyone one have an answer for this problem ? (I saw lot of threads in
different forums.. but never an answer.)
I'm trying to clone a repository from my computer to my computer. I,m using
cygwin 1.7. I,m able to clone all my others projects without problems.
This projec
Does anyone one have an answer for this problem ? (I saw lot of threads in
different forums.. but never an answer.)
I'm trying to clone a repository from my computer to my computer. I,m using
cygwin 1.7. I,m able to clone all my others projects without problems.
This project is 900k.. and th
On 9/27/2010 7:03 PM, Christopher Faylor wrote:
Christopher, I did have a question on the old thread that went
un-answered. I was wondering exactly what process you used to
determine that it was git that was having a stack issue. It would be
helpful as a starting point for a developer to try a
On Mon, Sep 27, 2010 at 05:56:04PM -0400, Bill Hoffman wrote:
>On 9/27/2010 3:59 PM, Christopher Faylor wrote:
>>And, when I tried this, it pointed to an actual problem in git rather
>>than a problem in Cygwin so that limits what is meant by "developer".
>>
>>Isn't git normally used for source cont
On 9/27/2010 3:59 PM, Christopher Faylor wrote:
And, when I tried this, it pointed to an actual problem in git rather than
a problem in Cygwin so that limits what is meant by "developer".
Isn't git normally used for source control management by programmers?
If this is such a bad problem why is
On Mon, Sep 27, 2010 at 02:24:05PM -0400, Bill Hoffman wrote:
>On 9/27/2010 12:38 PM, Kevin Layer wrote:
>> Eric Blake wrote:
>>
On 03/11/2010 04:03 PM, Charles Wilson wrote:
>> If it is not being worked on... I agree with Brian. This is a serious
>> impediment to using Cygwin 1.7.
On 9/27/2010 12:38 PM, Kevin Layer wrote:
Eric Blake wrote:
On 03/11/2010 04:03 PM, Charles Wilson wrote:
If it is not being worked on... I agree with Brian. This is a serious
impediment to using Cygwin 1.7. I would think it would be of top
priority.
Only people who experience the problem
Eric Blake wrote:
>> On 03/11/2010 04:03 PM, Charles Wilson wrote:
>> >> If it is not being worked on... I agree with Brian. This is a serious
>> >> impediment to using Cygwin 1.7. I would think it would be of top
>> >> priority.
>> >
>> > Only people who experience the problem can diagnose, d
The problem still exists but it appears infrequently with small repos. But
larger repositories constantly fail even with the environment variable below
defined. I currently use the putty ssh client for git. Nevertheless I
consider this a major issue since the ssh protocol is the most important use
On 4/7/2010 5:12 AM, nothize wrote:
> After I've replaced(or removed!) %windir%\system32\cygz.dll with the newer
> one in Cygwin, git 1.7.0.4 worked well. Perhaps I've manually copied an
> older cygz.dll to there sometimes ago.I can't remember.
The Cygwin setup program never installs files int
Hi Brian,
I had the same issue, lets see if my cause is your cause too.
After I've replaced(or removed!) %windir%\system32\cygz.dll with the newer
one in Cygwin, git 1.7.0.4 worked well. Perhaps I've manually copied an
older cygz.dll to there sometimes ago.I can't remember.
Some sub-command
On 03/11/2010 04:03 PM, Charles Wilson wrote:
>> If it is not being worked on... I agree with Brian. This is a serious
>> impediment to using Cygwin 1.7. I would think it would be of top
>> priority.
>
> Only people who experience the problem can diagnose, debug, and fix it.
> git works fine for
Kevin Layer wrote:
> Brian L. wrote:
>>> It's clearly affecting more than a few users and the workaround, while
>>> reliable, is quite lame. Can this please get a little bit more
>>> priority?
>
> and another month goes by...
>
> If there is work going on behind the scenes, it would be nice to he
On 3/11/2010 1:50 PM, Kevin Layer wrote:
Brian L. wrote:
From this thread I gather that little or no progress has been made on
addressing the root cause of this issue. It still seems to be broken
with the latest 1.7 series packages.
What is the proper method for getting this bug in front of
Brian L. wrote:
>> From this thread I gather that little or no progress has been made on
>> addressing the root cause of this issue. It still seems to be broken
>> with the latest 1.7 series packages.
>>
>> What is the proper method for getting this bug in front of the guys
>> who maintain the o
I ran into the same problem today. After looking at
http://gitdiscoveries.wordpress.com/2010/02/21/git-and-cygwin-part-2/, I
tried installing GIT 1.7.0 from source, but same as the author, it did not
fix the problem either, so I'm guessing that the rest of the people in this
thread are right, and
From this thread I gather that little or no progress has been made on
addressing the root cause of this issue. It still seems to be broken
with the latest 1.7 series packages.
What is the proper method for getting this bug in front of the guys
who maintain the openssh package? The cygwin website s
alland wrote:
I have the same issue trying to clone a repo with a recently updated cygwin.
The problem is not present in any other configurations I tried to clone
with, including git/ssh built for MSys on the same computer.
I can confirm the problems myself (cygwin 1.7.1, git 1.6.6.1). Also,
I have the same issue trying to clone a repo with a recently updated cygwin.
The problem is not present in any other configurations I tried to clone
with, including git/ssh built for MSys on the same computer.
--
View this message in context:
http://old.nabble.com/git-stopped-working-with-1.7.1
On Jan 18 00:17, ol42 wrote:
>
> But obviously the environment variable has still an effect!
> Without binmode I get the following error >
>
> $ git clone ssh://o...@simulacron/home/git/gen-dsp.git
> Initialized empty Git repository in /home/ol/tmp/gen-dsp/.git/
> remote: Counting objects: 9
But obviously the environment variable has still an effect!
Without binmode I get the following error >
$ git clone ssh://o...@simulacron/home/git/gen-dsp.git
Initialized empty Git repository in /home/ol/tmp/gen-dsp/.git/
remote: Counting objects: 979, done.
remote: Compressing objects: 100%
On 1/16/2010 9:44 AM, ol42 wrote:
CYGWIN=binmode
This is obsolete. See
http://www.cygwin.com/cygwin-ug-net/using-cygwinenv.html#cygwinenv-implemented-options
Ken
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: htt
other versions of SSH work with the 1.7 git, I would
> think this is pretty good evidence that it's a bug in cygwin1.dll.
>
> Date: Thu, 31 Dec 2009 14:04:16 -0500
> Message-ID:
> <6ee4c8380912311104i1869d73dk818e041f2d8b2...@mail.gmail.com>
> Subject: Re: git stoppe
od evidence that it's a bug in cygwin1.dll.
Date: Thu, 31 Dec 2009 14:04:16 -0500
Message-ID: <6ee4c8380912311104i1869d73dk818e041f2d8b2...@mail.gmail.com>
Subject: Re: git stopped working with 1.7.1
From: "Brian L."
To: cygwin@cygwin.com
...
The problem
Eric Blake wrote:
>> According to Kevin Layer on 1/8/2010 11:01 AM:
>> > Has anyone in the cygwin group reproduced this?
>>
>> Yes, as maintainer of the git package on cygwin, I've seen sporadic
>> failures of the git protocol, which I have always ended up working around
>> by switching over to
According to Kevin Layer on 1/8/2010 11:01 AM:
> Has anyone in the cygwin group reproduced this?
Yes, as maintainer of the git package on cygwin, I've seen sporadic
failures of the git protocol, which I have always ended up working around
by switching over to an http protocol. I'm assuming that i
Has anyone in the cygwin group reproduced this?
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
I wrote:
> Unfortunately I have no clue about how to debug it.
...
> Is going back to Cygwin 1.5 really the only solution?
Sorry, I should have read the thread more carefully before writing this,
the message from Brian L does provide a solution: using plink.exe instead
of Cygwin ssh works fine
2010/1/5 Vadim Zeitlin:
> Exactly the same thing happens here with 1.7.1 under 64-bit Windows 7.
> However my Cygwin is not a new install but an upgrade of a previous 1.5
> installation -- in which Git worked just fine.
Does the locale setting make a difference? For example, try it with
the follo
Kevin Layer franz.com> writes:
> layer hobart128 /c/tmp
> $ git clone git:/repo/git/acl acl.test
> Initialized empty Git repository in /c/tmp/acl.test/.git/
> remote: Counting objects: 9205, done.
> remote: Compressing objects: 100% (3300/3300), done.
> fatal: The remote end hung up
On Mon, Jan 4, 2010 at 15:06, Kevin Layer wrote:
> I'm not using the git protocol. Note the single slash. The machine
> is named `git', which is what is confusing you. Anything of the form
> "foo:/path" uses SSH, which is what this is using.
Yes, you're right, I'm so used to seeing git://server
Brian L. wrote:
>> I'm seeing very similar bad behavior from cygwin+git on win7 x64 as
>> well as winxp x86. This bug is not confined to 64 bit platforms. This
>> bug is new in 1.7.x--I have cygwin 1.5 installs on both of these
>> machines that do not exhibit this failure.
>>
>> The problem seem
David Antliff wrote:
>> On Thu, Dec 24, 2009 at 07:55, Kevin Layer wrote:
>> > la...@hobart128 /c/tmp
>> > $ git clone git:/repo/git/acl acl.test
>> > Initialized empty Git repository in /c/tmp/acl.test/.git/
>> > remote: Counting objects: 9205, done.
>> > remote: Compressing objects: 100%
I'm seeing very similar bad behavior from cygwin+git on win7 x64 as
well as winxp x86. This bug is not confined to 64 bit platforms. This
bug is new in 1.7.x--I have cygwin 1.5 installs on both of these
machines that do not exhibit this failure.
The problem seems to be rooted in cygwin's openssh p
On Thu, Dec 24, 2009 at 07:55, Kevin Layer wrote:
> la...@hobart128 /c/tmp
> $ git clone git:/repo/git/acl acl.test
> Initialized empty Git repository in /c/tmp/acl.test/.git/
> remote: Counting objects: 9205, done.
> remote: Compressing objects: 100% (3300/3300), done.
> fatal: The remote e
David Antliff wrote:
>> > It may be a 64-bit issue, so I'll try a 32-bit machine, if I can
>> > scrounge one up.
>>
>> We are using WinXP 32-bit and have not seen this problem (yet). It
>> would be really helpful (to me at least) to know whether you can
>> reproduce the issue with 32-bit Windows
On Mon, Dec 28, 2009 at 14:13, Kevin Layer wrote:
> This seems serious. Do people just not use cygwin git?
It sounds very serious. I am a very interested user of git on Cygwin
and I'm watching this thread with interest. However
> It may be a 64-bit issue, so I'll try a 32-bit machine, if I c
On Sun, Dec 27, 2009 at 05:13:39PM -0800, Kevin Layer wrote:
>
>
>I'm a little surprised there are *no* replies to this thread, other
>than mine. (It's not like there is no traffic on the mailing list.)
It's the holiday season. Our support staff are probably out enjoying
themselves.
cgf
--
Pro
I'm a little surprised there are *no* replies to this thread, other
than mine. (It's not like there is no traffic on the mailing list.)
Can someone tell me what I need to do to interest people in this?
Let me summarize: "git clone" fails with this:
remote: Compressing objects: 100% (3300/
I tried to install 1.6.1.2 on 1.7.1, but it didn't work. The clone
complained that the index-pack program was missing. I did the usual
./configure && make && make install
so I'm not sure what else to try.
I copied git-index-pack.exe from the build directory to
/usr/local/libexec/git
la...@hobart128 /c/tmp
$ git clone git:/repo/git/acl acl.test
Initialized empty Git repository in /c/tmp/acl.test/.git/
remote: Counting objects: 9205, done.
remote: Compressing objects: 100% (3300/3300), done.
fatal: The remote end hung up unexpectedly
fatal: early EOFs: 62% (5708/9
la...@hobart128 /c/tmp
$ git clone git:/repo/git/acl acl.test
Initialized empty Git repository in /c/tmp/acl.test/.git/
remote: Counting objects: 9205, done.
remote: Compressing objects: 100% (3300/3300), done.
fatal: The remote end hung up unexpectedly
fatal: early EOFs: 62% (5708/9
43 matches
Mail list logo
