* Re: Performance issue with excludes (was: Re: git-svn and submodules)
From: Linus Torvalds @ 2007-10-15 17:10 UTC (permalink / raw)
To: Benoit SIGOURE; +Cc: git list
In-Reply-To: <45410184-8D7D-47ED-AB10-1A4E52D0ADB0@lrde.epita.fr>
On Mon, 15 Oct 2007, Benoit SIGOURE wrote:
>
> There is no .gitignore, only .git/info/exclude.
They do exactly the same thing (apart from the nesting nature of
.gitignore wrt subdirectories), so that doesn't change anything.
Linus
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Alex Riesen @ 2007-10-15 17:36 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Dave Korn, 'Andreas Ericsson', 'git list',
'Make Windows'
In-Reply-To: <Pine.LNX.4.64.0710150059460.25221@racer.site>
Johannes Schindelin, Mon, Oct 15, 2007 02:01:00 +0200:
> On Sun, 14 Oct 2007, Dave Korn wrote:
> > On 14 October 2007 23:15, Alex Riesen wrote:
> > > - 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)
> >
> > Whuh?
> >
> > http://msdn2.microsoft.com/en-us/library/y5zz48s1(VS.80).aspx
>
> It does have an exec() call, yes, since that is required by the C
> standard. But internally, it converts that into one single command line.
>
> In corner cases, you find problems with that.
>
Like: "damn, it is just IMPOSSIBLE to implement without them corner
cases."
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Alex Riesen @ 2007-10-15 17:38 UTC (permalink / raw)
To: Michael Gebetsroither; +Cc: git, make-w32
In-Reply-To: <feud8j$kdg$1@ger.gmane.org>
Michael Gebetsroither, Mon, Oct 15, 2007 02:46:11 +0200:
> > - it is the only OS in the world with multi-root (/a/b/c and /a/b/c
> > can be not the same, depending on what current "drive" is) and
> > multi-cwd, which hasn't had formed itself into a problem yet, but
> > surely will
>
> Thats true for linux too.
> /a/b/c and /a/b/c can be 2 totally different files depending on the vfs
> namespace you are one.
No it is not. A process will always see the same filesystem object
under the same path at the any given time (IOW, you can't have many
namespaces active at the same time).
^ permalink raw reply
* Re: Performance issue with excludes (was: Re: git-svn and submodules)
From: Benoit SIGOURE @ 2007-10-15 17:38 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git list
In-Reply-To: <alpine.LFD.0.999.0710151009460.6887@woody.linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 785 bytes --]
On Oct 15, 2007, at 7:10 PM, Linus Torvalds wrote:
> On Mon, 15 Oct 2007, Benoit SIGOURE wrote:
>>
>> There is no .gitignore, only .git/info/exclude.
>
> They do exactly the same thing (apart from the nesting nature of
> .gitignore wrt subdirectories), so that doesn't change anything.
I fail to see how the mechanism work then. You said that I needed to
add the .gitignore before adding all the other bummer stuff, fair
enough. AFAIK .git/info/exclude doesn't need to be added, it's just
there. But you can try to change the test, add the .git/info/exclude
*first* and then make a commit and then add all the bummer stuff and
then commit, and finally, do a git-status, for me it still takes 9s.
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Alex Riesen @ 2007-10-15 17:49 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: ae, git, make-w32
In-Reply-To: <Pine.LNX.4.64.0710150936070.25221@racer.site>
Johannes Schindelin, Mon, Oct 15, 2007 10:44:12 +0200:
> On Mon, 15 Oct 2007, Eli Zaretskii wrote:
> > Can you show a test case where this penalty is clearly visible? I'm
> > curious to see the numbers. TIA
...
> Now, that is my _personal_ decision. If _you_ have no problem with
> Windows, just stick with it. (I always thought this goes without saying,
> but Windows users tend to be very religious about this issue, thinking
> just because I hate Windows that I want to make them switch. Hahaha, no.)
They tend to be so exactly because they know how pathetic they are.
They just want to have something where they don't suck and do
everything to find it. And fail. Then they resort to graphics and
user-friendly interface.
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Alex Riesen @ 2007-10-15 17:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Eli Zaretskii, ae, tsuna, git, make-w32
In-Reply-To: <Pine.LNX.4.64.0710150039120.25221@racer.site>
Johannes Schindelin, Mon, Oct 15, 2007 01:45:47 +0200:
> On Mon, 15 Oct 2007, Eli Zaretskii wrote:
> > Alex Riesen said:
> > > - it is the only OS in the world with multi-root (/a/b/c and /a/b/c
> > > can be not the same, depending on what current "drive" is)
> >
> > So what? on Unix "a/b/c" can be not the same. Both cases are simply not
> > complete file names, that's all. No one said there must be a single
> > root for all volumes, it's the Posix jingoism creeping in again.
>
> I think Alex means this: you can have C:\a\b\c and D:\a\b\c. So depending
> on which drive you are, you mean one or the other. Just comparing the
> paths is not enough.
Not really. I meant that "/a/b/c" and "/a/b/c". Note the leading
slash. On windoze it is _NOT_ absolute path. It is relative to the
root of the current drive.
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Alex Riesen @ 2007-10-15 17:56 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Eli Zaretskii, ae, tsuna, make-w32
In-Reply-To: <Pine.LNX.4.64.0710150217120.25221@racer.site>
Johannes Schindelin, Mon, Oct 15, 2007 03:22:53 +0200:
> On Sun, 14 Oct 2007, Brian Dessent wrote:
> > Johannes Schindelin wrote:
> > > The problem is that on Windows, you cannot keep a file open and delete
> > > it at the same time. This is an issue in Windows' equivalent of VFS.
> > >
> > > A neat trick to work with temporary files without permission issues is
> > > to open the file and delete it right after that. This does not work
> > > on Windows.
> >
> > You can achieve the same thing on Windows with CreateFile() by setting
> > the dwShareMode parameter to zero and setting the
> > FILE_FLAG_DELETE_ON_CLOSE attribute on dwFlagsAndAttributes. This
> > results in a file that cannot be opened or read by any other process and
> > that will be automatically deleted when all open handles are closed.
>
> Aha. So to support Windows, we have to wrap all sites that use that
> trick, and special case that #ifdef __MINGW32__.
He misunderstood. It is not what you meant. You cannot remove the open
file. What he talks about is removing the file after it is _closed_.
Junk.
^ permalink raw reply
* [PATCH] git-rebase--interactive.sh: Quote arguments to test
From: Michael W. Olson @ 2007-10-15 17:48 UTC (permalink / raw)
To: git
If /bin/sh is /bin/dash, then the script will display an error if
$parent_sha1 is undefined. This patch works fixes the issue by
quoting both arguments to `test'. Arguments composed solely of
variable expansions should always be quoted, unless we know for
certain that the contents are defined.
Signed-off-by: Michael W. Olson <mwolson@gnu.org>
---
Resending, this time directly to the mailing list instead of via Gmane.
git-rebase--interactive.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 050140d..8a03062 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -110,7 +110,7 @@ pick_one () {
parent_sha1=$(git rev-parse --verify $sha1^) ||
die "Could not get the parent of $sha1"
current_sha1=$(git rev-parse --verify HEAD)
- if test $no_ff$current_sha1 = $parent_sha1; then
+ if test "$no_ff$current_sha1" = "$parent_sha1"; then
output git reset --hard $sha1
test "a$1" = a-n && output git reset --soft $current_sha1
sha1=$(git rev-parse --short $sha1)
--
1.5.3.4
^ permalink raw reply related
* RE: Switching from CVS to GIT
From: Dave Korn @ 2007-10-15 18:25 UTC (permalink / raw)
To: 'Alex Riesen', 'Johannes Schindelin'; +Cc: ae, git, make-w32
In-Reply-To: <20071015174922.GC2966@steel.home>
On 15 October 2007 18:49, Alex Riesen wrote:
> Johannes Schindelin, Mon, Oct 15, 2007 10:44:12 +0200:
>> On Mon, 15 Oct 2007, Eli Zaretskii wrote:
>>> Can you show a test case where this penalty is clearly visible? I'm
>>> curious to see the numbers. TIA
> ...
>> Now, that is my _personal_ decision. If _you_ have no problem with
>> Windows, just stick with it. (I always thought this goes without saying,
>> but Windows users tend to be very religious about this issue, thinking
>> just because I hate Windows that I want to make them switch. Hahaha, no.)
>
> They tend to be so exactly because they know how pathetic they are.
> They just want to have something where they don't suck and do
> everything to find it. And fail. Then they resort to graphics and
> user-friendly interface.
Translation: "I feel that I am superior to other people. This post has no
content apart from me shooting my mouth off in an attempt to prove how much
cleverer I am than anyone else. However apart from my self-love I have no
contribution to make to the discussion."
This isn't slashdot. A computer is just a tool, and it's really *you* who
are being pathetic, because you confuse a choice of mass-manufactured consumer
product with a statement about personal identity. Loyalty to your favourite
brand is a game of one-upmanship suitable only for kids. You need to grow up.
cheers,
DaveK
--
Can't think of a witty .sigline today....
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Paul Smith @ 2007-10-15 18:29 UTC (permalink / raw)
To: Eli Zaretskii
Cc: raa.lkml, prohaska, make-w32, Johannes.Schindelin, ae,
Johannes Sixt, git
In-Reply-To: <E1IhPCo-0004ZO-N9@fencepost.gnu.org>
OK, enough. I am extremely grateful for the porting and maintenance
efforts of the GNU make porting team (since I have no Windows--or Amiga,
or OS/2, or OpenVMS--systems to maintain these ports myself) and I'm not
going to choose a tool unless it supports their environment and helps
them to work more efficiently (or at least no less efficiently). I'm
not interested in getting into a pissing match over which operating
system is better or worse, and I'm certainly not interested in unfounded
inferences as to the character and quality of my porting team based on
the operating system they are using.
For those who have provided details and pointers regarding the state of
GIT on Windows, thank you very much for your help: it's been very useful
and Eli and others sound like they have enough information to be getting
on with for now. If you'd like to discuss some Windows porting issues
further there are a number of extremely knowledgeable Windows / FLOSS
programmers on the make-w32@gnu.org list--although they are generally
very busy.
If what you're interested in is self-congratulatory back-slapping over
the superiority of Linux/POSIX, please keep that on the GIT mailing
list, or else an advocacy forum somewhere.
I'm setting followups to the GIT list.
Cheers all!
--
-------------------------------------------------------------------------------
Paul D. Smith <psmith@gnu.org> Find some GNU make tips at:
http://www.gnu.org http://make.mad-scientist.us
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
^ permalink raw reply
* RE: Switching from CVS to GIT
From: Johannes Schindelin @ 2007-10-15 18:34 UTC (permalink / raw)
To: Dave Korn; +Cc: 'Alex Riesen', ae, git, make-w32
In-Reply-To: <030301c80f58$d37b9710$2e08a8c0@CAM.ARTIMI.COM>
Hi,
On Mon, 15 Oct 2007, Dave Korn wrote:
> On 15 October 2007 18:49, Alex Riesen wrote:
>
> > Johannes Schindelin, Mon, Oct 15, 2007 10:44:12 +0200:
> >> On Mon, 15 Oct 2007, Eli Zaretskii wrote:
> >>> Can you show a test case where this penalty is clearly visible? I'm
> >>> curious to see the numbers. TIA
> > ...
> >> Now, that is my _personal_ decision. If _you_ have no problem with
> >> Windows, just stick with it. (I always thought this goes without saying,
> >> but Windows users tend to be very religious about this issue, thinking
> >> just because I hate Windows that I want to make them switch. Hahaha, no.)
> >
> > They tend to be so exactly because they know how pathetic they are.
> > They just want to have something where they don't suck and do
> > everything to find it. And fail. Then they resort to graphics and
> > user-friendly interface.
>
> Translation: "I feel that I am superior to other people. This post
> has no content apart from me shooting my mouth off in an attempt to
> prove how much cleverer I am than anyone else. However apart from my
> self-love I have no contribution to make to the discussion."
>
> This isn't slashdot. A computer is just a tool, and it's really *you*
> who are being pathetic, because you confuse a choice of
> mass-manufactured consumer product with a statement about personal
> identity. Loyalty to your favourite brand is a game of one-upmanship
> suitable only for kids. You need to grow up.
I sense a classical Stockholm Syndrome here ;-)
Ciao,
Dscho
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Brian Dessent @ 2007-10-15 18:37 UTC (permalink / raw)
To: Alex Riesen; +Cc: Johannes Schindelin, git, Eli Zaretskii, ae, tsuna, make-w32
In-Reply-To: <20071015175606.GE2966@steel.home>
Alex Riesen wrote:
> He misunderstood. It is not what you meant. You cannot remove the open
> file. What he talks about is removing the file after it is _closed_.
> Junk.
I did not misunderstand. The semantics are equivalent to the POSIX
case: you end up with a handle to an open file that is exclusive to that
process (it cannot be opened by any other process, even root) and that
is automatically reclaimed by the filesystem when all open handles are
closed, without any explicit action by the user. It's not "unlinking an
open file", no, but it's the same result.
Brian
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Johannes Schindelin @ 2007-10-15 18:44 UTC (permalink / raw)
To: git; +Cc: Alex Riesen, Eli Zaretskii, ae, tsuna
In-Reply-To: <4713B367.52CEC7E2@dessent.net>
Hi,
[excluding make-w32 list as per explicit request]
On Mon, 15 Oct 2007, Brian Dessent wrote:
> Alex Riesen wrote:
>
> > He misunderstood. It is not what you meant. You cannot remove the open
> > file. What he talks about is removing the file after it is _closed_.
> > Junk.
>
> I did not misunderstand. The semantics are equivalent to the POSIX
> case: you end up with a handle to an open file that is exclusive to that
> process (it cannot be opened by any other process, even root) and that
> is automatically reclaimed by the filesystem when all open handles are
> closed, without any explicit action by the user. It's not "unlinking an
> open file", no, but it's the same result.
No, it is not equivalent. For example, you can still see the file. For
example, you cannot reuse the filename for another file. And -- the
killer -- you cannot remove the directory which contains the file.
But really, we have workarounds in place to make this a non-issue.
My bigger concerns are the performance and stability. For example, I had
a very annoying problem on one of the machines I am testing msysGit on.
The problem was _only_ fixable by deactivating component of Logitech's
WebCam driver! Now, if a user-installable 3rd party program can make my
regular git crash, I am scared what more it can do.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Documentation/git-tag.txt: Document how to backdate tags
From: Michael Olson @ 2007-10-15 17:51 UTC (permalink / raw)
To: Junio C Hamano, git
In-Reply-To: <7vd4w0iqd5.fsf@gitster.siamese.dyndns.org>
Added a new section beneath "On Automatic following" called "On
Backdating Tags". This includes an explanation of when to use this
method, a brief explanation of the kind of date that can be used in
GIT_AUTHOR_DATE, and an example invocation of git-tag using a custom
setting of GIT_AUTHOR_DATE.
Signed-off-by: Michael W. Olson <mwolson@gnu.org>
---
[Resending, this time without trying to send through Gmane and munge
Reply-To.]
Junio C Hamano <gitster@pobox.com> writes:
> Michael Olson <mwolson@gnu.org> writes:
>
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>>> Wouldn't it be easier to create the tag with the desired
>>> timestamp from the beginning, by exporting GIT_COMMITTER_DATE?
>>
>> Ah, I didn't know about that environment variable.
>>
>> Would it be possible to mention that option on the git-tag manpage?
>
> Surely, I am kind of surprised if it weren't, but apparently you
> did not find it. Please make it so.
Documentation/git-tag.txt | 21 +++++++++++++++++++++
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
index 990ae4f..2966aa2 100644
--- a/Documentation/git-tag.txt
+++ b/Documentation/git-tag.txt
@@ -214,6 +214,27 @@ having tracking branches. Again, the heuristic to automatically
follow such tags is a good thing.
+On Backdating Tags
+~~~~~~~~~~~~~~~~~~
+
+If you have imported some changes from another VCS and would like
+to add tags for major releases of you work, it is useful to be able
+to specify the date to embed inside of the tag object. The data in
+the tag object affects, for example, the ordering of tags in the
+gitweb interface.
+
+To set the date used in future tag objects, set the environment
+variable GIT_AUTHOR_DATE to one or more of the date and time. The
+date and time can be specified in a number of ways; the most common
+is "YYYY-MM-DD HH:MM".
+
+An example follows.
+
+------------
+$ GIT_AUTHOR_DATE="2006-10-02 10:31" git tag -s v1.0.1
+------------
+
+
Author
------
Written by Linus Torvalds <torvalds@osdl.org>,
--
1.5.3.4
^ permalink raw reply related
* Re: Switching from CVS to GIT
From: Brian Dessent @ 2007-10-15 19:07 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Alex Riesen, Eli Zaretskii, ae, tsuna
In-Reply-To: <Pine.LNX.4.64.0710151938300.25221@racer.site>
Johannes Schindelin wrote:
> No, it is not equivalent. For example, you can still see the file. For
> example, you cannot reuse the filename for another file. And -- the
> killer -- you cannot remove the directory which contains the file.
Fair enough. You can move it to another directory in order to delete
the containing directory -- this is what Cygwin does to placate posix
apps that expect this to work.
> But really, we have workarounds in place to make this a non-issue.
Ok.
> My bigger concerns are the performance and stability. For example, I had
> a very annoying problem on one of the machines I am testing msysGit on.
> The problem was _only_ fixable by deactivating component of Logitech's
> WebCam driver! Now, if a user-installable 3rd party program can make my
> regular git crash, I am scared what more it can do.
That is because the MSYS runtime is based on an old version of Cygwin,
and it uses the same dirty tricks to emulate fork. These tricks rely on
having a repeatably consistent memory layout for a process each time it
is started, and when third party tools add hooks that affect the load
order or otherwise screw with the layout, the fork emulation fails.
This is also why it is sometimes necessary to assign unique base
addresses to all libraries (rebaseall) in order to get fork emulation
working again.
So yes, it is unfortunate that some system tools can drastically affect
the ability of Cygwin and MSYS to function, but it's what we live with
to have fork/exec emulation. I see that there is work afoot to abstract
process creation so that hopefully this won't be as much a concern in
the near future.
Brian
^ permalink raw reply
* Re: Switching from CVS to GIT
From: David Kastrup @ 2007-10-15 19:26 UTC (permalink / raw)
To: Alex Riesen; +Cc: Michael Gebetsroither, make-w32, git
In-Reply-To: <20071015173832.GB2966@steel.home>
Alex Riesen <raa.lkml@gmail.com> writes:
> Michael Gebetsroither, Mon, Oct 15, 2007 02:46:11 +0200:
>> > - it is the only OS in the world with multi-root (/a/b/c and /a/b/c
>> > can be not the same, depending on what current "drive" is) and
>> > multi-cwd, which hasn't had formed itself into a problem yet, but
>> > surely will
>>
>> Thats true for linux too.
>> /a/b/c and /a/b/c can be 2 totally different files depending on the vfs
>> namespace you are one.
>
> No it is not. A process will always see the same filesystem object
> under the same path at the any given time (IOW, you can't have many
> namespaces active at the same time).
dak@lola:/home/tmp/emacs$ mkdir -p /tmp/a/b
dak@lola:/home/tmp/emacs$ cd /tmp/a/b
dak@lola:/tmp/a/b$ sudo mount --bind /usr /tmp/a
Password:
dak@lola:/tmp/a/b$ command pwd
/tmp/a/b
dak@lola:/tmp/a/b$ ls -l
total 0
dak@lola:/tmp/a/b$ ls -l /tmp/a/b
ls: /tmp/a/b: No such file or directory
dak@lola:/tmp/a/b$
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Johannes Schindelin @ 2007-10-15 19:27 UTC (permalink / raw)
To: git; +Cc: Alex Riesen, Eli Zaretskii, ae, tsuna
In-Reply-To: <4713BA89.633B86F2@dessent.net>
Hi,
On Mon, 15 Oct 2007, Brian Dessent wrote:
> Johannes Schindelin wrote:
>
> > My bigger concerns are the performance and stability. For example, I
> > had a very annoying problem on one of the machines I am testing
> > msysGit on. The problem was _only_ fixable by deactivating component
> > of Logitech's WebCam driver! Now, if a user-installable 3rd party
> > program can make my regular git crash, I am scared what more it can
> > do.
>
> That is because the MSYS runtime is based on an old version of Cygwin,
> and it uses the same dirty tricks to emulate fork. These tricks rely on
> having a repeatably consistent memory layout for a process each time it
> is started, and when third party tools add hooks that affect the load
> order or otherwise screw with the layout, the fork emulation fails. This
> is also why it is sometimes necessary to assign unique base addresses to
> all libraries (rebaseall) in order to get fork emulation working again.
Ah, thanks for the explanation! (I knew that this thread still had
something useful in it ;-)
> So yes, it is unfortunate that some system tools can drastically affect
> the ability of Cygwin and MSYS to function, but it's what we live with
> to have fork/exec emulation. I see that there is work afoot to abstract
> process creation so that hopefully this won't be as much a concern in
> the near future.
We never had the problem in git itself, since we never used fork() on
Windows. The problem lies in our usage of bash and perl.
Bash we can fix in the long run (this goes under the keyword
"builtinification" on the git list), but I do not see our reliance on Perl
going away, not for git {send-email,cvsimport,cvsexportcommit,svn}.
These are not too common operations, so common users will be able to do
without them.
However, if you rely on the CVS/SVN connectors, or send-email, and in any
case in the short run, you better run Git on Windows only when that funny
Logitech driver is disabled ;-)
Ciao,
Dscho
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Alex Riesen @ 2007-10-15 19:30 UTC (permalink / raw)
To: David Kastrup; +Cc: Michael Gebetsroither, git, make-w32
In-Reply-To: <85ejfwi3gr.fsf@lola.goethe.zz>
David Kastrup, Mon, Oct 15, 2007 21:26:44 +0200:
> Alex Riesen <raa.lkml@gmail.com> writes:
>
> > Michael Gebetsroither, Mon, Oct 15, 2007 02:46:11 +0200:
> >> > - it is the only OS in the world with multi-root (/a/b/c and /a/b/c
> >> > can be not the same, depending on what current "drive" is) and
> >> > multi-cwd, which hasn't had formed itself into a problem yet, but
> >> > surely will
> >>
> >> Thats true for linux too.
> >> /a/b/c and /a/b/c can be 2 totally different files depending on the vfs
> >> namespace you are one.
> >
> > No it is not. A process will always see the same filesystem object
> > under the same path at the any given time (IOW, you can't have many
> > namespaces active at the same time).
>
> dak@lola:/home/tmp/emacs$ mkdir -p /tmp/a/b
> dak@lola:/home/tmp/emacs$ cd /tmp/a/b
> dak@lola:/tmp/a/b$ sudo mount --bind /usr /tmp/a
Well don't do that in your repos (unless need that for something).
It is not like someone creates a distribution which does it
automagically all the time and you're forced to use that distribution.
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Alex Riesen @ 2007-10-15 19:34 UTC (permalink / raw)
To: Dave Korn; +Cc: 'Johannes Schindelin', ae, git, make-w32
In-Reply-To: <030301c80f58$d37b9710$2e08a8c0@CAM.ARTIMI.COM>
Dave Korn, Mon, Oct 15, 2007 20:25:55 +0200:
> On 15 October 2007 18:49, Alex Riesen wrote:
>
> > Johannes Schindelin, Mon, Oct 15, 2007 10:44:12 +0200:
> >> On Mon, 15 Oct 2007, Eli Zaretskii wrote:
> >>> Can you show a test case where this penalty is clearly visible? I'm
> >>> curious to see the numbers. TIA
> > ...
> >> Now, that is my _personal_ decision. If _you_ have no problem with
> >> Windows, just stick with it. (I always thought this goes without saying,
> >> but Windows users tend to be very religious about this issue, thinking
> >> just because I hate Windows that I want to make them switch. Hahaha, no.)
> >
> > They tend to be so exactly because they know how pathetic they are.
> > They just want to have something where they don't suck and do
> > everything to find it. And fail. Then they resort to graphics and
> > user-friendly interface.
>
> Translation: "I feel that I am superior to other people. This post has no
> content apart from me shooting my mouth off in an attempt to prove how much
> cleverer I am than anyone else. However apart from my self-love I have no
> contribution to make to the discussion."
It is interpretation, not translation. Wrong, too.
> This isn't slashdot. A computer is just a tool, and it's really *you* who
> are being pathetic, because you confuse a choice of mass-manufactured consumer
it is not a "choice". It is an accident. Like in "caused by careless driving".
> product with a statement about personal identity. Loyalty to your favourite
> brand is a game of one-upmanship suitable only for kids. You need to grow up.
Yep. Will do.
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Alex Riesen @ 2007-10-15 19:42 UTC (permalink / raw)
To: Brian Dessent; +Cc: Johannes Schindelin, git, Eli Zaretskii, ae, tsuna
In-Reply-To: <4713BA89.633B86F2@dessent.net>
Brian Dessent, Mon, Oct 15, 2007 21:07:53 +0200:
> Johannes Schindelin wrote:
> > My bigger concerns are the performance and stability. For example, I had
> > a very annoying problem on one of the machines I am testing msysGit on.
> > The problem was _only_ fixable by deactivating component of Logitech's
> > WebCam driver! Now, if a user-installable 3rd party program can make my
> > regular git crash, I am scared what more it can do.
>
> That is because the MSYS runtime is based on an old version of Cygwin,
> and it uses the same dirty tricks to emulate fork. These tricks rely on
> having a repeatably consistent memory layout for a process each time it
> is started, and when third party tools add hooks that affect the load
> order or otherwise screw with the layout, the fork emulation fails.
> This is also why it is sometimes necessary to assign unique base
> addresses to all libraries (rebaseall) in order to get fork emulation
> working again.
Hmm... Could the allocation of large contiguous blocks also lock the
system hard? For instance, I avoid starting the test suite on my XP
workstation at work: it locks up hard every time. W2k works.
The system has nothing unusual in it. Well, it has an antivirus
program (which hopefully stopped working after a series of crashes,
which is just as well), an NVidia card with native driver (which is
broken in its own usual ways). Maybe that's enough
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Eli Zaretskii @ 2007-10-15 19:48 UTC (permalink / raw)
To: Alex Riesen; +Cc: brian, Johannes.Schindelin, git, ae, tsuna
In-Reply-To: <20071015194214.GC15541@steel.home>
> Date: Mon, 15 Oct 2007 21:42:14 +0200
> From: Alex Riesen <raa.lkml@gmail.com>
> Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>, git@vger.kernel.org,
> Eli Zaretskii <eliz@gnu.org>, ae@op5.se, tsuna@lrde.epita.fr
>
> Hmm... Could the allocation of large contiguous blocks also lock the
> system hard?
No, not on XP.
> For instance, I avoid starting the test suite on my XP
> workstation at work: it locks up hard every time.
Sounds like a bug to me.
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Johannes Schindelin @ 2007-10-15 19:58 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Alex Riesen, brian, git, ae, tsuna
In-Reply-To: <u1wbwjh10.fsf@gnu.org>
Hi,
On Mon, 15 Oct 2007, Eli Zaretskii wrote:
> > From: Alex Riesen <raa.lkml@gmail.com>
>
> > For instance, I avoid starting the test suite on my XP workstation at
> > work: it locks up hard every time.
>
> Sounds like a bug to me.
To me, too. Alas, it works on W2k, so where is the bug?
Ciao,
Dscho
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Brian Dessent @ 2007-10-15 20:05 UTC (permalink / raw)
To: Alex Riesen; +Cc: Johannes Schindelin, git, Eli Zaretskii, ae, tsuna
In-Reply-To: <20071015194214.GC15541@steel.home>
Alex Riesen wrote:
> Hmm... Could the allocation of large contiguous blocks also lock the
> system hard? For instance, I avoid starting the test suite on my XP
> workstation at work: it locks up hard every time. W2k works.
> The system has nothing unusual in it. Well, it has an antivirus
> program (which hopefully stopped working after a series of crashes,
> which is just as well), an NVidia card with native driver (which is
> broken in its own usual ways). Maybe that's enough
In terms of the MSYS/Cygwin style of fork emulation, large memory
allocations shouldn't pose any real problem, but they will be slow as
the fork emulation has to manually replicate the state of the parent in
the child and this means copying memory extents. (Yes, horribly ugly,
no doubt about it, but it allows for porting.)
This emulation code is sensitive enough that the Cygwin list has begun
to maintain a list of software whose hooks/interference can cause Cygwin
apps to fail: <http://cygwin.com/ml/cygwin-talk/2007-q3/msg00174.html>.
Since MSYS is derived from the same code I see no reason why the list
wouldn't also implicate potential problems with binaries linked to the
MSYS runtime.
Johannes Schindelin wrote:
> We never had the problem in git itself, since we never used fork() on
> Windows. The problem lies in our usage of bash and perl.
>
> Bash we can fix in the long run (this goes under the keyword
> "builtinification" on the git list), but I do not see our reliance on Perl
> going away, not for git {send-email,cvsimport,cvsexportcommit,svn}.
> These are not too common operations, so common users will be able to do
> without them.
>
> However, if you rely on the CVS/SVN connectors, or send-email, and in any
> case in the short run, you better run Git on Windows only when that funny
> Logitech driver is disabled ;-)
Well, instead of using an MSYS build of Perl there's always ActiveState
Perl. I think you may be stuck on the shell though -- I don't know of
any ports of bash that aren't MSYS or Cygwin based. However I do think
there's a native port of zsh out there by the GnuWin32 project, which
when renamed as just "/bin/sh" might be suitable, but only if these
scripts don't use bash-isms. I have not tried this zsh myself and
speed/compatibility wise I'm not sure it's up to snuff.
Brian
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Johannes Schindelin @ 2007-10-15 20:19 UTC (permalink / raw)
To: git; +Cc: Alex Riesen, Eli Zaretskii, ae, tsuna
In-Reply-To: <4713C81F.A75FEFC2@dessent.net>
Hi,
On Mon, 15 Oct 2007, Brian Dessent wrote:
> Well, instead of using an MSYS build of Perl there's always ActiveState
> Perl.
No, but thanks no. You haven't been around long enough on this list to
count the issues, but it is known that ActiveState Perl is close to
Malbolge.
> I think you may be stuck on the shell though -- I don't know of any
> ports of bash that aren't MSYS or Cygwin based. However I do think
> there's a native port of zsh out there by the GnuWin32 project, which
> when renamed as just "/bin/sh" might be suitable, but only if these
> scripts don't use bash-isms. I have not tried this zsh myself and
> speed/compatibility wise I'm not sure it's up to snuff.
There is a port of BusyBox' dash, which is nearing completion. Once
Nguyen says it is ready enough, we will try to integrate it into msysGit.
Ciao,
Dscho
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Linus Torvalds @ 2007-10-15 20:24 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Alex Riesen, Eli Zaretskii, ae, tsuna
In-Reply-To: <Pine.LNX.4.64.0710152026260.25221@racer.site>
On Mon, 15 Oct 2007, Johannes Schindelin wrote:
>
> Bash we can fix in the long run (this goes under the keyword
> "builtinification" on the git list)
I thought busybox was being used for the core commands? Is ash not
complete/usable enough (with all the fixes git has had for broken shells)
to be used?
I do agree that perl looks unavoidable, but I thought the windows port
already avoided at least bash. Not true?
(or is it just that even with ash, you end up hitting all the same issues
with cygwin/msys?)
Linus
^ permalink raw reply
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