git on 64bit windows - state of the art?

git on 64bit windows - state of the art?

[Jon Seymour]

Hi,

I was wondering what the state of the art for running git on 64 bit Windows is?

I haven't tried it myself - my Windows VMs are 32bit - but colleagues
are reporting persistent problems with the cygwin build because of
(cygwin) rebasing issues [ the issue most often reveals itself as a
failure to fork subprocesses while executing git svn ]

We have tried to use cygwin's rebaseall to address the issue per the
advice on stackoverflow.com amongst other places, but this "solution"
doesn't seem to produce permanent results (even if the installed
cygwin code base remains stable). We tried msysgit to see if this
provided any relief, but it had similar issues (perhaps because cygwin
was also active at the time - I haven't had a chance to diagnose this
particular more thoroughly yet).

Has anyone got a recipe that provides a permanent and stable solution
to the (cygwin) 32/64bit rebasing issues?

jon.

Re: git on 64bit windows - state of the art?

[Erik Faye-Lund]

On Tue, Jun 19, 2012 at 10:40 AM, Jon Seymour <jon.seymour@gmail.com> wrote:
> Hi,
>
> I was wondering what the state of the art for running git on 64 bit Windows is?

Git for Windows. That goes both for 32 and 64-bit Windows.

> We tried msysgit to see if this
> provided any relief, but it had similar issues (perhaps because cygwin
> was also active at the time - I haven't had a chance to diagnose this
> particular more thoroughly yet).
>

I'm running Git for Windows (msysgit is the development environment
for Git for Windows) on all my development-systems (which are all
64-bit) without any rebase-problems. I do not have Cygwin installed,
though.

Git for Windows is pretty heavily tested on 64-bit.

Re: git on 64bit windows - state of the art?

[Philippe Vaucher]

> I was wondering what the state of the art for running git on 64 bit Windows is?

Did they try msysgit? In my experience it has way less issues than cygwin.

Philippe

Re: git on 64bit windows - state of the art?

[Jon Seymour]

On Tue, Jun 19, 2012 at 6:59 PM, Philippe Vaucher
<philippe.vaucher@gmail.com> wrote:
>> I was wondering what the state of the art for running git on 64 bit Windows is?
>
> Did they try msysgit? In my experience it has way less issues than cygwin.
>
> Philippe

Erik and Philippe,

Thanks for the quick responses. I'll take cygwin out of the picture
completely and see if that improves things.

I was hoping to use cygwin because I don't like the (understandable)
limitations of the msysgit toolset (restricted set of available tools,
invoking bat files is painful, symbolic links don't work the same way,
etc)

jon.

Re: git on 64bit windows - state of the art?

[Philippe Vaucher]

> I was hoping to use cygwin because I don't like the (understandable)
> limitations of the msysgit toolset (restricted set of available tools,
> invoking bat files is painful, symbolic links don't work the same way,
> etc)

There's a git bash with msysgit which is probably more limited than
cygwin's one but decent enough. About the tools you can install
something like https://github.com/bmatzelle/gow/wiki or
http://gnuwin32.sourceforge.net.

To be honest most of the time I just use the *nix tools from the
windows command line, and jump into git bash for more advanced stuffs
when necessary.

Philippe

Re: git on 64bit windows - state of the art?

[Jon Seymour]

On Tue, Jun 19, 2012 at 7:28 PM, Philippe Vaucher
<philippe.vaucher@gmail.com> wrote:
>> I was hoping to use cygwin because I don't like the (understandable)
>> limitations of the msysgit toolset (restricted set of available tools,
>> invoking bat files is painful, symbolic links don't work the same way,
>> etc)
>
> There's a git bash with msysgit which is probably more limited than
> cygwin's one but decent enough. About the tools you can install
> something like https://github.com/bmatzelle/gow/wiki or
> http://gnuwin32.sourceforge.net.

Yes, I have tried the msysgit bash which is ok, except for the
annoyances mentioned. Thanks for the additional links, which I shall
peruse.

>
> To be honest most of the time I just use the *nix tools from the
> windows command line, and jump into git bash for more advanced stuffs
> when necessary.
>

I do like my bash  and have got used to the way cygwin handles "the divide".

jon.

Re: git on 64bit windows - state of the art?

[Jon Seymour]

Would I be correct in assuming that Git For Windows doesn't support
"git svn" because of the dependency on a perl implementation that is
available with msysgit but not (perhaps?) "Git For Windows"? Or is
this an incorrect assumption?

jon.

Re: git on 64bit windows - state of the art?

[Erik Faye-Lund]

On Tue, Jun 19, 2012 at 11:57 AM, Jon Seymour <jon.seymour@gmail.com> wrote:
> Would I be correct in assuming that Git For Windows doesn't support
> "git svn" because of the dependency on a perl implementation that is
> available with msysgit but not (perhaps?) "Git For Windows"? Or is
> this an incorrect assumption?

