Re: [PATCH] fmt-merge-msg: avoid open "-|" list form for Perl 5.6

On Thu, Mar 02, 2006 at 03:10:30PM +0100, Alex Riesen wrote:

Christopher, I'm terribly sorry for the long delays,
but that is something I can't change at this moment.

On 2/26/06, Christopher Faylor [off-list ref] wrote:

quoted

quoted

quoted

quoted

It's not activestate perl actually.  It's only one platform it also
_has_ to support.  Is it worth supporting Windows?

With or without cygwin?  With cygwin, I'd say "yes, unless it makes
things terribly difficult to maintain and so long as we don't take
performance hits on unices".  Without cygwin, I'd say "What?  It runs
on windows?".

There not much difference with or without cygwin.  The penalties of
doing any kind of support for it will pile up (as they started to do
with pipes).  Someday we'll have to start dropping features on Windows
or restrict them beyond their usefullness.  The fork emulation in
cygwin isn't perfect,

If the speed of cygwin's fork is an issue then I'd previously suggested
using spawn*.  The spawn family of functions were designed to emulate
Windows functions of the same name.  They start a new process without
the requirement of forking.

The effort of porting git to spawn-like interface has already started,
so there's no much left to say about the fork's speed...

quoted

quoted

signals do not work reliably (if at all),

I'm not sure if you're mixing cygwin with windows here but if signals do
not work reliably in Cygwin then that is something that we'd like to
know about.  Signals *obviously* have to work fairly well for programs
like ssh, bash, and X to work, however.

That's not enough.
Try interrupting busy processes. Like "git pull", "git clone" or make.

Are you saying that typing CTRL-C doesn't work when you use "git pull"?
If so, give me a real bug report that I can look into.  I interrupt
"busy" processes on cygwin all of the time so I'm not going to spend a
few hours typing "git pull" on my system only to find out that you are
talking about an environment that uses ActiveState perl on Windows 95
using Netware.

If you are reporting a problem you need to provide details.

quoted

Native Windows, OTOH, hardly has any signals at all and deals with
signals in a way that is only vaguely like linux.

That makes the rest of installed system kind of useless in cygwin
environment. After interrupting a build process, which uses java
(don't ask) only make stops. The rest of the process runs happily
away.

This sounds like a java bug which is entirely unrelated to git.

Now, I know that windows has no signals at all and nothing which
even closely resembles them.

Actually, Windows does understand CTRL-C and any native windows console
program should honor CTRL-C in a manner similar to UNIX, i.e., if the
program doesn't trap SIGINT with 'signal()', it will cause the program
to terminate.  There are also other mechanisms for a native windows
program to deal with CTRL-C so this really shouldn't be an issue for
any well-written program.

I wont be pressing anyone to implement them in windows, having the
knowledge.  What I'd actually suggest is to drop their implementation
entierly, returning ENOSYS,

You're not being clear again, but if you are actually promoting the
notion of cygwin not implementing signals then that is a really daft
idea.  Really.  Go to the Cygwin web site and look at all of the
packages which have been ported.  Now think about how they would work if
Cygwin didn't support signals.  bash wouldn't work, openssh, X wouldn't
work.

so that programs are not fooled into believing that the system will
work as expected.  It never will.  "Ctrl-C" in windows console is just
a shortcut to TerminateProcess, live with that.

Let me say it again since it isn't clear that you are getting it.  If
signals in a pure cygwin environment don't work then that is *a bug*.
If you are running pure windows programs in the mix with cygwin programs
then if *they* don't stop when you hit CTRL-C, that is undoubtedly a bug
in that pure windows program.

If you find that a pure windows program terminates when run from a
windows command prompt but keeps running when run by a cygwin program
then that is likely a cygwin problem that can be reported to the cygwin
mailing list.

quoted

quoted

filesystem is slow and locked down, and exec-attribute is NOT really
useful even on NTFS (it is somehow related to execute permission and
open files.  I still cannot figure out how exactly are they related).

Again, it's not clear if you're talking about Windows or Cygwin but
under Cygwin, in the default configuration, the exec attribute means
the same thing to cygwin as it does to linux.

I'm talking about git and native windows interaction:

I'd suggest that using git with native windows programs should probably
be considered "unsupported" since you seem to be having so much trouble
with it.

I cannot use umask, because I have to use stupid windows programs, and
they always create "executable" *.c and *.h, and I cannot blindly
remove it with something like "chmod -R -x", because it'd remove it
also from executables.

  find . -name '*.[ch]' | xargs chmod a-x

The poor executables lose their _rights_ to be executed (why does
cygwin use windows permissions?  They cannot correlate to unix
attributes, can they?)

Please read the Cygwin user's guide for a discussion about how file
permissions are implemented.  And, then, when you are outraged about how
unclear that documentation is please send comments and improvements to
the cygwin mailing list.

I don't see why it is appropriate to be discussing how Cygwin implements
UNIX permissions in this mailing list unless the implementation affects
git somehow.

cgf