* [PATCH] manpages: insert two missing [verse] markers for multi-line SYNOPSIS
From: Jonas Fonseca @ 2006-03-02 16:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Found with:
for i in *.txt; do
grep -A 2 "SYNOPSIS" "$i" | grep -q "^\[verse\]$" && continue
multiline=$(grep -A 3 "SYNOPSIS" "$i" | tail -n 1)
test -n "$multiline" && echo "$i: $multiline"
done
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
Documentation/git-repo-config.txt | 1 +
Documentation/git-svnimport.txt | 1 +
2 files changed, 2 insertions(+), 0 deletions(-)
c7336e4b19bf7683540ea4d6704c0f522067f2de
diff --git a/Documentation/git-repo-config.txt b/Documentation/git-repo-config.txt
index 33fcde4..00efde5 100644
--- a/Documentation/git-repo-config.txt
+++ b/Documentation/git-repo-config.txt
@@ -8,6 +8,7 @@ git-repo-config - Get and set options in
SYNOPSIS
--------
+[verse]
'git-repo-config' [type] name [value [value_regex]]
'git-repo-config' [type] --replace-all name [value [value_regex]]
'git-repo-config' [type] --get name [value_regex]
diff --git a/Documentation/git-svnimport.txt b/Documentation/git-svnimport.txt
index 912a808..deee66a 100644
--- a/Documentation/git-svnimport.txt
+++ b/Documentation/git-svnimport.txt
@@ -9,6 +9,7 @@ git-svnimport - Import a SVN repository
SYNOPSIS
--------
+[verse]
'git-svnimport' [ -o <branch-for-HEAD> ] [ -h ] [ -v ] [ -d | -D ]
[ -C <GIT_repository> ] [ -i ] [ -u ] [-l limit_rev]
[ -b branch_subdir ] [ -T trunk_subdir ] [ -t tag_subdir ]
--
1.2.3.g858c-dirty
--
Jonas Fonseca
^ permalink raw reply related
* Re: [PATCH] fmt-merge-msg: avoid open "-|" list form for Perl 5.6
From: Alex Riesen @ 2006-03-02 16:10 UTC (permalink / raw)
To: Christopher Faylor; +Cc: git
In-Reply-To: <20060302150016.GC2781@trixie.casa.cgf.cx>
On 3/2/06, Christopher Faylor <me@cgf.cx> wrote:
> >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"?
It does. Almost always. It's the seldom cases when this does not
really work which annoy me that much.
> 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.
well, it is almost exactly the case: WinNT 2K. And I cannot change this.
> If you are reporting a problem you need to provide details.
I am NOT reporting a problem. Everyone knows there are these problems,
it's just almost no one (including me) cares enough about getting anything
to work sanely on windows.
Please, stop assuming that every my complaint is a bug report about
cygwin. It is not. You can use my mails as you please, even as bug reports.
If you ask nicely, I can provide more details maybe. But I am not asking
YOU for anything, and not complaining to YOU about anything.
I _do_not_ like how Cygwin workarounds windows, but I respect the
effort and understand why it happens. Still, I'd prefer it die. I'll try to
keep it moving, but no farther than needed and only when I really have to.
> 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.
In windows you have to do hell of a lot useless typing to write what you
consider a "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.
That's right. They are not _ported_. I'm not interested in xterm which
prints page in a minute.
> >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*.
Whatever you say. I never expected them to, personally.
> 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.
Maybe. I wouldn't blame that poor windows programmer though: it's hard,
boring and in 99.9999% of starts of that program - dead code.
> 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.
gui applications detach from cmd (not from cygwin console),
so that kind of pointless exercise.
> 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'd suggest calling cygwin ports unsupported.
> >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
find . -name '*.[ch]' -o -name '*.[ch]pp' -o -name Makefile -o -name
'*.txt' -o ...ooh! damn it^C -print0| xargs -0 chmod -x
You oversimplifying.
^ permalink raw reply
* Re: windows problems summary
From: Andreas Ericsson @ 2006-03-02 16:01 UTC (permalink / raw)
To: Alex Riesen; +Cc: Christopher Faylor, Git Mailing List
In-Reply-To: <81b0412b0603020735j603b3518ob5e27a02c531093a@mail.gmail.com>
Alex Riesen wrote:
> On 3/2/06, Christopher Faylor <me@cgf.cx> wrote:
>
>>Are we *really* contemplating porting git to native Windows?
>>
>
>
> Actually, I wasn't thinking about that when I was writing that mail,
> but ... why not?
For the same reason we don't support Perl 5.4. It's too much effort for
too little gain. OTOH, if you want to do the effort, I won't mind taking
the gain. ;)
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: windows problems summary
From: Bertrand Jacquin @ 2006-03-02 15:57 UTC (permalink / raw)
To: Alex Riesen; +Cc: Christopher Faylor, Git Mailing List
In-Reply-To: <81b0412b0603020735j603b3518ob5e27a02c531093a@mail.gmail.com>
On 3/2/06, Alex Riesen <raa.lkml@gmail.com> wrote:
> On 3/2/06, Christopher Faylor <me@cgf.cx> wrote:
> >
> > Are we *really* contemplating porting git to native Windows?
> >
>
> Actually, I wasn't thinking about that when I was writing that mail,
> but ... why not?
> Cygwin makes syscalls many times slower, git is very slow on
> windows, users (well, I) want it faster, so if the needed api subset
> can be narrowed down to a reasonable amount of work - I think
> I'd give the idea a try.
Is the goal to have something like a git-turtoise (as {svn,cvs}-turtoise) ?
I personaly think that is could be benefic.
--
Beber
#e.fr@freenode
^ permalink raw reply
* Re: Newbie question: git tag failure
From: Jan-Benedict Glaw @ 2006-03-02 15:54 UTC (permalink / raw)
To: Aubrey; +Cc: git
In-Reply-To: <6d6a94c50603020751v4bb96b75q1686d36b32e2c40f@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1198 bytes --]
On Thu, 2006-03-02 23:51:04 +0800, Aubrey <aubreylee@gmail.com> wrote:
> aubrey@linux:~/local/mygit>git tag -u
> 43368b967bd838292b8cc6b576c5aa13850551cc v2.5
> gpg: directory `/home/aubrey/.gnupg' created
> gpg: new configuration file `/home/aubrey/.gnupg/gpg.conf' created
> gpg: WARNING: options in `/home/aubrey/.gnupg/gpg.conf' are not yet
> active during this run
> gpg: keyring `/home/aubrey/.gnupg/secring.gpg' created
> gpg: keyring `/home/aubrey/.gnupg/pubring.gpg' created
> gpg: skipped "43368b967bd838292b8cc6b576c5aa13850551cc": secret key
> not available
> gpg: signing failed: secret key not available
> failed to sign the tag with GPG.
You seem to not have a working GnuPG installation, inclusing an
(already present) private key. Please first get familiar with GnuPG,
then try to use it :-) "gpg --gen-key" may help.
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Newbie question: git tag failure
From: Aubrey @ 2006-03-02 15:51 UTC (permalink / raw)
To: git
There are two commit. I want to tag one commit by commit id, but failed.
Thanks for any hints.
Regards,
-Aubrey
aubrey@linux:~/local/mygit> git log
===============================================================
commit a8ac6540cf96f79225cc8457b02cb90d40ac7991
Author: Aubrey.Li <aubrey@linux.site>
Date: Thu Mar 2 23:34:18 2006 +0800
add commit log
commit 43368b967bd838292b8cc6b576c5aa13850551cc
Author: Aubrey.Li <aubrey@linux.site>
Date: Thu Mar 2 22:24:55 2006 +0800
Initial commit
===============================================================
aubrey@linux:~/local/mygit>git tag -u
43368b967bd838292b8cc6b576c5aa13850551cc v2.5
gpg: directory `/home/aubrey/.gnupg' created
gpg: new configuration file `/home/aubrey/.gnupg/gpg.conf' created
gpg: WARNING: options in `/home/aubrey/.gnupg/gpg.conf' are not yet
active during this run
gpg: keyring `/home/aubrey/.gnupg/secring.gpg' created
gpg: keyring `/home/aubrey/.gnupg/pubring.gpg' created
gpg: skipped "43368b967bd838292b8cc6b576c5aa13850551cc": secret key
not available
gpg: signing failed: secret key not available
failed to sign the tag with GPG.
^ permalink raw reply
* Re: windows problems summary
From: Johannes Schindelin @ 2006-03-02 15:38 UTC (permalink / raw)
To: Alex Riesen; +Cc: Git Mailing List
In-Reply-To: <81b0412b0603020649u99a2035i3b8adde8ddce9410@mail.gmail.com>
Hi,
On Thu, 2 Mar 2006, Alex Riesen wrote:
> 1. opened and mmaped files can't be removed or renamed
> (caused workaround with reading index in memory)
It was not the locking which caused the workaround. It was the
not-working. (I still have to find a Windows machine where git-whatchanged
does not segfault without NO_MMAP.)
> 2. command can safely contain only one argument
> (breaks and complicates passing things between processes)
> 3. no fork
> (slows down and complicates passing things between processes)
> 4. non-unix permissions model
> (breaks x-attr)
> 5. real slow filesystems and caching
> (makes everything slow. I noticed I'm trying to avoid git status!).
> Caused workaround with manual checkout)
> 6. real slow program startup
> (makes everything slow, eventually may cause everything being put
> in one super-executable, just to avoid spawning new processes,
> with all associated problems. Makes scripting harder)
Except for (4), these issues should be resolvable by the libifying effort.
Ciao,
Dscho
^ permalink raw reply
* Re: windows problems summary
From: Alex Riesen @ 2006-03-02 15:35 UTC (permalink / raw)
To: Christopher Faylor; +Cc: Git Mailing List
In-Reply-To: <20060302152329.GH2781@trixie.casa.cgf.cx>
On 3/2/06, Christopher Faylor <me@cgf.cx> wrote:
>
> Are we *really* contemplating porting git to native Windows?
>
Actually, I wasn't thinking about that when I was writing that mail,
but ... why not?
Cygwin makes syscalls many times slower, git is very slow on
windows, users (well, I) want it faster, so if the needed api subset
can be narrowed down to a reasonable amount of work - I think
I'd give the idea a try.
^ permalink raw reply
* Re: windows problems summary
From: Christopher Faylor @ 2006-03-02 15:23 UTC (permalink / raw)
To: Alex Riesen, Git Mailing List
In-Reply-To: <81b0412b0603020649u99a2035i3b8adde8ddce9410@mail.gmail.com>
On Thu, Mar 02, 2006 at 03:49:24PM +0100, Alex Riesen wrote:
>This is just to summarize all the problems which make porting to that
>thing so boring. Maybe if we have them all on one page, it'd be easier
>to locate the workarounds (it can be one thread, for example).
>
>1. opened and mmaped files can't be removed or renamed
> (caused workaround with reading index in memory)
>2. command can safely contain only one argument
> (breaks and complicates passing things between processes)
>3. no fork
> (slows down and complicates passing things between processes)
>4. non-unix permissions model
> (breaks x-attr)
>5. real slow filesystems and caching
> (makes everything slow. I noticed I'm trying to avoid git status!).
> Caused workaround with manual checkout)
>6. real slow program startup
> (makes everything slow, eventually may cause everything being put
> in one super-executable, just to avoid spawning new processes,
> with all associated problems. Makes scripting harder)
>
>I hope this message can be a start of a big porting thread,
>even though it is only about windows at the moment.
Are we *really* contemplating porting git to native Windows?
I guess I missed that memo.
cgf
^ permalink raw reply
* Re: [PATCH] fmt-merge-msg: avoid open "-|" list form for Perl 5.6
From: Christopher Faylor @ 2006-03-02 15:22 UTC (permalink / raw)
To: git
In-Reply-To: <81b0412b0603020618q3b205cdeuabc7e204044cca5b@mail.gmail.com>
On Thu, Mar 02, 2006 at 03:18:44PM +0100, Alex Riesen wrote:
>On 2/26/06, Christopher Faylor <me@cgf.cx> wrote:
>> The cygwin/windows version of spawn is basically like an extended version
>> of exec*():
>>
>> pid = spawnlp (P_NOWAIT, "/bin/ls", "ls", "-l", NULL);
>>
>
>By the way, is argv worked around?
>AFAIK, windows has only one argument, returned by GetCommandLine?
Cygwin passes an argv list between cygwin processes and a quoted command
line to pure windows processes.
cgf
^ permalink raw reply
* Re: git push issue
From: Aubrey @ 2006-03-02 15:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <6d6a94c50603020246g1520ceahb970da7bbf965dfc@mail.gmail.com>
OK. I help myself out.
It's not complex to put own work on a web server. And it works on my
end. Because git:// or rsync:// need the port which it's possibly
unaccessible behind a firewall. I think it's good enough so far to use
http connection.
Regards,
-Aubrey
^ permalink raw reply
* Re: [PATCH] fmt-merge-msg: avoid open "-|" list form for Perl 5.6
From: Mark Wooding @ 2006-03-02 15:18 UTC (permalink / raw)
To: git
In-Reply-To: <81b0412b0603020618q3b205cdeuabc7e204044cca5b@mail.gmail.com>
"Alex Riesen" <raa.lkml@gmail.com> wrote:
> AFAIK, windows has only one argument, returned by GetCommandLine?
This is true, but there's a standard quoting convention which (in
particular) Microsoft's C library uses to split the single argument back
into an argv. The spawn* functions quote; the C library startup stuff
unquotes and splits.
The actual quoting convention is /horrible/. I had to implement the
darned thing once. See
http://sources.redhat.com/ml/cygwin/1999-08/msg00701.html
for the details.
-- [mdw]
^ permalink raw reply
* Re: [PATCH] fmt-merge-msg: avoid open "-|" list form for Perl 5.6
From: Christopher Faylor @ 2006-03-02 15:00 UTC (permalink / raw)
To: git
In-Reply-To: <81b0412b0603020610q41d0ec98x80d112b7daa179fa@mail.gmail.com>
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 <me@cgf.cx> wrote:
>> >>>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...
>
>> >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.
>> 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.
>>>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
^ permalink raw reply
* windows problems summary
From: Alex Riesen @ 2006-03-02 14:49 UTC (permalink / raw)
To: Git Mailing List
This is just to summarize all the problems which make porting to that
thing so boring. Maybe if we have them all on one page, it'd be easier
to locate the workarounds (it can be one thread, for example).
1. opened and mmaped files can't be removed or renamed
(caused workaround with reading index in memory)
2. command can safely contain only one argument
(breaks and complicates passing things between processes)
3. no fork
(slows down and complicates passing things between processes)
4. non-unix permissions model
(breaks x-attr)
5. real slow filesystems and caching
(makes everything slow. I noticed I'm trying to avoid git status!).
Caused workaround with manual checkout)
6. real slow program startup
(makes everything slow, eventually may cause everything being put
in one super-executable, just to avoid spawning new processes,
with all associated problems. Makes scripting harder)
I hope this message can be a start of a big porting thread,
even though it is only about windows at the moment.
Alex Riesen
^ permalink raw reply
* Re: [PATCH] fmt-merge-msg: avoid open "-|" list form for Perl 5.6
From: Alex Riesen @ 2006-03-02 14:18 UTC (permalink / raw)
To: Christopher Faylor; +Cc: git
In-Reply-To: <20060226204027.GC30735@trixie.casa.cgf.cx>
On 2/26/06, Christopher Faylor <me@cgf.cx> wrote:
> The cygwin/windows version of spawn is basically like an extended version
> of exec*():
>
> pid = spawnlp (P_NOWAIT, "/bin/ls", "ls", "-l", NULL);
>
By the way, is argv worked around?
AFAIK, windows has only one argument, returned by GetCommandLine?
^ permalink raw reply
* Re: [PATCH] fmt-merge-msg: avoid open "-|" list form for Perl 5.6
From: Alex Riesen @ 2006-03-02 14:10 UTC (permalink / raw)
To: Christopher Faylor; +Cc: git
In-Reply-To: <20060226195552.GA30735@trixie.casa.cgf.cx>
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 <me@cgf.cx> wrote:
> >>>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...
> >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.
> 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.
Now, I know that windows has no signals at all and nothing which
even closely resembles them. 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, 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.
> >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 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. The
poor executables lose their _rights_ to be executed (why does cygwin use
windows permissions? They cannot correlate to unix attributes, can they?)
An .bat or .cmd without right to execute it is a pain in my build system
(and no, I'm not allowed to change that damn stupid build system).
Is there any way to tell cygwin that the files it hasn't seen or touched yet
are _not_executables_?
^ permalink raw reply
* Re: Problems with using git
From: Andreas Ericsson @ 2006-03-02 13:59 UTC (permalink / raw)
To: Joseph Wakeling; +Cc: git
In-Reply-To: <4406F8B1.9050303@webdrake.net>
Joseph Wakeling wrote:
> Thanks very much to all who offered advice on this. :-)
>
> Unfortunately openSUSE is somewhat out of sync not just with git but in
> libraries necessary to install the latest version (libcrypto.so.4,
> libssl.so.4). The openssl (0.9.7g-2.4) and openssl-devel (0.9.7g-2)
> packages don't contain these but rather contain libcrypto.so.0.9.7 and
> libssl.0.9.7. Just in case it's important to future git development.
>
It might be useful for the openSuSE developers, but for git this is
totally irrelevant. If you build from sources yourself they will be
linked to whatever libraries you have installed.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Problems with using git
From: Joseph Wakeling @ 2006-03-02 13:52 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0603011651240.22647@g5.osdl.org>
Thanks very much to all who offered advice on this. :-)
Unfortunately openSUSE is somewhat out of sync not just with git but in
libraries necessary to install the latest version (libcrypto.so.4,
libssl.so.4). The openssl (0.9.7g-2.4) and openssl-devel (0.9.7g-2)
packages don't contain these but rather contain libcrypto.so.0.9.7 and
libssl.0.9.7. Just in case it's important to future git development.
Best wishes & thanks again,
-- Joe
^ permalink raw reply
* Re: NT directory traversal speed on 25K files on Cygwin
From: Alex Riesen @ 2006-03-02 13:40 UTC (permalink / raw)
To: git; +Cc: Andreas Ericsson, Christopher Faylor, git
In-Reply-To: <20060227184544.GB13195@nospam.com>
On 2/27/06, Rutger Nijlunsing <rutger@nospam.com> wrote:
> I'm not saying Cygwin is bad (actually, I'm installing on every
> Windows PC I get my hand on ;), but using Cygwin for all file IO
> instead of native Windows IO makes git a magnitude slower on Windows
By "slow filesystem" I actually meant the native filesystem access.
Cygwin does make it 6 times slower, that's right, and this can be
considered a disaster of course, but not as big as the windows api.
^ permalink raw reply
* cygwin: push/pull takes very long time
From: Alex Riesen @ 2006-03-02 13:26 UTC (permalink / raw)
To: Git Mailing List
Hi,
I didn't really notice when it happened, but since some time
push and pull takes *very* long. git-pack-objects appears to
be the major offender:
$ git pull ../src march:march
Generating pack...
Done counting 20238 objects.
Result has 12 objects.
Deltifying 12 objects.
8% (1/12) done
It's still working, half an hour since it was started.
It can be seen that it is constantly growing and shrinking
(for about 20k,50k,80k,100k back and forth).
I did a small instrumentation to figure out how much
and how often is allocated, but it's waiting for the
git-pack-objects to finish. "Counting objects" was
slow too, with git-rev-list "pulsating" in a similar
way (most commonly allocated objects in the size
range from 16 to 256).
I continue looking for the problem (I didn't do bisect yet,
want to wait for mem profile first), but any ideas on how
to fix that are very welcome.
^ permalink raw reply
* Re: [PATCH] Teach git-checkout-index to read filenames from stdin.
From: Alex Riesen @ 2006-03-02 13:14 UTC (permalink / raw)
To: Christopher Faylor; +Cc: git
In-Reply-To: <81b0412b0603020512i429481f7i4a0dbe4599dbb5a6@mail.gmail.com>
On 3/2/06, Alex Riesen <raa.lkml@gmail.com> wrote:
> On 3/1/06, Christopher Faylor <me@cgf.cx> wrote:
> >
> > For native Windows programs, the command line length is ~32K but I don't
> > think that git uses any native Windows programs, does it?
> >
>
> Yes, ActiveState Perl is as native as it gets.
>
It does use native windows programs, I mean.
At least for me it does.
^ permalink raw reply
* Re: [PATCH] Teach git-checkout-index to read filenames from stdin.
From: Alex Riesen @ 2006-03-02 13:12 UTC (permalink / raw)
To: Christopher Faylor; +Cc: git
In-Reply-To: <20060301155053.GC1010@trixie.casa.cgf.cx>
On 3/1/06, Christopher Faylor <me@cgf.cx> wrote:
>
> For native Windows programs, the command line length is ~32K but I don't
> think that git uses any native Windows programs, does it?
>
Yes, ActiveState Perl is as native as it gets.
^ permalink raw reply
* Re: git doesn't like big files when pushing
From: Simon Richter @ 2006-03-02 12:43 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Greg KH, git
In-Reply-To: <Pine.LNX.4.64.0603011448230.22647@g5.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 685 bytes --]
Hi,
Linus Torvalds wrote:
> But maybe it's really the case that you can't fit those 8 objects in
> memory. One option (which might also solve some of the performance issues)
> is to make the window be based on object _size_ rather than just be a
> fixed number (ie with an 80MB object, you'd only try a couple of objects
> around it, not the full window).
Well, doesn't the pack process involve keeping objects of similar size
in memory next to each other? My suspicion is that the system is running
out of virtual address space because almost every malloc() will attempt
to get an entirely new block because the one that was just freed is a
few bytes too small.
Simon
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 307 bytes --]
^ permalink raw reply
* gitview: pass the missing argument _show_clicked_cb
From: Aneesh Kumar K.V @ 2006-03-02 11:47 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
From: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Subject: gitview: pass the missing argument _show_clicked_cb.
In our last update to use the encoding while showing the commit
diff we added a new argument to this function. But we missed
updating all the callers.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
---
contrib/gitview/gitview | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
225f953266128b0703fd8d8a20b3167d06503e4a
diff --git a/contrib/gitview/gitview b/contrib/gitview/gitview
index de9f3f3..781badb 100755
--- a/contrib/gitview/gitview
+++ b/contrib/gitview/gitview
@@ -798,7 +798,7 @@ class GitView:
button.set_relief(gtk.RELIEF_NONE)
button.set_sensitive(True)
button.connect("clicked", self._show_clicked_cb,
- child_id, commit.commit_sha1)
+ child_id, commit.commit_sha1, self.encoding)
hbox.pack_start(button, expand=False, fill=True)
button.show()
--
1.2.3.gc55f-dirty
^ permalink raw reply related
* [PATCH] Fix test case for some sed
From: Johannes Schindelin @ 2006-03-02 11:43 UTC (permalink / raw)
To: git, junkio
Some versions of sed lack the "-i" option.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
t/t8001-annotate.sh | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
7f024821ec45dc6eaf36c24f94931d58deb75201
diff --git a/t/t8001-annotate.sh b/t/t8001-annotate.sh
index cae1794..172908a 100755
--- a/t/t8001-annotate.sh
+++ b/t/t8001-annotate.sh
@@ -50,7 +50,8 @@ test_expect_success \
test_expect_success \
'merge-setup part 2' \
'git checkout -b branch2 master &&
- sed -i -e "s/2A quick brown/4A quick brown lazy dog/" file &&
+ sed -e "s/2A quick brown/4A quick brown lazy dog/" < file > file.new &&
+ mv file.new file &&
GIT_AUTHOR_NAME="B2" git commit -a -m "Branch2-1"'
test_expect_success \
--
1.2.4.g9520
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox