Subject: Re: Switching from CVS to GIT

From: Andreas Ericsson <[email-masked]>
Date: Mon, 15 Oct 2007 01:55:56 +0200

Eli Zaretskii wrote:
>> Date: Mon, 15 Oct 2007 00:14:46 +0200
>> From: Alex Riesen <[email-masked]>
>> Cc: Andreas Ericsson <[email-masked]>, Benoit SIGOURE <[email-masked]>,
>> 	git list <[email-masked]>, Eli Zaretskii <[email-masked]>,
>> 	Make Windows <[email-masked]>
>>
>> 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.

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

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

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

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

> 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                   [email-masked]
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231