git on 64bit windows - state of the art?

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.

On Tue, Jun 19, 2012 at 10:40 AM, Jon Seymour <jon.seymour@gmail.com> wrote:

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

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.

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

Philippe

On Tue, Jun 19, 2012 at 6:59 PM, Philippe Vaucher <philippe.vaucher@gmail.com> wrote:

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.

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

On Tue, Jun 19, 2012 at 7:28 PM, Philippe Vaucher <philippe.vaucher@gmail.com> wrote:

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

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

jon.

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.

On Tue, Jun 19, 2012 at 11:57 AM, Jon Seymour <jon.seymour@gmail.com> wrote:

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

Jon,

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

$ 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.

On Wed, Jun 20, 2012 at 5:16 AM, Pascal Obry <pascal@obry.net> wrote:

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.

Jon,

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

Pascal.

On Thu, Jun 21, 2012 at 11:40 AM, Paul Harris <harris.pc@gmail.com> wrote:

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.

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.