windows problems summary

windows problems summary

[Alex Riesen]

This is just to summarize all the problems which make porting to that
thing so boring. Maybe if we have them all on one page, it'd be easier
to locate the workarounds (it can be one thread, for example).

1. opened and mmaped files can't be removed or renamed
  (caused workaround with reading index in memory)
2. command can safely contain only one argument
  (breaks and complicates passing things between processes)
3. no fork
  (slows down and complicates passing things between processes)
4. non-unix permissions model
  (breaks x-attr)
5. real slow filesystems and caching
  (makes everything slow. I noticed I'm trying to avoid git status!).
  Caused workaround with manual checkout)
6. real slow program startup
  (makes everything slow, eventually may cause everything being put
  in one super-executable, just to avoid spawning new processes,
  with all associated problems. Makes scripting harder)

I hope this message can be a start of a big porting thread,
even though it is only about windows at the moment.

Alex Riesen

Re: windows problems summary

[Christopher Faylor]

On Thu, Mar 02, 2006 at 03:49:24PM +0100, Alex Riesen wrote:
>This is just to summarize all the problems which make porting to that
>thing so boring. Maybe if we have them all on one page, it'd be easier
>to locate the workarounds (it can be one thread, for example).
>
>1. opened and mmaped files can't be removed or renamed
>  (caused workaround with reading index in memory)
>2. command can safely contain only one argument
>  (breaks and complicates passing things between processes)
>3. no fork
>  (slows down and complicates passing things between processes)
>4. non-unix permissions model
>  (breaks x-attr)
>5. real slow filesystems and caching
>  (makes everything slow. I noticed I'm trying to avoid git status!).
>  Caused workaround with manual checkout)
>6. real slow program startup
>  (makes everything slow, eventually may cause everything being put
>  in one super-executable, just to avoid spawning new processes,
>  with all associated problems. Makes scripting harder)
>
>I hope this message can be a start of a big porting thread,
>even though it is only about windows at the moment.

Are we *really* contemplating porting git to native Windows?

I guess I missed that memo.

cgf

Re: windows problems summary

[Alex Riesen]

On 3/2/06, Christopher Faylor <me@cgf.cx> wrote:
>
> Are we *really* contemplating porting git to native Windows?
>

Actually, I wasn't thinking about that when I was writing that mail,
but ... why not?
Cygwin makes syscalls many times slower, git is very slow on
windows, users (well, I) want it faster, so if the needed api subset
can be narrowed down to a reasonable amount of work - I think
I'd give the idea a try.

Re: windows problems summary

[Bertrand Jacquin]

On 3/2/06, Alex Riesen <raa.lkml@gmail.com> wrote:
> On 3/2/06, Christopher Faylor <me@cgf.cx> wrote:
> >
> > Are we *really* contemplating porting git to native Windows?
> >
>
> Actually, I wasn't thinking about that when I was writing that mail,
> but ... why not?
> Cygwin makes syscalls many times slower, git is very slow on
> windows, users (well, I) want it faster, so if the needed api subset
> can be narrowed down to a reasonable amount of work - I think
> I'd give the idea a try.

Is the goal to have something like a git-turtoise (as {svn,cvs}-turtoise) ?
I personaly think that is could be benefic.

--
Beber
#e.fr@freenode

Re: windows problems summary

[Alex Riesen]

Bertrand Jacquin, Thu, Mar 02, 2006 16:57:42 +0100:
> 
> Is the goal to have something like a git-turtoise (as {svn,cvs}-turtoise) ?
> I personaly think that is could be benefic.
> 

Not in the original post.
It just about making git faster and more stable in Windows.

Re: windows problems summary

[Christopher Faylor]

On Thu, Mar 02, 2006 at 08:54:50PM +0100, Alex Riesen wrote:
>Bertrand Jacquin, Thu, Mar 02, 2006 16:57:42 +0100:
>>Is the goal to have something like a git-turtoise (as
>>{svn,cvs}-turtoise) ?  I personaly think that is could be benefic.
>
>Not in the original post.  It just about making git faster and more
>stable in Windows.

Can I request that people stop cc'ing me in this thread?

I'd like to cut down on the blood pressure medication if I can.

cgf

Re: windows problems summary

[Andreas Ericsson]

Christopher Faylor wrote:
> On Thu, Mar 02, 2006 at 08:54:50PM +0100, Alex Riesen wrote:
> 
>>Bertrand Jacquin, Thu, Mar 02, 2006 16:57:42 +0100:
>>
>>>Is the goal to have something like a git-turtoise (as
>>>{svn,cvs}-turtoise) ?  I personaly think that is could be benefic.
>>
>>Not in the original post.  It just about making git faster and more
>>stable in Windows.
> 
> 
> Can I request that people stop cc'ing me in this thread?
> 

That's most likely because people hit "reply all" so the reply goes to 
the list as well. A "normal" reply would go only to you.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: windows problems summary

[Andreas Ericsson]

Alex Riesen wrote:
> On 3/2/06, Christopher Faylor <me@cgf.cx> wrote:
> 
>>Are we *really* contemplating porting git to native Windows?
>>
> 
> 
> Actually, I wasn't thinking about that when I was writing that mail,
> but ... why not?


For the same reason we don't support Perl 5.4. It's too much effort for 
too little gain. OTOH, if you want to do the effort, I won't mind taking 
the gain. ;)

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: windows problems summary

[Alex Riesen]

