* [PATCH] git-rebase: document suppression of duplicate commits
From: Jeff King @ 2007-10-15 4:47 UTC (permalink / raw)
To: Michael Witten; +Cc: git, Lars Hjemli
git-rebase uses format-patch's --ignore-if-in-upstream
option, but we never document the user-visible behavior. The
example is placed near the top of the example list rather
than at the bottom because it is:
a. a simple example
b. a reasonably common scenario for many projects (mail
some patches which get accepted upstream, then rebase)
Signed-off-by: Jeff King <peff@peff.net>
---
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?
Documentation/git-rebase.txt | 25 ++++++++++++++++++++++++-
1 files changed, 24 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index e8e7579..b6efb48 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -28,7 +28,10 @@ The current branch is reset to <upstream>, or <newbase> if the
`git reset --hard <upstream>` (or <newbase>).
The commits that were previously saved into the temporary area are
-then reapplied to the current branch, one by one, in order.
+then reapplied to the current branch, one by one, in order. Note that
+any commits in HEAD which introduce the same textual changes as a commit
+in <upstream>..HEAD are omitted (i.e., a patch already accepted upstream
+with a different commit message or timestamp will be skipped).
It is possible that a merge failure will prevent this process from being
completely automatic. You will have to resolve any such merge failure
@@ -62,6 +65,26 @@ would be:
The latter form is just a short-hand of `git checkout topic`
followed by `git rebase master`.
+If the upstream branch already contains a change you have made (e.g.,
+because you mailed a patch which was applied upstream), then that commit
+will be skipped. For example, running `git-rebase master` on the
+following history (in which A' and A introduce the same set of changes,
+but have different committer information):
+
+------------
+ A---B---C topic
+ /
+ D---E---A'---F master
+------------
+
+will result in:
+
+------------
+ B'---C' topic
+ /
+ D---E---A'---F master
+------------
+
Here is how you would transplant a topic branch based on one
branch to another, to pretend that you forked the topic branch
from the latter branch, using `rebase --onto`.
--
1.5.3.4.1155.gfe96ee-dirty
^ permalink raw reply related
* Re: git-fast-import crashes
From: Shun Kei Leung @ 2007-10-15 4:53 UTC (permalink / raw)
To: git; +Cc: Pierre Habouzit, Shawn O. Pearce
In-Reply-To: <20071013075027.GD7110@artemis.corp>
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'.
Hi Shawn,
I include the output of `git count-objects -v' for your information:
count: 104
size: 552
in-pack: 10652
packs: 12
prune-packable: 0
garbage: 0
Regards,
Kevin Leung
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Martin Langhoff @ 2007-10-15 5:35 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Benoit SIGOURE, git list, Eli Zaretskii, Make Windows
In-Reply-To: <Pine.LNX.4.64.0710141916510.25221@racer.site>
On 10/15/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> There is msysGit. This project is nearing to its first beta, being
> self-hosted since mid-August IIRC.
I've been using it recently, I have to say it's pretty impressive -
you can use it from cmd.com or from a bash window (courtesy of the
msys environment included). The GUIs that ship with git are there
(git-gui, gitk).
I use gitk extensively, and it works *great*. My work-style is of a
shell window for status/diff/commit actions and one or more gitk
windows for browsing of proj history. You can use git-gui for a visual
status/git/commit workflow, or qgit. qgit is more integrated, and
might feel more "at home" for users that expect something more
MDI-ish.
cheers.
martin
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Martin Langhoff @ 2007-10-15 5:43 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Johannes Schindelin, Benoit SIGOURE, git list, Eli Zaretskii,
Make Windows
In-Reply-To: <47126957.1020204@op5.se>
On 10/15/07, Andreas Ericsson <ae@op5.se> wrote:
> > And I have to disagree strongly with the "black": In msysGit (which brings
> > its own minimal version of MSys), it is very smooth.
> >
>
> Oh? I didn't know that. Windows and its unixifying toolboxes is unknown
> territory to me, as I happily spend all my time on various unices.
I'm a unix-head too. Last couple of weeks had to work on a windows
server, and installed msysGit. Very impressed - all the needed
dependencies are there, from an end-user POV it "just works".
> I was under the impression that the windows port suffers from Windows'
> lack of a proper fork() and friends and that a proper library would
> help solving those problems. Perhaps I was misinformed.
I think msys' DLLs might be doing what cygwin does, an emulated fork.
A quite surprising thing is that msysgit manages to be very fast. Not
as fast as the same git, same hw running on a recent Linux, but pretty
usable fast for a tree with a few thousand files. Earlier/other git
ports to win32 are pretty slow (still faster than svn and friends, but
slooow).
cheers,
m
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Eli Zaretskii @ 2007-10-15 5:56 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: ae, raa.lkml, git, make-w32
In-Reply-To: <Pine.LNX.4.64.0710150039120.25221@racer.site>
> 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. 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.
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". Instead, recognize that file
names are not strings (although they inherit some of the strings'
traits), and think in terms of "file-name comparison" abstraction;
then everything will fall in place just fine.
> > > - 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
^ permalink raw reply
* Re: [PATCH 0/7] Bisect dunno
From: Marius Storm-Olsen @ 2007-10-15 6:04 UTC (permalink / raw)
To: David Kastrup
Cc: Christian Couder, Wincent Colaiuta, René Scharfe,
Junio Hamano, Johannes Schindelin, git
In-Reply-To: <85d4vhlh8y.fsf@lola.goethe.zz>
[-- Attachment #1: Type: text/plain, Size: 1355 bytes --]
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"? :-)
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"..
"Argh, this test is void, because someone messed with it"
"We can't make heads or tails of this one, so it must be void"
--
.marius
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Eli Zaretskii @ 2007-10-15 6:04 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: ae, raa.lkml, git, make-w32
In-Reply-To: <Pine.LNX.4.64.0710150223230.25221@racer.site>
> 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?
TIA
^ permalink raw reply
* 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
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