Eli Zaretskii wrote:
quoted text
>> Date: Mon, 15 Oct 2007 00:14:46 +0200
>> From: Alex Riesen <raa.lkml@gmail.com>
>> Cc: Andreas Ericsson <ae@op5.se>, Benoit SIGOURE <tsuna@lrde.epita.fr>,
>> 	git list <git@vger.kernel.org>, Eli Zaretskii <eliz@gnu.org>,
>> 	Make Windows <make-w32@gnu.org>
>>
>> Re "functional". Have to remind something (besides the fork):
> 
> That's a 20-20 hindsight: if you deliberately write a program to rely
> heavily on Posix-isms, don't be surprised when you discover that it
> cannot be easily ported to other platforms.
> 

True. It was originally developed because Linux kernel development came
to a stand-still and needed an scm quickly. Since the original design
worked out nicely, nobody bothered (then) about possible future porting
issues. Windows is still a second class citizen, but that's true for
pretty much every unix-born application out there, so I'm not all that
stressed out about it.

quoted text
> 
>> - no proper filename semantics (case-insensitivity and stupid rules for
>>   allowed characters in filenames, like ":" in filenames in
>>   cross-platform projects)
> 
> There's a flag on Windows to open files case-sensitively, if you need
> that.  In any case, I don't see how this can be of any real relevance
> to porting GIT.


Because having

	Path/foo
	path/Foo
	PATH
	path/foo

is possible in git's native playground, but not on windows, so it can
quite seriously hamper cross-platform cooperation. When that happens,
users usually start blaming the tools in use. Browse the list archives
for HFS and you'll see what I mean, although come to think of it, the
HFS problems might actually be worse, since HFS reports case-changes
while not actually being case-sensitive.


quoted text
>  As for ":" in file names, simply don't use it, like
> you don't use white space or characters below 32 decimal: it's
> inconvenient, even if it's allowed.
> 

It's still a real problem because sooner or later someone will use that,
and it needs to be handled with a bit more grace than just bombing out.

quoted text
> 
>> - no real "mmap" (which kills perfomance and complicates code)
> 
> You only need mmap because you are accustomed to use it on GNU/Linux.
> 

Not really. mmap() provides a real performance boost when reading large
repos, due to the sliding window code that handles pack-files. mmap
was invented for occasions like that, and was allowed to endure because
it was a much better solution than simply read(fd, buf, st.st_size) and
moving pointers around.


quoted text
>> Interprocess communication:
>>
>> - no reliable text environment (I'm programming in the damn thing for
>>   10 years and I still don't know how to pass an environment variable
>>   _for_sure_)
>>
>> - it has only one argument (limited in size) passed to started
>>   programs, which means that there is no possible way to safely pass
>>   file and text arguments on command line (more than one, that is)
> 
> Not enough context, so I cannot talk intelligently about this.  Why do
> you need interprocess communication in the first place?


Because some of the commands operate on large data-sets that are best
passed as a stream. It's ridiculously easy to set that up on unix, but
(afaiu) quite troublesome under windows.


quoted text
> why not simply
> give birth to a subsidiary process and pass it a command line (which
> can be up to 32KB)?

I believe work is in progress that will run things as threads rather
than using fork()+execve(). 32KiB of data is nowhere near enough to
sustain many of the more data-hungry commands. Or rather, it won't be
once the repository has grown passed 50-odd revisions.


All that being said, welcome to the git mailing list. Hopefully you
can help iron out the wrinkles on windows. You seem to have a fairly
good grasp of what's available there, and I'm sure the msys team would
be pretty happy to get a few patches to speed them on their way.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html