Re: Switching from CVS to GIT

[Andreas Ericsson]

Eli Zaretskii wrote:
> > Date: Mon, 15 Oct 2007 00:14:46 +0200
> > From: Alex Riesen <address@hidden>
> > Cc: Andreas Ericsson <address@hidden>, Benoit SIGOURE <address@hidden>,
> >         git list <address@hidden>, Eli Zaretskii <address@hidden>,
> >         Make Windows <address@hidden>
> >
> > 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                   address@hidden
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231