From: Alex Riesen <hidden> Date: 2016-06-15 22:42:20
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
From: Christopher Faylor <hidden> Date: 2016-06-15 22:42:20
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
From: Alex Riesen <hidden> Date: 2016-06-15 22:42:20
On 3/2/06, Christopher Faylor [off-list ref] 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.
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:42:20
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
On 3/2/06, Christopher Faylor [off-list ref] wrote:
quoted
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
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:42:20
Alex Riesen wrote:
On 3/2/06, Christopher Faylor [off-list ref] wrote:
quoted
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
From: Alex Riesen <hidden> Date: 2016-06-15 22:42:20
On 3/2/06, Andreas Ericsson [off-list ref] wrote:
quoted
quoted
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.
From: Alex Riesen <hidden> Date: 2016-06-15 22:42:20
On 3/2/06, Johannes Schindelin [off-list ref] wrote:
quoted
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.
quoted
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, Christopher Faylor [off-list ref] wrote:
quoted
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.
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:42:20
Hi,
On Thu, 2 Mar 2006, Alex Riesen wrote:
On 3/2/06, Johannes Schindelin [off-list ref] wrote:
quoted
quoted
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.
quoted
quoted
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.
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:42:20
Christopher Faylor wrote:
On Thu, Mar 02, 2006 at 08:54:50PM +0100, Alex Riesen wrote:
quoted
Bertrand Jacquin, Thu, Mar 02, 2006 16:57:42 +0100:
quoted
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