* Re: Switching from CVS to GIT
From: Eli Zaretskii @ 2007-10-15 6:08 UTC (permalink / raw)
To: David Brown; +Cc: raa.lkml, make-w32, Johannes.Schindelin, ae, git
In-Reply-To: <20071015000347.GA13033@old.davidb.org>
> Date: Sun, 14 Oct 2007 17:03:47 -0700
> From: David Brown <git@davidb.org>
> Cc: 'Andreas Ericsson' <ae@op5.se>, 'Alex Riesen' <raa.lkml@gmail.com>,
> 'git list' <git@vger.kernel.org>,
> 'Johannes Schindelin' <Johannes.Schindelin@gmx.de>,
> 'Make Windows' <make-w32@gnu.org>
>
> The MS exec* calls just concatenate all of the argv arguments, separating
> them with a space into a single buffer.
True.
> If you know what the library on the other end is doing to re-parse the
> arguments back into separate strings, it might be possible to quote things
> enough to handle names with spaces, but it is hard.
It's not hard, it's just a bit of work. And it needs to be done
exactly once.
^ permalink raw reply
* Re: [PATCH 0/7] Bisect dunno
From: David Symonds @ 2007-10-15 6:15 UTC (permalink / raw)
To: Marius Storm-Olsen
Cc: David Kastrup, Christian Couder, Wincent Colaiuta,
René Scharfe, Junio Hamano, Johannes Schindelin, git
In-Reply-To: <471302D2.6010405@trolltech.com>
On 15/10/2007, Marius Storm-Olsen <marius@trolltech.com> wrote:
> David Kastrup said the following on 14.10.2007 19:48:
> >
> > "unknown" clearly is much better than "dunno" though even if my own
> > favorite would be "undecided".
>
> What then about a good'ol programming favorite, "void"? :-)
"skip"? That would make semantic sense, right?
Dave.
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Johannes Sixt @ 2007-10-15 6:39 UTC (permalink / raw)
To: Benoit SIGOURE; +Cc: git list, Make Windows
In-Reply-To: <1773C6F0-87BE-4F3C-B68A-171E1F32E242@lrde.epita.fr>
Benoit SIGOURE schrieb:
> Context: GNU make seems to be willing to switch from CVS to ...
> something else.
>
> On Oct 14, 2007, at 6:57 PM, Paul Smith wrote:
>
>> [...] the big thing no one else seems to have addressed much in
>> other discussions I've seen is portability. It LOOKS like there are
>> native ports of GIT to MINGW, but I have no idea how complete and usable
>> they are. If someone who has a Windows system could look into that it
>> would be a big help.
>
> I think the best thing to do is to ask directly on the Git ML.
>
> Someone already pointed out that he'd like to use Git on Windows but
> doesn't want to install either Cygwin or MSYS. Is this possible, or
> will it be possible in the near future? Is it possible to use one of
> the various GUIs (git-gui, gitk, qgit) on Windows without requiring a
> POSIXish shell etc.?
FWIW, I'm using the MinGW port from cmd.exe, i.e. not from a posix shell, on
a *production* repository. gitk and git-gui work. Not all operations that I
regularly use are available[*] via the GUIs, like git-rebase or
non-fast-forwarding push, so the use of the command line is needed from time
to time.
Unfortunately, "Fetch" does not yet work[*] from within git-gui, so you have
to fall back to git-fetch on the command line.
Of course, the Posix toolset, including a shell, must still be installed
(and in my setup they are in the PATH), but you don't have to use it.
[*] Note the distinction between "not available" and "does not work".
-- Hannes
^ permalink raw reply
* Re: [PATCH 0/7] Bisect dunno
From: Johan Herland @ 2007-10-15 7:02 UTC (permalink / raw)
To: git
Cc: David Symonds, Marius Storm-Olsen, David Kastrup,
Christian Couder, Wincent Colaiuta, René Scharfe,
Junio Hamano, Johannes Schindelin
In-Reply-To: <ee77f5c20710142315j192b9f65m22d7980769a46cec@mail.gmail.com>
On Monday 15 October 2007, David Symonds wrote:
> On 15/10/2007, Marius Storm-Olsen <marius@trolltech.com> wrote:
> > David Kastrup said the following on 14.10.2007 19:48:
> > >
> > > "unknown" clearly is much better than "dunno" though even if my own
> > > favorite would be "undecided".
> >
> > What then about a good'ol programming favorite, "void"? :-)
>
> "skip"? That would make semantic sense, right?
...or we could go all spaghetti western, and call it "ugly".
(as in "git-bisect [the <good>, the <bad> and the <ugly>]")
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: git-svn and submodules
From: Benoit SIGOURE @ 2007-10-15 7:07 UTC (permalink / raw)
To: Eric Wong; +Cc: git list, Johannes Schindelin
In-Reply-To: <Pine.LNX.4.64.0710142359020.25221@racer.site>
[-- Attachment #1: Type: text/plain, Size: 2042 bytes --]
On Oct 15, 2007, at 12:59 AM, Johannes Schindelin wrote:
> Hi,
>
> On Sun, 14 Oct 2007, Eric Wong wrote:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>>
>>> While I have your attention: last weekend, I spoke to a guy from the
>>> ffmpeg project, and he said that the only thing preventing them from
>>> switching to git was the lack of svn:external support...
>>>
>>> (Of course I know that it is more difficult than that: ffmpeg itself
>>> is an svn:external of MPlayer, but maybe we can get both of them to
>>> switch ;-)
>>>
>>> Do you have any idea when/if you're coming around to add that to
>>> git-svn?
>>
>> Soonish, possibly within a next week, even. I have actually have
>> started a project (using git) that wants to use SVN-hosted
>> repositories
>> directly submodules; so the fact that I'll actually need something
>> like
>> it bodes well for getting it implemented :)
>
> Hehe. Thanks!
>
Thanks for making this another thread because I didn't read the
answers to that patch and I was going to try and implement this
(svn:externals via submodules) sooner or later. Hadn't I seen this,
we'd probably end up duplicating effort. Maybe I can help with the
implementation?
This week I'm probably going to start to dive in git-svn by
implementing simpler things first:
- git svn create-ignore (to create one .gitignore per directory
from the svn:ignore properties. This has the disadvantage of
committing the .gitignore during the next dcommit, but when you
import a repo with tons of ignores (>1000), using git svn show-ignore
to build .git/info/exclude is *not* a good idea, because things like
git-status will end up doing >1000 fnmatch *per file* in the repo,
which leads to git-status taking more than 4s on my Core2Duo 2Ghz 2G
RAM)
- git svn propget (to easily retrieve svn properties from withing
git-svn). git svn propset would be nice too, but I guess it's harder
to implement.
Cheers,
--
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: [PATCH] git-svn: respect Subversion's [auth] section configuration values
From: Eygene Ryabinkin @ 2007-10-15 7:17 UTC (permalink / raw)
To: Eric Wong; +Cc: Sam Vilain, git
In-Reply-To: <20071007214334.GA7442@untitled>
Eric, good day.
Sun, Oct 07, 2007 at 02:43:34PM -0700, Eric Wong wrote:
> > Great, thanks for the pointer! Eric, do you want me to produce
> > another patch or you'll correct mine?
>
> Go ahead and produce another patch. I haven't had much time to
> work on git lately.
OK, the patch will follow in the separate thread. I had embedded
"no warnings 'once'" both to my new code and to your code to get
rid of the $kill_stupid_warnings. I did it selectively to minimize
the impact of the "no warnings" pragma.
--
Eygene
^ permalink raw reply
* [PATCH] git-svn: use "no warnings 'once'" to disable false-positives
From: Eygene Ryabinkin @ 2007-10-15 7:19 UTC (permalink / raw)
To: git; +Cc: normalperson
Some variables coming from the Subversion's Perl bindings are used
in our code only once, so the interpreter warns us about it. These
warnings are false-positives, because the variables themselves are
initialized in the binding's guts, that are made by SWIG.
Credits to Sam Vilain for his note about "no warnings 'once'".
Signed-off-by: Eygene Ryabinkin <rea-git@codelabs.ru>
---
git-svn.perl | 86 +++++++++++++++++++++++++++------------------------------
1 files changed, 41 insertions(+), 45 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index f7ef421..39a70bf 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -2293,23 +2293,30 @@ sub ssl_server_trust {
my ($cred, $realm, $failures, $cert_info, $may_save, $pool) = @_;
$may_save = undef if $_no_auth_cache;
print STDERR "Error validating server certificate for '$realm':\n";
- if ($failures & $SVN::Auth::SSL::UNKNOWNCA) {
- print STDERR " - The certificate is not issued by a trusted ",
- "authority. Use the\n",
- " fingerprint to validate the certificate manually!\n";
- }
- if ($failures & $SVN::Auth::SSL::CNMISMATCH) {
- print STDERR " - The certificate hostname does not match.\n";
- }
- if ($failures & $SVN::Auth::SSL::NOTYETVALID) {
- print STDERR " - The certificate is not yet valid.\n";
- }
- if ($failures & $SVN::Auth::SSL::EXPIRED) {
- print STDERR " - The certificate has expired.\n";
- }
- if ($failures & $SVN::Auth::SSL::OTHER) {
- print STDERR " - The certificate has an unknown error.\n";
- }
+ { no warnings 'once';
+ # All variables SVN::Auth::SSL::* are used only once,
+ # so we're shutting up Perl warnings about this.
+ if ($failures & $SVN::Auth::SSL::UNKNOWNCA) {
+ print STDERR " - The certificate is not issued ",
+ "by a trusted authority. Use the\n",
+ " fingerprint to validate ",
+ "the certificate manually!\n";
+ }
+ if ($failures & $SVN::Auth::SSL::CNMISMATCH) {
+ print STDERR " - The certificate hostname ",
+ "does not match.\n";
+ }
+ if ($failures & $SVN::Auth::SSL::NOTYETVALID) {
+ print STDERR " - The certificate is not yet valid.\n";
+ }
+ if ($failures & $SVN::Auth::SSL::EXPIRED) {
+ print STDERR " - The certificate has expired.\n";
+ }
+ if ($failures & $SVN::Auth::SSL::OTHER) {
+ print STDERR " - The certificate has ",
+ "an unknown error.\n";
+ }
+ } # no warnings 'once'
printf STDERR
"Certificate information:\n".
" - Hostname: %s\n".
@@ -2393,20 +2400,6 @@ sub _read_password {
$password;
}
-package main;
-
-{
- my $kill_stupid_warnings = $SVN::Node::none.$SVN::Node::file.
- $SVN::Node::dir.$SVN::Node::unknown.
- $SVN::Node::none.$SVN::Node::file.
- $SVN::Node::dir.$SVN::Node::unknown.
- $SVN::Auth::SSL::CNMISMATCH.
- $SVN::Auth::SSL::NOTYETVALID.
- $SVN::Auth::SSL::EXPIRED.
- $SVN::Auth::SSL::UNKNOWNCA.
- $SVN::Auth::SSL::OTHER;
-}
-
package SVN::Git::Fetcher;
use vars qw/@ISA/;
use strict;
@@ -2823,16 +2816,20 @@ sub open_or_add_dir {
if (!defined $t) {
die "$full_path not known in r$self->{r} or we have a bug!\n";
}
- if ($t == $SVN::Node::none) {
- return $self->add_directory($full_path, $baton,
- undef, -1, $self->{pool});
- } elsif ($t == $SVN::Node::dir) {
- return $self->open_directory($full_path, $baton,
- $self->{r}, $self->{pool});
- }
- print STDERR "$full_path already exists in repository at ",
- "r$self->{r} and it is not a directory (",
- ($t == $SVN::Node::file ? 'file' : 'unknown'),"/$t)\n";
+ { no warnings 'once';
+ # SVN::Node::none and SVN::Node::file are used only once,
+ # so we're shutting up Perl's warnings about them.
+ if ($t == $SVN::Node::none) {
+ return $self->add_directory($full_path, $baton,
+ undef, -1, $self->{pool});
+ } elsif ($t == $SVN::Node::dir) {
+ return $self->open_directory($full_path, $baton,
+ $self->{r}, $self->{pool});
+ } # no warnings 'once'
+ print STDERR "$full_path already exists in repository at ",
+ "r$self->{r} and it is not a directory (",
+ ($t == $SVN::Node::file ? 'file' : 'unknown'),"/$t)\n";
+ } # no warnings 'once'
exit 1;
}
@@ -3053,12 +3050,11 @@ sub new {
$RA = undef;
my $dont_store_passwords = 1;
my $conf_t = ${$config}{'config'};
- {
+ { no warnings 'once';
# The usage of $SVN::_Core::SVN_CONFIG_* variables
# produces warnings that variables are used only once.
# I had not found the better way to shut them up, so
- # warnings are disabled in this block.
- no warnings;
+ # the warnings of type 'once' are disabled in this block.
if (SVN::_Core::svn_config_get_bool($conf_t,
$SVN::_Core::SVN_CONFIG_SECTION_AUTH,
$SVN::_Core::SVN_CONFIG_OPTION_STORE_PASSWORDS,
@@ -3073,7 +3069,7 @@ sub new {
1) == 0) {
$Git::SVN::Prompt::_no_auth_cache = 1;
}
- }
+ } # no warnings 'once'
my $self = SVN::Ra->new(url => $url, auth => $baton,
config => $config,
pool => SVN::Pool->new,
--
1.5.3.2
^ permalink raw reply related
* Re: git-fast-import crashes
From: Pierre Habouzit @ 2007-10-15 7:33 UTC (permalink / raw)
To: Shun Kei Leung; +Cc: git, Shawn O. Pearce
In-Reply-To: <e66701d40710142153o70a7b696r928491be437ac6d@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 916 bytes --]
On Mon, Oct 15, 2007 at 04:53:38AM +0000, Shun Kei Leung wrote:
> Hi,
>
> Sorry for the late reply. I was away from my computer in the weekend.
>
>
> Hi Pierre,
>
> I didn't try:
> http://git.madism.org/?p=git.git;a=commit;h=7406e83342cd445ac38c1753c5fce75377737e2f
>
> because the bad commit turns out to be b449f4c according to `git bisect'.
I don't get the reason for your "because" but so be it. The commit you
show is not obviously broken to me, especially not in fast-import.c, so
I'll need more input. Could you please run your test in valgrind and
report the output please? Or if the data to reproduce the bug are online
or shareable, it'd be great to share, so that I can reproduce the issue
here.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Steffen Prohaska @ 2007-10-15 7:56 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Johannes Schindelin, git, raa.lkml, ae, tsuna, make-w32
In-Reply-To: <E1IhJ4K-00086x-5U@fencepost.gnu.org>
On Oct 15, 2007, at 8:04 AM, Eli Zaretskii wrote:
>> Date: Mon, 15 Oct 2007 02:24:53 +0100 (BST)
>> From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
>> cc: Eli Zaretskii <eliz@gnu.org>, Alex Riesen
>> <raa.lkml@gmail.com>, ae@op5.se,
>> tsuna@lrde.epita.fr, make-w32@gnu.org
>>
>> To clarify: git works on Windows. Most of the time, that is. But
>> all
>> those changes that were necessary to go there have not yet found
>> their way
>> into the official git.git repository.
>
> I, for one, appreciate all the hard work invested in that.
>
> While we are at that: can you (or someone else) point me to
> instructions on how to build the MinGW port of GIT? I found a tarball
> of the MinGW-ported GIT (v1.5.3, I think), but what I don't seem to be
> able to find is some kind of HOWTO: what tools I need to have
> installed, how to configure them (if there are any special issues
> there), what command(s) to type, etc. Is there anything like that out
> there, or can someone post such instructions?
If you want to have a full working development environment, such that
you can start contributing to msysgit right away, and have no firewall
issues, go to
http://code.google.com/p/msysgit/
and install GitMe, currently
http://msysgit.googlecode.com/files/GitMe-0.4.2.exe
If you only care about an end-user setup, which contains only the git
binaries on your system, but no tools to compile them, stay tuned for
one or two days. We'll release an updated installer soon.
Steffen
^ permalink raw reply
* Re: git-fast-import crashes
From: Shun Kei Leung @ 2007-10-15 8:19 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git, Shawn O. Pearce
In-Reply-To: <20071015073307.GA1508@artemis.corp>
> I don't get the reason for your "because" but so be it.
Well, my reasoning was that the commit didn't touch the convert.c. But
after re-reading the patch, I think I should apply and test with the
patch again.
...
> Or if the data to reproduce the bug are online
> or shareable, it'd be great to share, so that I can reproduce the issue
> here.
The repository is private, and it is in maintenance mode for the rest
of today. I will get back to you tomorrow with updates.
Thanks & regards,
Kevin Leung
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Eli Zaretskii @ 2007-10-15 8:20 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Johannes.Schindelin, git, raa.lkml, ae, tsuna, make-w32
In-Reply-To: <AD60F584-7AAD-4083-9BA6-21F0D00D6D1D@zib.de>
> Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>, git@vger.kernel.org,
> raa.lkml@gmail.com, ae@op5.se, tsuna@lrde.epita.fr, make-w32@gnu.org
> From: Steffen Prohaska <prohaska@zib.de>
> Date: Mon, 15 Oct 2007 09:56:40 +0200
>
> > While we are at that: can you (or someone else) point me to
> > instructions on how to build the MinGW port of GIT? I found a tarball
> > of the MinGW-ported GIT (v1.5.3, I think), but what I don't seem to be
> > able to find is some kind of HOWTO: what tools I need to have
> > installed, how to configure them (if there are any special issues
> > there), what command(s) to type, etc. Is there anything like that out
> > there, or can someone post such instructions?
>
> If you want to have a full working development environment, such that
> you can start contributing to msysgit right away, and have no firewall
> issues, go to
>
> http://code.google.com/p/msysgit/
>
> and install GitMe, currently
>
> http://msysgit.googlecode.com/files/GitMe-0.4.2.exe
>
> If you only care about an end-user setup, which contains only the git
> binaries on your system, but no tools to compile them, stay tuned for
> one or two days. We'll release an updated installer soon.
Sorry I wasn't clear: I want neither. I don't think I will have
enough free time to become an active contributor to GIT any time
soon. OTOH, since binaries are not available (and I'd prefer a
tarball as opposed to an installer, to be more in control of what's
being installed and where), I asked about the development tools
(compiler and Binutils, obviously, but what else?) required to build
the source tarball with MinGW tools.
Do I understand correctly that building GIT currently requires MSYS?
That'd be unfortunate, at least for me.
Anyway, thanks for replying.
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Johannes Schindelin @ 2007-10-15 8:34 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: git, raa.lkml, ae, tsuna, make-w32
In-Reply-To: <u4pgtj9rs.fsf@gnu.org>
Hi,
On Mon, 15 Oct 2007, Eli Zaretskii wrote:
> No, you need to think in abstractions rather than POSIX-isms, and then
> let each platform implement those abstractions as appropriate.
Last time I checked, POSIX was already an abstraction, thankyouverymuch.
Anyway, this discussion gets out of hand. The question was: does Git work
on Windows natively, and the answer as far as you are concerned is: yes.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 0/7] Bisect dunno
From: David Kastrup @ 2007-10-15 8:25 UTC (permalink / raw)
To: git
In-Reply-To: <471302D2.6010405@trolltech.com>
Marius Storm-Olsen <marius@trolltech.com> writes:
> David Kastrup said the following on 14.10.2007 19:48:
>> Marius Storm-Olsen <marius@trolltech.com> writes:
>>
>>> Wincent Colaiuta said the following on 14.10.2007 18:35:
>>>
>>>> "undecided" sounds good to me. It should be clear to non-native
>>>> speakers of English (at least, clearer than "dunno").
>>> What about just "unknown"?
>>
>> I tend to nitpick to the degree of silliness when my own suggestions
>> are concerned, but "unknown" sounds to me like the state _before_ the
>> test. If a person says he is "undecided" about something that means
>> that he _has_ thought about it already. "Undecidable" might bring
>> this distinction across more strongly, but it is a more complicated
>> word and it insinuates that it is _impossible_ to come to a decision
>> regardless of the spent effort.
>>
>> "unknown" clearly is much better than "dunno" though even if my own
>> favorite would be "undecided".
>
> What then about a good'ol programming favorite, "void"? :-)
Huh? void is a type, not a value. void would insinuate that it was
wrong to ask the question, not that its answer could not be
determined.
> I agree that "unknown" might be a state even _before_ a person has
> determined if a case is good or bad (same for 'dunno' actually: "-
> Do you know if it works? - I dunno yet") When I think more about it,
> I really like "void"..
Well, I don't.
Basically, I would say that this seems to be so much a matter of
personal taste that we should at this point of time leave the decision
of how to pick this to Junio. Whether this gets resolved by vote or
by authority: seems like the fine lines are no longer worth the time
invested in discussing them.
--
David Kastrup
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Johannes Schindelin @ 2007-10-15 8:44 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: raa.lkml, ae, tsuna, git, make-w32
In-Reply-To: <E1IhIwR-0006be-Ki@fencepost.gnu.org>
Hi,
On Mon, 15 Oct 2007, Eli Zaretskii wrote:
> > Date: Mon, 15 Oct 2007 00:45:47 +0100 (BST)
> > From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> > cc: Alex Riesen <raa.lkml@gmail.com>, ae@op5.se, tsuna@lrde.epita.fr,
> > git@vger.kernel.org, make-w32@gnu.org
> >
> > The problem is not so much opening, but determining if an existing file
> > and a file in the index have the same name.
> >
> > For example, "README" in the index, but "readme" in the working directory,
> > will be handled as "deleted/untracked" by the current machinery. IOW git
> > will not know that what it gets from readdir() as "readme" really is the
> > same file as "README" in the index.
>
> That's because you think file names are simple strings and can be
> compared by simple string comparison.
Almost...
> This na?ve view is not true even on POSIX systems: "foo/bar" and
> "/a/b/foo/bar" can be the same file, as well as "/a/b/c/d" and "/x/y/z",
> given the right symlinks.
... not quite, ah ...
> But for some reason that eludes me, people who are accustomed to POSIX
> stop right there and in effect say "file names are strings, if we only
> make them absolute and resolve links".
... yes! There you have it. Absolute filenames, resolved by readlink()
are assumed to be the unique (!) identifiers for the contents.
_Note:_ absolute paths _without_ readlink() resolving are _still_ unique
identifiers; this time for files/symlinks.
Things like this utter rubbish that two different file names (which are
the keys in the keystore that a filesystem really is) make Windows'
filesystem operations so slow.
I wonder when Windows heads will realise that this "convenience" is just
another reason why Windows is easily outperformed by other OSes (yes, the
last one is a plural).
> > > > - no acceptable level of performance in filesystem and VFS
> > > > (readdir, stat, open and read/write are annoyingly slow)
> > >
> > > With what libraries? Native `stat' and `readdir' are quite fast.
> > > Perhaps you mean the ported glibc (libgw32c), where `readdir' is
> > > indeed painfully slow, but then you don't need to use it.
> >
> > No, native.
>
> Can you show a test case where this penalty is clearly visible? I'm
> curious to see the numbers. TIA
No, I cannot. I will not go and buy a copy of Windows just to show you
the numbers.
Since quite some time I only run Linux on my machine(s), and the reason
was a very unscientific experiment: I kept with the OS that did not freeze
and let me do nothing for more than one second.
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.)
Ciao,
Dscho
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Johannes Schindelin @ 2007-10-15 8:47 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Steffen Prohaska, git, raa.lkml, ae, tsuna, make-w32
In-Reply-To: <E1IhLBW-0006uw-19@fencepost.gnu.org>
Hi,
On Mon, 15 Oct 2007, Eli Zaretskii wrote:
> Do I understand correctly that building GIT currently requires MSYS?
> That'd be unfortunate, at least for me.
If you could make Git compile with Visual C++, that would be fabulous.
TIA,
Dscho
^ permalink raw reply
* Re: Switching from CVS to GIT
From: David Kastrup @ 2007-10-15 8:57 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0710150936070.25221@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Mon, 15 Oct 2007, Eli Zaretskii wrote:
>
>> > Date: Mon, 15 Oct 2007 00:45:47 +0100 (BST)
>> > From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
>> > cc: Alex Riesen <raa.lkml@gmail.com>, ae@op5.se, tsuna@lrde.epita.fr,
>> > git@vger.kernel.org, make-w32@gnu.org
>> >
>> > The problem is not so much opening, but determining if an existing file
>> > and a file in the index have the same name.
>> >
>> > For example, "README" in the index, but "readme" in the working directory,
>> > will be handled as "deleted/untracked" by the current machinery. IOW git
>> > will not know that what it gets from readdir() as "readme" really is the
>> > same file as "README" in the index.
>>
>> That's because you think file names are simple strings and can be
>> compared by simple string comparison.
>
> Almost...
>
>> This na?ve view is not true even on POSIX systems: "foo/bar" and
>> "/a/b/foo/bar" can be the same file, as well as "/a/b/c/d" and "/x/y/z",
>> given the right symlinks.
>
> ... not quite, ah ...
>
>> But for some reason that eludes me, people who are accustomed to POSIX
>> stop right there and in effect say "file names are strings, if we only
>> make them absolute and resolve links".
>
> ... yes! There you have it. Absolute filenames, resolved by
> readlink() are assumed to be the unique (!) identifiers for the
> contents.
They aren't. One can mount the same file system several times in
different places. In Linux, one can even mount directories and files
to several places at once. Most Unices also support some
case-insensitive file systems, and readlink does not canonicalize the
casing.
> _Note:_ absolute paths _without_ readlink() resolving are _still_
> unique identifiers; this time for files/symlinks.
Not even that. A unique identifier for files would imply that
touching the file does not affect, say, the access times of files with
other unique identifiers.
--
David Kastrup
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Benoit SIGOURE @ 2007-10-15 9:02 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Eli Zaretskii, git list, Make Windows
In-Reply-To: <Pine.LNX.4.64.0710150932560.25221@racer.site>
[-- Attachment #1: Type: text/plain, Size: 665 bytes --]
On Oct 15, 2007, at 10:34 AM, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 15 Oct 2007, Eli Zaretskii wrote:
>
>> No, you need to think in abstractions rather than POSIX-isms, and
>> then
>> let each platform implement those abstractions as appropriate.
>
> Last time I checked, POSIX was already an abstraction,
> thankyouverymuch.
But as Eli pointed out, it's not universal, so you need higher
abstractions on top of them.
> Anyway, this discussion gets out of hand.
Not at all, actually I think some interesting points were made,
including on the technical side of the thing.
--
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: [PATCH] git-add (-a|-u) and -n support
From: Michael Witten @ 2007-10-15 9:09 UTC (permalink / raw)
To: git; +Cc: Jeff King
In-Reply-To: <20071015042028.GB4844@coredump.intra.peff.net>
On 15 Oct 2007, at 12:20:28 AM, Jeff King wrote:
> Thank you for submitting a patch! However, please make sure you read
> SubmittingPatches carefully.
I apologize, though I got your first email about
Documentation/SubmittingPatches after I had sent
in this patch; I had gone rummaging around the homepage
for some information, but had found nothing special.
I just submitted a patch (properly!) to Petr Baudis
to add a link to that documentation on the main page.
> -Peff "policing the list with an iron fist in Junio's absence" King
Don't worry, I didn't take it personally ;-)
Sincerely,
Michael Witten
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Steffen Prohaska @ 2007-10-15 9:23 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Johannes.Schindelin, git, raa.lkml, ae, tsuna, make-w32
In-Reply-To: <E1IhLBW-0006uw-19@fencepost.gnu.org>
On Oct 15, 2007, at 10:20 AM, Eli Zaretskii wrote:
>> Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
>> git@vger.kernel.org,
>> raa.lkml@gmail.com, ae@op5.se, tsuna@lrde.epita.fr, make-
>> w32@gnu.org
>> From: Steffen Prohaska <prohaska@zib.de>
>> Date: Mon, 15 Oct 2007 09:56:40 +0200
>>
>>> While we are at that: can you (or someone else) point me to
>>> instructions on how to build the MinGW port of GIT? I found a
>>> tarball
>>> of the MinGW-ported GIT (v1.5.3, I think), but what I don't seem
>>> to be
>>> able to find is some kind of HOWTO: what tools I need to have
>>> installed, how to configure them (if there are any special issues
>>> there), what command(s) to type, etc. Is there anything like
>>> that out
>>> there, or can someone post such instructions?
>>
>> If you want to have a full working development environment, such that
>> you can start contributing to msysgit right away, and have no
>> firewall
>> issues, go to
>>
>> http://code.google.com/p/msysgit/
>>
>> and install GitMe, currently
>>
>> http://msysgit.googlecode.com/files/GitMe-0.4.2.exe
>>
>> If you only care about an end-user setup, which contains only the git
>> binaries on your system, but no tools to compile them, stay tuned for
>> one or two days. We'll release an updated installer soon.
>
> Sorry I wasn't clear: I want neither. I don't think I will have
> enough free time to become an active contributor to GIT any time
> soon. OTOH, since binaries are not available (and I'd prefer a
> tarball as opposed to an installer, to be more in control of what's
> being installed and where),
Ok, so I uploaded the most recent preview of the installer to
http://msysgit.googlecode.com/files/WinGit-1.5.3-preview20071010.exe
Note, we're about to release an updated version soon. Personally,
I don't plan to put work in providing tar balls. A working installer
has higher priority for me.
> I asked about the development tools
> (compiler and Binutils, obviously, but what else?) required to build
> the source tarball with MinGW tools.
>
> Do I understand correctly that building GIT currently requires MSYS?
> That'd be unfortunate, at least for me.
msysgit's GitMe contains all tools from MSYS required to build git.
It also clones the git source and compiles it. It doesn't install
anything outside the folder that you chose upon installation.
I strongly believe it is the easiest way to compile git from source.
Steffen
^ permalink raw reply
* Re: [PATCH 0/7] Bisect dunno
From: Wincent Colaiuta @ 2007-10-15 9:31 UTC (permalink / raw)
To: Johan Herland
Cc: git, David Symonds, Marius Storm-Olsen, David Kastrup,
Christian Couder, René Scharfe, Junio Hamano,
Johannes Schindelin
In-Reply-To: <200710150902.52653.johan@herland.net>
El 15/10/2007, a las 9:02, Johan Herland escribió:
> On Monday 15 October 2007, David Symonds wrote:
>> On 15/10/2007, Marius Storm-Olsen <marius@trolltech.com> wrote:
>>> David Kastrup said the following on 14.10.2007 19:48:
>>>>
>>>> "unknown" clearly is much better than "dunno" though even if my own
>>>> favorite would be "undecided".
>>>
>>> What then about a good'ol programming favorite, "void"? :-)
>>
>> "skip"? That would make semantic sense, right?
>
> ...or we could go all spaghetti western, and call it "ugly".
>
> (as in "git-bisect [the <good>, the <bad> and the <ugly>]")
<personal opinion>
Yes, it's funny, but I don't think an SCM interface is a place for
jokes or puns. Git already has one big tongue-in-cheek attribute:
it's name, so let's leave it at that.
</personal opinion>
Cheers,
Wincent
^ permalink raw reply
* [PATCH 0/2] gitk: Added support for OS X mouse wheel
From: Jonathan del Strother @ 2007-10-15 9:33 UTC (permalink / raw)
To: git
In-Reply-To: <8c5c35580710141727k4bbd2bgc2292cfcc6f97c4a@mail.gmail.com>
On 15 Oct 2007, at 01:27, Lars Hjemli wrote:
> Your patch has been mangled, probably by your MUA.
>
> Also, these -/+ 4 lines seem to only change tab into spaces: please
> send such cleanups in a separate patch
Alright, let's try again. First patch fixes the mouse wheel, second patch fixes the weird indentation
^ permalink raw reply
* [PATCH 1/2] gitk: Added support for OS X mouse wheel
From: Jonathan del Strother @ 2007-10-15 9:33 UTC (permalink / raw)
To: git; +Cc: Jonathan del Strother
In-Reply-To: <8c5c35580710141727k4bbd2bgc2292cfcc6f97c4a@mail.gmail.com>
From: Jonathan del Strother <jon.delStrother@bestbefore.tv>
(Väinö Järvelä supplied this patch a while ago for 1.5.2. It no longer
applied cleanly, so I'm reposting it.)
MacBook doesn't seem to recognize MouseRelease-4 and -5 events, at all.
So i added a support for the MouseWheel event, which i limited to Tcl/tk
aqua, as i couldn't test it neither on Linux or Windows. Tcl/tk needs to
be updated from the version that is shipped with OS X 10.4 Tiger, for
this patch to work.
Signed-off-by: Jonathan del Strother <jon.delStrother@bestbefore.tv>
---
gitk | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/gitk b/gitk
index 300fdce..ee2a6f5 100755
--- a/gitk
+++ b/gitk
@@ -843,6 +843,12 @@ proc makewindow {} {
} else {
bindall <ButtonRelease-4> "allcanvs yview scroll -5 units"
bindall <ButtonRelease-5> "allcanvs yview scroll 5 units"
+ if {[tk windowingsystem] eq "aqua"} {
+ bindall <MouseWheel> {
+ set delta [expr {- (%D)}]
+ allcanvs yview scroll $delta units
+ }
+ }
}
bindall <2> "canvscan mark %W %x %y"
bindall <B2-Motion> "canvscan dragto %W %x %y"
--
1.5.3.1
^ permalink raw reply related
* [PATCH 2/2] Fixing gitk indentation
From: Jonathan del Strother @ 2007-10-15 9:33 UTC (permalink / raw)
To: git; +Cc: Jonathan del Strother
In-Reply-To: <8c5c35580710141727k4bbd2bgc2292cfcc6f97c4a@mail.gmail.com>
From: Jonathan del Strother <jon.delStrother@bestbefore.tv>
Just tweaking some minor indentation issues in gitk
Signed-off-by: Jonathan del Strother <jon.delStrother@bestbefore.tv>
---
gitk | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/gitk b/gitk
index ee2a6f5..9b3e627 100755
--- a/gitk
+++ b/gitk
@@ -838,11 +838,11 @@ proc makewindow {} {
bindall <1> {selcanvline %W %x %y}
#bindall <B1-Motion> {selcanvline %W %x %y}
if {[tk windowingsystem] == "win32"} {
- bind . <MouseWheel> { windows_mousewheel_redirector %W %X %Y %D }
- bind $ctext <MouseWheel> { windows_mousewheel_redirector %W %X %Y %D ; break }
+ bind . <MouseWheel> { windows_mousewheel_redirector %W %X %Y %D }
+ bind $ctext <MouseWheel> { windows_mousewheel_redirector %W %X %Y %D ; break }
} else {
- bindall <ButtonRelease-4> "allcanvs yview scroll -5 units"
- bindall <ButtonRelease-5> "allcanvs yview scroll 5 units"
+ bindall <ButtonRelease-4> "allcanvs yview scroll -5 units"
+ bindall <ButtonRelease-5> "allcanvs yview scroll 5 units"
if {[tk windowingsystem] eq "aqua"} {
bindall <MouseWheel> {
set delta [expr {- (%D)}]
--
1.5.3.1
^ permalink raw reply related
* Re: [PATCH] git-rebase: document suppression of duplicate commits
From: Michael Witten @ 2007-10-15 9:47 UTC (permalink / raw)
To: git; +Cc: Jeff King
In-Reply-To: <20071015044730.GA12118@coredump.intra.peff.net>
On 15 Oct 2007, at 12:47:30 AM, Jeff King wrote:
> On Sat, Oct 13, 2007 at 07:04:52PM -0400, Michael Witten wrote:
>> I can make a patch, but at the moment I'm swamped and I don't want to
>> think about doing that.
>
> And whoever said procrastination didn't get things done?
:-)
Thanks.
I'm pretty bad at setting priories, so I apologize for
saying I'm swamped and then turning around to submit
other patches.
Sincerely,
Michael Witten
^ permalink raw reply
* Re: git-svn and submodules
From: Andreas Ericsson @ 2007-10-15 10:00 UTC (permalink / raw)
To: Benoit SIGOURE; +Cc: Eric Wong, git list, Johannes Schindelin
In-Reply-To: <05CAB148-56ED-4FF1-8AAB-4BA2A0B70C2C@lrde.epita.fr>
Benoit SIGOURE wrote:
> - git svn create-ignore (to create one .gitignore per directory from
> the svn:ignore properties. This has the disadvantage of committing the
> .gitignore during the next dcommit, but when you import a repo with tons
> of ignores (>1000), using git svn show-ignore to build .git/info/exclude
> is *not* a good idea, because things like git-status will end up doing
> >1000 fnmatch *per file* in the repo, which leads to git-status taking
> more than 4s on my Core2Duo 2Ghz 2G RAM)
How spoiled we are. I just ran cvs status on a checkout of a repo located
on a server in the local network. It took 6 seconds to complete :P
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ 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