That's an incorrect assumption. Git for Windows ships with perl.

Re: git on 64bit windows - state of the art?

[Pascal Obry]

Jon,

This is a known issue. I have since a long time left Windows world but I
still have some notes to "fix" this:

>From the ash shell (be sure that no Cygwin process are still running):

$ rebaseall
$ peflagsall

Try your command again. If it still doesn't work, try instead:
$ rebaseall -b 0x50000000 -o 0x80000
or -b 0xNNNN0000 where NNNN is any hex number between 2000 and 7000.
The -o option tell to leave more space between the dlls, it may also
help. It did in my case.

If you are curious, look at /usr/share/doc/Cygwin/rebase-3.0.README
for more explanation.


Hope this helps.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|    http://www.obry.net  -  http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: git on 64bit windows - state of the art?

[Jon Seymour]

On Wed, Jun 20, 2012 at 5:16 AM, Pascal Obry <pascal@obry.net> wrote:
> Jon,
>
> This is a known issue. I have since a long time left Windows world but I
> still have some notes to "fix" this:
>
> From the ash shell (be sure that no Cygwin process are still running):
>
> $ rebaseall
> $ peflagsall
>
> Try your command again. If it still doesn't work, try instead:
> $ rebaseall -b 0x50000000 -o 0x80000
> or -b 0xNNNN0000 where NNNN is any hex number between 2000 and 7000.
> The -o option tell to leave more space between the dlls, it may also
> help. It did in my case.
>
> If you are curious, look at /usr/share/doc/Cygwin/rebase-3.0.README
> for more explanation.
>
>
> Hope this helps.
>
> Pascal.

Thank you. I think we have tried the -b option without much luck, but
I don't think we have tried the -o option.

I will arrange to do some testing and will post to the list in a few
weeks if this looks to be a definitive solution to the problem (or
otherwise)

jon.

Re: git on 64bit windows - state of the art?

[Pascal Obry]

Jon,

> Thank you. I think we have tried the -b option without much luck, but
> I don't think we have tried the -o option.
> 
> I will arrange to do some testing and will post to the list in a few
> weeks if this looks to be a definitive solution to the problem (or
> otherwise)

Ok, the most important part is running peflagsall, this was the way to
fix that properly on Win7 IIRC.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|    http://www.obry.net  -  http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: git on 64bit windows - state of the art?

[Jon Seymour]

On Thu, Jun 21, 2012 at 11:40 AM, Paul Harris <harris.pc@gmail.com> wrote:
>
>
> On 20 June 2012 14:57, Pascal Obry <pascal@obry.net> wrote:
>>
>> Jon,
>>
>> > Thank you. I think we have tried the -b option without much luck, but
>> > I don't think we have tried the -o option.
>> >
>> > I will arrange to do some testing and will post to the list in a few
>> > weeks if this looks to be a definitive solution to the problem (or
>> > otherwise)
>>
>> Ok, the most important part is running peflagsall, this was the way to
>> fix that properly on Win7 IIRC.
>>
>> Pascal.
>>
>
> Hello,
>
> I use git + cygwin on Win7-64 (almost) without problems.  I have used
> git-svn too (once) with success.

We do use git svn fairly heavily as part of our normal workflow and it
is git-svn that is most heavily affected by the issue. If you only use
git-svn occasionally, it is possible that you have avoided the
particular issue we are facing. For us, git-svn does tend to work
immediately after the rebase or after a fresh boot when not much is
loaded, but the reliability will be tend to degrade over time,
presumably as the 32bit address space becomes more "polluted" by the
other demands placed upon it.

>
> Perhaps Jon's is not working because rebaseall is not rebasing the
> particular binaries he is using?  Perhaps his git svn is running some
> binaries/dlls that are installed in non-standard locations?  Can that
> happen?

I don't think this is the case. All the users affected have a pretty
standard scripted cygwin install - there are no variations between
users and no special considerations for the SVN installation. We tried
some of the suggestions we found here about explicitly enumerating all
the .so and .dll files

      http://stackoverflow.com/questions/4988091/unable-to-start-solr-server-ruby-on-rails/6601464#6601464

but this didn't change the behaviour.

I suspect the flavour of anti-virus solution one has installed may be
a factor. We are using Norton Antivirus.

Another factor might be the other tools we are running (Java IDEs and
application servers) although I haven't seen any good evidence one way
or the other about whether the JVMs are actually a factor. As
mentioned above, It does seem true that time since reboot is a factor,
which is presumably related to how the 32bit address space is
"fragmented" over time by the various demands placed on it.

Thus far, Pascal's solution seems to be working, but it is a bit early
to call it a success yet - we will need several more days testing to
be sure.

jon.