windows problems summary

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

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

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

> 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?
> 

> 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?

> >>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. ;)

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

> 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)

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

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

> 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?

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