On 3/2/06, Andreas Ericsson <ae@op5.se> wrote:
> >>Are we *really* contemplating porting git to native Windows?
> >
> > Actually, I wasn't thinking about that when I was writing that mail,
> > but ... why not?
>
> For the same reason we don't support Perl 5.4. It's too much effort for
> too little gain. OTOH, if you want to do the effort, I won't mind taking
> the gain. ;)

I don't care. I just have nothing for you to gain from yet.

Re: windows problems summary

[Shawn Pearce]

Alex Riesen <raa.lkml@gmail.com> wrote:
> On 3/2/06, Christopher Faylor <me@cgf.cx> wrote:
> >
> > Are we *really* contemplating porting git to native Windows?
> >
> 
> Actually, I wasn't thinking about that when I was writing that mail,
> but ... why not?
> Cygwin makes syscalls many times slower, git is very slow on
> windows, users (well, I) want it faster, so if the needed api subset
> can be narrowed down to a reasonable amount of work - I think
> I'd give the idea a try.

I'd certainly appreciate faster response times from GIT on Windows.
Hell, I'd port GIT myself and cross my fingers that Junio, et. al.
would be open to accepting the changes into the tree.

But right now I don't really have a Windows development environment
available to me that I can hack on releasable changes from (damn
lawyers and those agreements about things on work computers being
owned by work).  If I get time I'll try rebuilding a system at
home that is currently offline due to failed disk as a Windows
development environment.

-- 
Shawn.

Re: windows problems summary

[Johannes Schindelin]

Hi,

On Thu, 2 Mar 2006, Alex Riesen wrote:

> 1. opened and mmaped files can't be removed or renamed
>   (caused workaround with reading index in memory)

It was not the locking which caused the workaround. It was the 
not-working. (I still have to find a Windows machine where git-whatchanged 
does not segfault without NO_MMAP.)

> 2. command can safely contain only one argument
>   (breaks and complicates passing things between processes)
> 3. no fork
>   (slows down and complicates passing things between processes)
> 4. non-unix permissions model
>   (breaks x-attr)
> 5. real slow filesystems and caching
>   (makes everything slow. I noticed I'm trying to avoid git status!).
>   Caused workaround with manual checkout)
> 6. real slow program startup
>   (makes everything slow, eventually may cause everything being put
>   in one super-executable, just to avoid spawning new processes,
>   with all associated problems. Makes scripting harder)

Except for (4), these issues should be resolvable by the libifying effort.

Ciao,
Dscho

Re: windows problems summary

[Alex Riesen]

On 3/2/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > 1. opened and mmaped files can't be removed or renamed
> >   (caused workaround with reading index in memory)
>
> It was not the locking which caused the workaround. It was the
> not-working. (I still have to find a Windows machine where git-whatchanged
> does not segfault without NO_MMAP.)

me too. It crashes everywhere here.

> > 4. non-unix permissions model
> >   (breaks x-attr)
> > 5. real slow filesystems and caching
> >   (makes everything slow. I noticed I'm trying to avoid git status!).
> >   Caused workaround with manual checkout)
> > 6. real slow program startup
> >   (makes everything slow, eventually may cause everything being put
> >   in one super-executable, just to avoid spawning new processes,
> >   with all associated problems. Makes scripting harder)
>
> Except for (4), these issues should be resolvable by the libifying effort.
>

How can it help with 5? Less accesses to index?

Re: windows problems summary

[Johannes Schindelin]

Hi,

On Thu, 2 Mar 2006, Alex Riesen wrote:

> On 3/2/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >
> > > 1. opened and mmaped files can't be removed or renamed
> > >   (caused workaround with reading index in memory)
> >
> > It was not the locking which caused the workaround. It was the
> > not-working. (I still have to find a Windows machine where git-whatchanged
> > does not segfault without NO_MMAP.)
> 
> me too. It crashes everywhere here.
> 
> > > 4. non-unix permissions model
> > >   (breaks x-attr)
> > > 5. real slow filesystems and caching
> > >   (makes everything slow. I noticed I'm trying to avoid git status!).
> > >   Caused workaround with manual checkout)
> > > 6. real slow program startup
> > >   (makes everything slow, eventually may cause everything being put
> > >   in one super-executable, just to avoid spawning new processes,
> > >   with all associated problems. Makes scripting harder)
> >
> > Except for (4), these issues should be resolvable by the libifying effort.
> >
> 
> How can it help with 5? Less accesses to index?

Exactly.

Ciao,
Dscho

Re: windows problems summary

[Eric W. Biederman]

"Alex Riesen" <raa.lkml@gmail.com> writes:

> This is just to summarize all the problems which make porting to that
> thing so boring. Maybe if we have them all on one page, it'd be easier
> to locate the workarounds (it can be one thread, for example).
>
> 1. opened and mmaped files can't be removed or renamed
>   (caused workaround with reading index in memory)
> 2. command can safely contain only one argument
>   (breaks and complicates passing things between processes)
> 3. no fork
>   (slows down and complicates passing things between processes)
> 4. non-unix permissions model
>   (breaks x-attr)
> 5. real slow filesystems and caching
>   (makes everything slow. I noticed I'm trying to avoid git status!).
>   Caused workaround with manual checkout)
> 6. real slow program startup
>   (makes everything slow, eventually may cause everything being put
>   in one super-executable, just to avoid spawning new processes,
>   with all associated problems. Makes scripting harder)
>
> I hope this message can be a start of a big porting thread,
> even though it is only about windows at the moment.

Not to forget make install gets confused when there
is a file named INSTALL in the git directory.

Eric