Eli Zaretskii wrote:
Date: Mon, 15 Oct 2007 00:14:46 +0200
From: Alex Riesen <raa.lkml@xxxxxxxxx>
Cc: Andreas Ericsson <ae@xxxxxx>, Benoit SIGOURE <tsuna@xxxxxxxxxxxxx>,
git list <git@xxxxxxxxxxxxxxx>, Eli Zaretskii <eliz@xxxxxxx>,
Make Windows <make-w32@xxxxxxx>
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 andreas.ericsson@xxxxxx
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
