* Re: Make "git clone" less of a deathly quiet experience
From: Linus Torvalds @ 2006-02-11 4:37 UTC (permalink / raw)
To: Git Mailing List, Junio C Hamano, Petr Baudis
In-Reply-To: <Pine.LNX.4.64.0602102018250.3691@g5.osdl.org>
On Fri, 10 Feb 2006, Linus Torvalds wrote:
>
> Instead, it at least prints out how much data it's gotten, and what the
> packign speed is. Which makes the user realize that it's actually doing
> something useful instead of sitting there silently (and if the recipient
> knows how large the final result is, he can at least make a guess about
> when it migt be done).
Btw, we should print out the other "stages" too - the checkout in
particular can be a big part of the overhead, and it would probably make
sense to tell people about the fact that "hey, now we're checking the
result out, we're not actually trying to destroy your disk".
Quite often, the way to make users happy is not by being impossibly fast
or beautiful or otherwise wonderful, but by just _managing_ their
expectations, so that they don't say "that's some slow crud", but instead
say "Ok, it's a nice program, and it's doing a lot of hard work for me".
It takes me 15 minutes to clone a kernel repo over the network. Once I can
see that most of that is getting a 106MB pack-file at 146 kB/s, I say "ok,
that's fairly reasonable".
Linus
^ permalink raw reply
* Make "git clone" less of a deathly quiet experience
From: Linus Torvalds @ 2006-02-11 4:31 UTC (permalink / raw)
To: Git Mailing List, Junio C Hamano, Petr Baudis
I was on IRC today (which is definitely not normal, but hey, I tried it),
and somebody was complaining about how horribly slow "git clone" was on
the WineHQ repository.
The WineHQ git repo is actually fairly big: 120+MB packed, 220+ thousand
objects. So creating the pack is actually a big operation, and yes, it's
too slow. We should be better at it, and it would be good if the pack-file
generation were much faster.
However, it turns out that the "slow" git-pack-objects was only using up
2.3% of CPU time. The fact is, the primary reason it took a long time is
that even packed, it had to get 120 MB of data. So in this case, it
appears that the fact that it uses a lot of CPU is actually a good
trade-off, because the damn thing would have been even slower if it hadn't
been packed.
(Of course, pre-generated packs would be good regardless)
Anyway, what _really_ made for a pissed-off user was that "git clone" was
just very very silent all the time. No updates on what the hell it was
doing. Was it working at all? Was something broken? Is git just a piece of
cr*p? But "git clone" would not say a peep about it.
It used to be that "git-unpack-objects" would give nice percentages, but
now that we don't unpack the initial clone pack any more, it doesn't. And
I'd love to do that nice percentage view in the pack objects downloader
too, but the thing doesn't even read the pack header, much less know how
much it's going to get, so I was lazy and didn't.
Instead, it at least prints out how much data it's gotten, and what the
packign speed is. Which makes the user realize that it's actually doing
something useful instead of sitting there silently (and if the recipient
knows how large the final result is, he can at least make a guess about
when it migt be done).
So with this patch, I get something like this on my DSL line:
[torvalds@g5 ~]$ time git clone master.kernel.org:/pub/scm/linux/kernel/git/torvalds/linux-2.6 clone-test
Packing 188543 objects
48.398MB (154 kB/s)
where even the speed approximation seem sto be roughtly correct (even
though my algorithm is a truly stupid one, and only really gives "speed in
the last half second or so").
Anyway, _something_ like this is definitely needed. It could certainly be
better (if it showed the same kind of thing that git-unpack-objects did,
that would be much nicer, but would require parsing the object stream as
it comes in). But this is big step forward, I think.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
Comments? Hate-mail? Improvements?
diff --git a/cache.h b/cache.h
index bdbe2d6..c255421 100644
--- a/cache.h
+++ b/cache.h
@@ -348,6 +348,6 @@ extern int copy_fd(int ifd, int ofd);
/* Finish off pack transfer receiving end */
extern int receive_unpack_pack(int fd[2], const char *me, int quiet);
-extern int receive_keep_pack(int fd[2], const char *me);
+extern int receive_keep_pack(int fd[2], const char *me, int quiet);
#endif /* CACHE_H */
diff --git a/clone-pack.c b/clone-pack.c
index f634431..719e1c4 100644
--- a/clone-pack.c
+++ b/clone-pack.c
@@ -6,6 +6,8 @@ static const char clone_pack_usage[] =
"git-clone-pack [--exec=<git-upload-pack>] [<host>:]<directory> [<heads>]*";
static const char *exec = "git-upload-pack";
+static int quiet = 0;
+
static void clone_handshake(int fd[2], struct ref *ref)
{
unsigned char sha1[20];
@@ -123,7 +125,9 @@ static int clone_pack(int fd[2], int nr_
}
clone_handshake(fd, refs);
- status = receive_keep_pack(fd, "git-clone-pack");
+ if (!quiet)
+ fprintf(stderr, "Generating pack ...\r");
+ status = receive_keep_pack(fd, "git-clone-pack", quiet);
if (!status) {
if (nr_match == 0)
@@ -154,8 +158,10 @@ int main(int argc, char **argv)
char *arg = argv[i];
if (*arg == '-') {
- if (!strcmp("-q", arg))
+ if (!strcmp("-q", arg)) {
+ quiet = 1;
continue;
+ }
if (!strncmp("--exec=", arg, 7)) {
exec = arg + 7;
continue;
diff --git a/fetch-clone.c b/fetch-clone.c
index 859f400..b67d976 100644
--- a/fetch-clone.c
+++ b/fetch-clone.c
@@ -1,6 +1,7 @@
#include "cache.h"
#include "exec_cmd.h"
#include <sys/wait.h>
+#include <sys/time.h>
static int finish_pack(const char *pack_tmp_name, const char *me)
{
@@ -129,10 +130,12 @@ int receive_unpack_pack(int fd[2], const
die("git-unpack-objects died of unnatural causes %d", status);
}
-int receive_keep_pack(int fd[2], const char *me)
+int receive_keep_pack(int fd[2], const char *me, int quiet)
{
char tmpfile[PATH_MAX];
int ofd, ifd;
+ unsigned long total;
+ static struct timeval prev_tv;
ifd = fd[0];
snprintf(tmpfile, sizeof(tmpfile),
@@ -141,6 +144,8 @@ int receive_keep_pack(int fd[2], const c
if (ofd < 0)
return error("unable to create temporary file %s", tmpfile);
+ gettimeofday(&prev_tv, NULL);
+ total = 0;
while (1) {
char buf[8192];
ssize_t sz, wsz, pos;
@@ -165,6 +170,27 @@ int receive_keep_pack(int fd[2], const c
}
pos += wsz;
}
+ total += sz;
+ if (!quiet) {
+ static unsigned long last;
+ struct timeval tv;
+ unsigned long diff = total - last;
+ /* not really "msecs", but a power-of-two millisec (1/1024th of a sec) */
+ unsigned long msecs;
+
+ gettimeofday(&tv, NULL);
+ msecs = tv.tv_sec - prev_tv.tv_sec;
+ msecs <<= 10;
+ msecs += (int)(tv.tv_usec - prev_tv.tv_usec) >> 10;
+ if (msecs > 500) {
+ prev_tv = tv;
+ last = total;
+ fprintf(stderr, "%4lu.%03luMB (%lu kB/s) \r",
+ total >> 20,
+ 1000*((total >> 10) & 1023)>>10,
+ diff / msecs );
+ }
+ }
}
close(ofd);
return finish_pack(tmpfile, me);
diff --git a/fetch-pack.c b/fetch-pack.c
index 27f5d2a..aa6f42a 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -378,7 +378,7 @@ static int fetch_pack(int fd[2], int nr_
fprintf(stderr, "warning: no common commits\n");
if (keep_pack)
- status = receive_keep_pack(fd, "git-fetch-pack");
+ status = receive_keep_pack(fd, "git-fetch-pack", quiet);
else
status = receive_unpack_pack(fd, "git-fetch-pack", quiet);
^ permalink raw reply related
* Re: Git 1.1.6.g4d44 make test FAILURE report
From: Junio C Hamano @ 2006-02-11 4:14 UTC (permalink / raw)
To: gitzilla; +Cc: git
In-Reply-To: <43ED5F60.1010408@gmail.com>
A Large Angry SCM <gitzilla@gmail.com> writes:
> It also breaks a lot of commands not related to making commits;
> git-fetch for one.
git-sh-setup one is easy to fix. We could say something equally
silly like this instead:
diff --git a/git-sh-setup.sh b/git-sh-setup.sh
index 1e638e4..157c7e4 100755
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh
@@ -41,7 +41,11 @@ then
: ${GIT_OBJECT_DIRECTORY="$GIT_DIR/objects"}
# Make sure we are in a valid repository of a vintage we understand.
- GIT_DIR="$GIT_DIR" git-var GIT_AUTHOR_IDENT >/dev/null || exit
+ GIT_DIR="$GIT_DIR" git repo-config --get core.nosuch >/dev/null
+ if test $? == 128
+ then
+ exit
+ fi
else
GIT_DIR=$(git-rev-parse --git-dir) || exit
fi
The only thing that code cares about is to use a relatively
cheap command to examine "$GIT_DIR/config" to make sure that the
respository format version recorded in the file is of old enough
vintage we understand; the command to cause .git/config to be
read does not have to be git-var.
So after nixing that one, the remaining users all look like they
do want something reasonable from the user anyway, so for them
git-var that fails when the user has not fixed the unusable
gecos is a desirable thing.
git grep -n git-var '*.sh'
shows:
git-am, git-applypatch, git-format-patch::
use it to add sign-off by the user.
git-commit, git-tag::
use it to record the user identity.
git-pull::
this uses git-var-l which is unfortunate. We should
be able to use git-repo-config instead. Patches
welcome.
^ permalink raw reply related
* Re: [PATCH] Don't send copies to the From: address
From: Junio C Hamano @ 2006-02-11 3:55 UTC (permalink / raw)
To: Christian Biesinger; +Cc: git, Ryan Anderson, Greg Kroah-Hartman
In-Reply-To: <11396260373307-git-send-email-cbiesinger@web.de>
Christian Biesinger <cbiesinger@web.de> writes:
> Sending copies to the from address is pointless.
Ryan, care to defend this part of the code? This behaviour
might have been inherited from Greg's original version.
I cannot speak for Ryan or Greg, but I think the script
deliberately does this to support this workflow:
(1) The original author sends in a patch to a subsystem
maintainer;
(2) The subsystem maintainer applies the patch to her tree,
perhaps with her own sign-off and sign-offs by other people
collected from the list. She examines it and says this
patch is good;
(3) The commit is formatted and sent to higher level of the
foodchain. The message is CC'ed to interested parties in
order to notify that the patch progressed in the
foodchain.
Me, personally I do not like CC: to people on the signed-off-by
list, but dropping a note to From: person makes perfect sense to
me, if it is to notify the progress of the patch.
What you are after _might_ be not CC'ing it if it was your own
patch. Maybe something like this would help, but even if that
is the case I suspect many people want to CC herself so it needs
to be an optional feature.
-- >8 --
[PATCH] Do not CC me
---
git diff
diff --git a/git-send-email.perl b/git-send-email.perl
index 3f1b3ca..a02e2f8 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -343,7 +343,7 @@ foreach my $t (@files) {
}
close F;
- $cc = join(", ", unique_email_list(@cc));
+ $cc = join(", ", unique_email_list(grep { $_ ne $from } @cc));
send_message();
^ permalink raw reply related
* Re: Git 1.1.6.g4d44 make test FAILURE report
From: A Large Angry SCM @ 2006-02-11 3:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvevmtza4.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> A Large Angry SCM <gitzilla@gmail.com> writes:
>
>>Also, git-var complains when used by an account with an empty gcos
>>field; thereby, breaking all the non-C git commands even when the user
>>is not committing.
>>
>>If the _intent_ was to force commiters and author names in commits,
>>why was the test not placed only in commit-tree.c?
>
> git-var was more or less intentional. Scripts such as
> git-applypatch, git-commit and git-tag use the command to grab
> COMMITTER_IDENT to generate sign-off line and tagger information
> when asked, and commit-tree.c changes alone would not catch
> them.
>
> A user eventually would make commit so it may not be a too bad
> to _strongly_ encourage setting up these environment variables,
> by being nasty ;-). I agree it would be _very_ annoying until
> you either fix your gecos and/or environment.
>
> Ideas welcome.
It also breaks a lot of commands not related to making commits;
git-fetch for one.
^ permalink raw reply
* [PATCH 2/3] Use File::Find rather than find and xargs in git-archimport
From: Jason Riedy @ 2006-02-11 2:52 UTC (permalink / raw)
To: git
git-archimport uses find and xargs directly to find and apply patches.
Replace these by File::Find and save one call to find. Tested on
Solaris 8 with a quite complex, interrelated set of Arch repos.
Hopefully handles {arch} subdirectories correctly. Thanks to Randal
Schwartz for pointing out the problem.
Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu>
---
git-archimport.perl | 39 +++++++++++++++++++++++++++++----------
1 files changed, 29 insertions(+), 10 deletions(-)
8e7119df3d59da189baa741d44b04e7c8da2c421
diff --git a/git-archimport.perl b/git-archimport.perl
index 841738d..ffdf742 100755
--- a/git-archimport.perl
+++ b/git-archimport.perl
@@ -60,6 +60,7 @@ use Getopt::Std;
use File::Temp qw(tempdir);
use File::Path qw(mkpath rmtree);
use File::Basename qw(basename dirname);
+use File::Find;
use Data::Dumper qw/ Dumper /;
use IPC::Open2;
@@ -664,17 +665,35 @@ sub apply_cset {
# get the changeset
safe_pipe_capture($TLA,'get-changeset',$ps->{id},"$tmp/changeset");
die "Cannot get changeset: $!" if $?;
-
+
+ my @patchlist;
+ my $wanted_patches = sub {
+ # We want all those non-empty *.patch files that do not modify
+ # arch state. The preprocess argument strips out {arch}.
+ if (-f && !-z && /^.*\.patch$/) {
+ push @patchlist, $File::Find::name;
+ }
+ if ($File::Find::dir =~ /\{arch\}/) {
+ print STDERR "AUGH! tested " . $File::Find::name . "\n";
+ }
+ }; # perl note: This needs to be an anonymous sub to share
+ # @patchlist correctly.
+
# apply patches
- if (`find $tmp/changeset/patches -type f -name '*.patch'`) {
- # this can be sped up considerably by doing
- # (find | xargs cat) | patch
- # but that cna get mucked up by patches
- # with missing trailing newlines or the standard
- # 'missing newline' flag in the patch - possibly
- # produced with an old/buggy diff.
- # slow and safe, we invoke patch once per patchfile
- `find $tmp/changeset/patches -type f -name '*.patch' -print0 | grep -zv '{arch}' | xargs -iFILE -0 --no-run-if-empty patch -p1 --forward -iFILE`;
+
+ # this can be sped up considerably by applying all the patches in
+ # one pass, as with
+ # (find | xargs cat) | patch
+ # but that can get mucked up by patches with missing trailing
+ # newlines or the standard 'missing newline' flag in the patch -
+ # possibly produced with an old/buggy diff.
+ # slow and safe, we invoke patch once per patchfile
+
+ File::Find ({wanted => $wanted_patches,
+ preprocess => sub { grep(!/^\{arch\}$/, @_); }},
+ $tmp . "/changeset/patches");
+ foreach my $patchname (@patchlist) {
+ safe_pipe_capture("patch", "-p1", "--forward", "-i", $patchname);
die "Problem applying patches! $!" if $?;
}
--
1.1.6.g0d39d
^ permalink raw reply related
* [PATCH] Don't send copies to the From: address
From: Christian Biesinger @ 2006-02-11 2:47 UTC (permalink / raw)
To: git
Sending copies to the from address is pointless. Not
sending copies there makes it possible to do:
git-format-patch --mbox origin
git-send-email 00*
and get a reasonable result.
Signed-off-by: Christian Biesinger <cbiesinger@web.de>
---
git-send-email.perl | 16 ++++++++++------
1 files changed, 10 insertions(+), 6 deletions(-)
486a15e29dff39ff5885d7a1e38d6c5c3b70127b
diff --git a/git-send-email.perl b/git-send-email.perl
index 3f1b3ca..31d23d6 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -304,9 +304,11 @@ foreach my $t (@files) {
$subject = $1;
} elsif (/^(Cc|From):\s+(.*)$/) {
- printf("(mbox) Adding cc: %s from line '%s'\n",
- $2, $_) unless $quiet;
- push @cc, $2;
+ unless ($2 eq $from) {
+ printf("(mbox) Adding cc: %s from line '%s'\n",
+ $2, $_) unless $quiet;
+ push @cc, $2;
+ }
}
} else {
@@ -335,9 +337,11 @@ foreach my $t (@files) {
if (/^Signed-off-by: (.*)$/i) {
my $c = $1;
chomp $c;
- push @cc, $c;
- printf("(sob) Adding cc: %s from line '%s'\n",
- $c, $_) unless $quiet;
+ unless ($c eq $from) {
+ push @cc, $c;
+ printf("(sob) Adding cc: %s from line '%s'\n",
+ $c, $_) unless $quiet;
+ }
}
}
}
--
1.1.6.g71f7-dirty
^ permalink raw reply related
* Re: [PATCH] Don't propagate SKIPPED warning to future commits.
From: Junio C Hamano @ 2006-02-11 2:21 UTC (permalink / raw)
To: Carl Worth; +Cc: git
In-Reply-To: <87r76avfhz.wl%cworth@cworth.org>
Carl Worth <cworth@cworth.org> writes:
> Here's a simple bug fix for the (currently undocumented) -S flag to
> git-cvsimport.
>
> The -S flag allows an import to proceed in the face of a missing ,v
> file in the CVS repository. It marks this by adding a SKIPPED warning
> in the relevant commit.
>
> Without this patch, the SKIPPED warning propagates to all future
> commits, (and accumulates with future SKIPPED warnings).
I might be missing something fundamental, but isn't prapagating
the warning a good thing? If an earlier commit is suspected to
lack some path that needs to be there (I think that is what
"missing ,v file" means), wouldn't later commits built on top of
that one be by definition missing that path?
^ permalink raw reply
* Re: Git 1.1.6.g4d44 make test FAILURE report
From: Junio C Hamano @ 2006-02-11 2:17 UTC (permalink / raw)
To: A Large Angry SCM; +Cc: git
In-Reply-To: <43ED3FD3.7020005@gmail.com>
A Large Angry SCM <gitzilla@gmail.com> writes:
> Also, git-var complains when used by an account with an empty gcos
> field; thereby, breaking all the non-C git commands even when the user
> is not committing.
>
> If the _intent_ was to force commiters and author names in commits,
> why was the test not placed only in commit-tree.c?
git-var was more or less intentional. Scripts such as
git-applypatch, git-commit and git-tag use the command to grab
COMMITTER_IDENT to generate sign-off line and tagger information
when asked, and commit-tree.c changes alone would not catch
them.
A user eventually would make commit so it may not be a too bad
to _strongly_ encourage setting up these environment variables,
by being nasty ;-). I agree it would be _very_ annoying until
you either fix your gecos and/or environment.
Ideas welcome.
^ permalink raw reply
* [PATCH] Don't propagate SKIPPED warning to future commits.
From: Carl Worth @ 2006-02-11 1:41 UTC (permalink / raw)
To: git
Here's a simple bug fix for the (currently undocumented) -S flag to
git-cvsimport.
The -S flag allows an import to proceed in the face of a missing ,v
file in the CVS repository. It marks this by adding a SKIPPED warning
in the relevant commit.
Without this patch, the SKIPPED warning propagates to all future
commits, (and accumulates with future SKIPPED warnings).
Martin did the original work on -S to fix an import of the cairo
repository.
However, I just discovered that a correct fix for the cairo import
problem was for me to just "rm -rf ~/.cvsps". (I suppose calling with
a -x option would have worked too.)
I don't know how common it is for CVS repositories to change in ways
such that the cvsps cache gets totally confused as in my case, but it
might be worth adding something to cvsimport to help this. Some
options could be:
* Use cvsps -x always, to ignore the cache.
* Warn the user, (perhaps emit some description of stale cache
possibility if the import fails?).
* Add a note to the documentation.
Signed-off-by: Carl Worth <cworth@cworth.org>
---
git-cvsimport.perl | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
c816d743a1faf65fb209273a471b15c7b51b55df
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index 6b63aa2..25db0ed 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -749,6 +749,7 @@ my $commit = sub {
if (@skipped) {
$logmsg .= "\n\n\nSKIPPED:\n\t";
$logmsg .= join("\n\t", @skipped) . "\n";
+ @skipped = ();
}
print $pw "$logmsg\n"
--
1.1.6.g9da5
^ permalink raw reply related
* Re: Git 1.1.6.g4d44 make test FAILURE report
From: A Large Angry SCM @ 2006-02-11 1:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhd76vqrg.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Thanks; good catch. I think we should export GIT_*_{NAME,EMAIL}
> variables explicitly for this particular problem. We probably
> do _not_ want to do the same for GIT_*_DATE though.
Also, git-var complains when used by an account with an empty gcos
field; thereby, breaking all the non-C git commands even when the user
is not committing.
If the _intent_ was to force commiters and author names in commits, why
was the test not placed only in commit-tree.c?
^ permalink raw reply
* [PATCH] Munge ChangeLog-style commit messages, and grab author name and email.
From: Carl Worth @ 2006-02-11 1:19 UTC (permalink / raw)
To: git
The cairo project has been using ChangeLog-style commit messages, such as:
2006-01-18 Carl Worth <cworth@cworth.org>
* src/cairo-pdf-surface.c: (cairo_pdf_surface_create_for_stream),
(cairo_pdf_surface_create): Fix compilation-breaking typo.
This patch recognizes that style and munges it up into:
Fix compilation-breaking typo.
which results in a much more useful headline within git.
It also grabs the name and email address from the first line and
commits with those as GIT_AUTHOR_NAME and GIT_AUTHOR_MAIL.
It would probably make sense to hide all this munging behind an
appropriate command-line parameter, but I'm offering this up as is in
case it's useful for anyone with similar commit messages.
Signed-off-by: Carl Worth <cworth@cworth.org>
Signed-off-by: Keith Packard <keithp@keithp.com>
---
git-cvsimport.perl | 71 ++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 71 insertions(+), 0 deletions(-)
2f2002fe619c45cb1be1c0f063416ede242f3552
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index 00fc3ba..6b63aa2 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -658,6 +658,12 @@ my $commit = sub {
}
}
+ # Look for name and email from ChangeLog-style commit message
+ if ($logmsg =~ /^\s*\d\d\d\d-\d\d-\d\d\s*(.*)\s*<(.*)>/) {
+ $author_name = $1;
+ $author_email = $2;
+ }
+
exec("env",
"GIT_AUTHOR_NAME=$author_name",
"GIT_AUTHOR_EMAIL=$author_email",
@@ -673,8 +679,73 @@ my $commit = sub {
# compatibility with git2cvs
substr($logmsg,32767) = "" if length($logmsg) > 32767;
+
+ # We do a bunch of munging on the log message here,
+ # particularly for logs that are formatted in a ChangeLog
+ # style.
+
+ my $origlog = $logmsg;
+
+ # Kill initial date/name stamp: YYYY-MM-DD First Last <email@example.com>
+
+ $logmsg =~ s|^\s*\d\d*-\d\d*-\d\d*\s*[^<\n]*<[^>\n]*>\s*$|* \n|mg;
+
+ # Strip out nickle version numbers
+ $logmsg =~ s|^(version )?2.\d\d*$||mg;
+
+ # Remove initial space for each line
+ $logmsg =~ s|^[ \t]+||mg;
+
+ # Collapse space sequences
+ $logmsg =~ s|[ \t]+| |g;
+
+ # Un-fold paragraphs
+ $logmsg =~ s|([^\n])\n([^*+\-\n])|$1 $2|g;
+
+ my @lines = split (/\n/, $logmsg);
+
+ $logmsg = "";
+
+ my $reviews = "";
+
+ foreach my $line (@lines) {
+ # Pull out any reviewed-by name
+ if ($line =~ /^reviewed by:\s*/i) {
+ if ($line !~ /<delete if not using/) {
+ $reviews = $reviews . "\n" . $line;
+ }
+ } else {
+ # find lines begining with '*'
+ if ($line =~ s/^\*\s\s*//) {
+ # strip off filenames
+ while ($line =~ s/^[^ :,]*([,:]| (?=\())\s*// ) {
+ }
+ # strip off function names
+ while ($line =~ s/^\([^)]*\)[,:]*\s*// ) {
+ }
+ }
+ $logmsg = $logmsg . $line . "\n";
+ }
+ }
+ $logmsg = $logmsg . $reviews;
+
+ # Trim initial newlines
+ $logmsg =~ s|^\n+||;
+
+ # Remove initial space for each line
+ $logmsg =~ s|^[ \t]+||mg;
+
+ # Collapse space sequences
+ $logmsg =~ s|[ \t]+| |g;
+
+ # collapse sequences of newlines
+ $logmsg =~ s/\n\n*/\n/g;
+
+ # Remove trailing whitespace
$logmsg =~ s/[\s\n]+\z//;
+# print "<<<< Original\n$origlog\n---- Rewritten\n$logmsg\n<<<<\n";
+
if (@skipped) {
$logmsg .= "\n\n\nSKIPPED:\n\t";
$logmsg .= join("\n\t", @skipped) . "\n";
--
1.1.6.g9da5
^ permalink raw reply related
* Re: [PATCH 2/3] Use File::Find rather than find and xargs in git-archimport
From: Jason Riedy @ 2006-02-11 0:17 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86k6c2ojx6.fsf@blue.stonehenge.com>
And Randal L. Schwartz writes:
- Jason> + if (-f && !-z && /^.*\.patch$/ && !/{arch}/) {
-
- If that works, it's only accidentally.
Thanks! Not only is the regex wrong, it's applied to the
wrong quantity. Should be on $File::Find::dir. Looks like
the repos I tested against didn't have any Arch state
patches.
I'll fix this, test it on a nastier set of repos, and re-
send. It'll be an hour or so, at least.
Jason
^ permalink raw reply
* Re: [PATCH 2/3] Use File::Find rather than find and xargs in git-archimport
From: Randal L. Schwartz @ 2006-02-10 23:47 UTC (permalink / raw)
To: Jason Riedy; +Cc: git
In-Reply-To: <1103.1139614557@lotus.CS.Berkeley.EDU>
>>>>> "Jason" == Jason Riedy <ejr@EECS.Berkeley.EDU> writes:
Jason> + if (-f && !-z && /^.*\.patch$/ && !/{arch}/) {
If that works, it's only accidentally. Perhaps you wanted !/\{arch\}/ because
curlies are special to regex. Dunno, because I don't know what you're
excluding.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* [PATCH 3/3] Use active CPIO, FIND, and XARGS to set built-in defaults.
From: Jason Riedy @ 2006-02-10 23:36 UTC (permalink / raw)
To: git
Move the sed program in the % : %.sh pattern into the shellsedprog
variable. Add clauses to change the CPIO, FIND, and XARGS built-in
defaults if those variables are set. With appropriate settings, all
the current tests pass on Solaris 8 with my personal bizarre setup.
I'll try on a modules-based AIX once the machine's back next week.
I don't really like how I build the sed program, but I can't think of
an easier / better way.
Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu>
---
Makefile | 16 +++++++++++++---
1 files changed, 13 insertions(+), 3 deletions(-)
e512a44ccd488fec29af59e95b35741d4454b118
diff --git a/Makefile b/Makefile
index f240e45..edf785c 100644
--- a/Makefile
+++ b/Makefile
@@ -415,11 +415,21 @@ git$X: git.c $(LIB_FILE)
$(CC) -DGIT_VERSION='"$(GIT_VERSION)"' \
$(CFLAGS) $(COMPAT_CFLAGS) -o $@ $(filter %.c,$^) $(LIB_FILE)
+shellsedprog=-e '1s|\#!.*/sh|\#!$(call shq,$(SHELL_PATH))|;'
+shellsedprog+= -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g;'
+ifdef CPIO
+ shellsedprog+= -e 's@^: \$${CPIO:=cpio}@: \$${CPIO:=$(CPIO)}@;'
+endif
+ifdef FIND
+ shellsedprog+= -e 's@^: \$${FIND:=find}@: \$${FIND:=$(FIND)}@;'
+endif
+ifdef XARGS
+ shellsedprog+= -e 's@^: \$${XARGS:=xargs}@: \$${XARGS:=$(XARGS)}@;'
+endif
+
$(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.sh
rm -f $@
- sed -e '1s|#!.*/sh|#!$(call shq,$(SHELL_PATH))|' \
- -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
- $@.sh >$@
+ sed $(shellsedprog) $@.sh >$@
chmod +x $@
$(patsubst %.perl,%,$(SCRIPT_PERL)) : % : %.perl
--
1.1.6.g0d39d
^ permalink raw reply related
* [PATCH 2/3] Use File::Find rather than find and xargs in git-archimport
From: Jason Riedy @ 2006-02-10 23:35 UTC (permalink / raw)
To: git
git-archimport uses find and xargs directly to find and apply patches.
Replace these by File::Find and save one call to find. Tested on
Solaris 8 with a moderately complex, interrelated set of Arch repos.
Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu>
---
git-archimport.perl | 34 ++++++++++++++++++++++++----------
1 files changed, 24 insertions(+), 10 deletions(-)
5cd391ce78022806bbe12d5fda5ff49843e53207
diff --git a/git-archimport.perl b/git-archimport.perl
index 841738d..17502a4 100755
--- a/git-archimport.perl
+++ b/git-archimport.perl
@@ -60,6 +60,7 @@ use Getopt::Std;
use File::Temp qw(tempdir);
use File::Path qw(mkpath rmtree);
use File::Basename qw(basename dirname);
+use File::Find;
use Data::Dumper qw/ Dumper /;
use IPC::Open2;
@@ -664,17 +665,30 @@ sub apply_cset {
# get the changeset
safe_pipe_capture($TLA,'get-changeset',$ps->{id},"$tmp/changeset");
die "Cannot get changeset: $!" if $?;
-
+
+ my @patchlist;
+ my $wanted_patches = sub {
+ # We want all those non-empty *.patch files that do not modify
+ # arch state.
+ if (-f && !-z && /^.*\.patch$/ && !/{arch}/) {
+ push @patchlist, $File::Find::name;
+ }
+ }; # perl note: This needs to be an anonymous sub to share
+ # @patchlist correctly.
+
# apply patches
- if (`find $tmp/changeset/patches -type f -name '*.patch'`) {
- # this can be sped up considerably by doing
- # (find | xargs cat) | patch
- # but that cna get mucked up by patches
- # with missing trailing newlines or the standard
- # 'missing newline' flag in the patch - possibly
- # produced with an old/buggy diff.
- # slow and safe, we invoke patch once per patchfile
- `find $tmp/changeset/patches -type f -name '*.patch' -print0 | grep -zv '{arch}' | xargs -iFILE -0 --no-run-if-empty patch -p1 --forward -iFILE`;
+
+ # this can be sped up considerably by applying all the patches in
+ # one pass, as with
+ # (find | xargs cat) | patch
+ # but that can get mucked up by patches with missing trailing
+ # newlines or the standard 'missing newline' flag in the patch -
+ # possibly produced with an old/buggy diff.
+ # slow and safe, we invoke patch once per patchfile
+
+ File::Find ($wanted_patches, $tmp . "/changeset/patches");
+ foreach my $patchname (@patchlist) {
+ safe_pipe_capture("patch", "-p1", "--forward", "-i", $patchname);
die "Problem applying patches! $!" if $?;
}
--
1.1.6.g0d39d
^ permalink raw reply related
* [PATCH 1/3] Call extended-semantics commands through variables.
From: Jason Riedy @ 2006-02-10 23:35 UTC (permalink / raw)
To: git
In some places, git shell scripts rely on semantics for
xargs, find, and cpio that do not exist in all versions
of those commands. Both xargs and find rely on -0 for
handling multi-word names, and for some reason the cpio
calls do not work with pkgsrc's default cpio.
Replacing all such calls with calls through variables
allows more portability. Also, the variables can point
to debugging scripts that log arguments, outputs, etc.
The variables are just XARGS, FIND, and CPIO. No GIT_
was appended so a user can set those once for all scripts
that may use them (e.g. configure). A follow-on patch
will modify the Makefile to allow installation-specific
defaults.
Tested on Solaris 8 with those arguments pointing at
GNU tools as well as some Linux versions. (The AIX
machine I use is down for maintenance right now.)
Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu>
---
git-add.sh | 3 ++-
git-clone.sh | 10 ++++++----
git-count-objects.sh | 8 +++++---
git-grep.sh | 3 ++-
git-ls-remote.sh | 4 +++-
git-merge.sh | 5 +++--
git-prune.sh | 5 +++--
git-push.sh | 5 +++--
git-repack.sh | 3 ++-
9 files changed, 29 insertions(+), 17 deletions(-)
846024657d04675a762fd9edaba3c0612f616a41
diff --git a/git-add.sh b/git-add.sh
index f719b4b..bd79b4f 100755
--- a/git-add.sh
+++ b/git-add.sh
@@ -3,6 +3,7 @@
USAGE='[-n] [-v] <file>...'
SUBDIRECTORY_OK='Yes'
. git-sh-setup
+: ${XARGS:=xargs}
show_only=
verbose=
@@ -35,7 +36,7 @@ else
fi |
case "$show_only" in
true)
- xargs -0 echo ;;
+ ${XARGS} -0 echo ;;
*)
git-update-index --add $verbose -z --stdin ;;
esac
diff --git a/git-clone.sh b/git-clone.sh
index 47f3ec9..2c9b45e 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -7,6 +7,8 @@
# See git-sh-setup why.
unset CDPATH
+: ${FIND:=find}
+: ${CPIO:=cpio}
usage() {
echo >&2 "Usage: $0 [--bare] [-l [-s]] [-q] [-u <upload-pack>] [-o <name>] [-n] <repo> [<dir>]"
@@ -141,19 +143,19 @@ yes,yes)
no)
# See if we can hardlink and drop "l" if not.
sample_file=$(cd "$repo" && \
- find objects -type f -print | sed -e 1q)
+ ${FIND} objects -type f -print | sed -e 1q)
# objects directory should not be empty since we are cloning!
test -f "$repo/$sample_file" || exit
l=
- if ln "$repo/$sample_file" "$GIT_DIR/objects/sample" 2>/dev/null
+ if ln "$repo/$sample_file" "$DIR/objects/sample" 2>/dev/null
then
l=l
fi &&
rm -f "$GIT_DIR/objects/sample" &&
cd "$repo" &&
- find objects -depth -print | cpio -puamd$l "$GIT_DIR/" || exit 1
+ ${FIND} objects -depth -print | ${CPIO} -puamd$l "$GIT_DIR/" || exit 1
;;
yes)
mkdir -p "$GIT_DIR/objects/info"
@@ -234,7 +236,7 @@ then
"URL: $repo
Pull: $head_points_at:$origin" &&
git-update-ref "refs/heads/$origin" $(git-rev-parse HEAD) &&
- (cd "$GIT_DIR" && find "refs/heads" -type f -print) |
+ (cd "$GIT_DIR" && ${FIND} "refs/heads" -type f -print) |
while read ref
do
head=`expr "$ref" : 'refs/heads/\(.*\)'` &&
diff --git a/git-count-objects.sh b/git-count-objects.sh
index 40c58ef..5a4550c 100755
--- a/git-count-objects.sh
+++ b/git-count-objects.sh
@@ -4,6 +4,8 @@
#
GIT_DIR=`git-rev-parse --git-dir` || exit $?
+: ${FIND:=find}
+: ${XARGS:=xargs}
dc </dev/null 2>/dev/null || {
# This is not a real DC at all -- it just knows how
@@ -20,12 +22,12 @@ dc </dev/null 2>/dev/null || {
}
}
-echo $(find "$GIT_DIR/objects"/?? -type f -print 2>/dev/null | wc -l) objects, \
+echo $(${GIT_FIND} "$GIT_DIR/objects"/?? -type f -print 2>/dev/null | wc -l) objects, \
$({
echo 0
# "no-such" is to help Darwin folks by not using xargs -r.
- find "$GIT_DIR/objects"/?? -type f -print 2>/dev/null |
- xargs du -k "$GIT_DIR/objects/no-such" 2>/dev/null |
+ ${FIND} "$GIT_DIR/objects"/?? -type f -print 2>/dev/null |
+ ${XARGS} du -k "$GIT_DIR/objects/no-such" 2>/dev/null |
sed -e 's/[ ].*/ +/'
echo p
} | dc) kilobytes
diff --git a/git-grep.sh b/git-grep.sh
index ad4f2fe..a58ab37 100755
--- a/git-grep.sh
+++ b/git-grep.sh
@@ -6,6 +6,7 @@
USAGE='[<option>...] [-e] <pattern> [<path>...]'
SUBDIRECTORY_OK='Yes'
. git-sh-setup
+: ${XARGS:=xargs}
got_pattern () {
if [ -z "$no_more_patterns" ]
@@ -59,4 +60,4 @@ done
usage
}
git-ls-files -z "${git_flags[@]}" -- "$@" |
- xargs -0 grep "${flags[@]}" -e "$pattern" --
+ ${XARGS} -0 grep "${flags[@]}" -e "$pattern" --
diff --git a/git-ls-remote.sh b/git-ls-remote.sh
index 2c9a588..340bde0 100755
--- a/git-ls-remote.sh
+++ b/git-ls-remote.sh
@@ -1,6 +1,8 @@
#!/bin/sh
#
+: ${FIND:=find}
+
usage () {
echo >&2 "usage: $0 [--heads] [--tags] [-u|--upload-pack <upload-pack>]"
echo >&2 " <repository> <refs>..."
@@ -63,7 +65,7 @@ rsync://* )
echo "failed slurping"
exit
}
- (cd $tmpdir && find refs -type f) |
+ (cd $tmpdir && ${FIND} refs -type f) |
while read path
do
cat "$tmpdir/$path" | tr -d '\012'
diff --git a/git-merge.sh b/git-merge.sh
index dc17baf..c9b03c8 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -6,6 +6,7 @@
USAGE='[-n] [--no-commit] [-s <strategy>]... <merge-message> <head> <remote>+'
. git-sh-setup
+: ${CPIO:=cpio}
LF='
'
@@ -22,14 +23,14 @@ dropsave() {
savestate() {
# Stash away any local modifications.
git-diff-index -z --name-only $head |
- cpio -0 -o >"$GIT_DIR/MERGE_SAVE"
+ ${CPIO} -0 -o >"$GIT_DIR/MERGE_SAVE"
}
restorestate() {
if test -f "$GIT_DIR/MERGE_SAVE"
then
git reset --hard $head
- cpio -iuv <"$GIT_DIR/MERGE_SAVE"
+ ${CPIO} -iuv <"$GIT_DIR/MERGE_SAVE"
git-update-index --refresh >/dev/null
fi
}
diff --git a/git-prune.sh b/git-prune.sh
index c5a5d29..781393f 100755
--- a/git-prune.sh
+++ b/git-prune.sh
@@ -2,6 +2,7 @@
USAGE='[-n] [--] [<head>...]'
. git-sh-setup
+: ${XARGS:=xargs}
dryrun=
echo=
@@ -27,7 +28,7 @@ sed -ne '/unreachable /{
s|\(..\)|\1/|p
}' | {
cd "$GIT_OBJECT_DIRECTORY" || exit
- xargs $echo rm -f
+ ${XARGS} $echo rm -f
rmdir 2>/dev/null [0-9a-f][0-9a-f]
}
@@ -37,7 +38,7 @@ if redundant=$(git-pack-redundant --all
then
if test "" = "$dryrun"
then
- echo "$redundant" | xargs rm -f
+ echo "$redundant" | ${XARGS} rm -f
else
echo rm -f "$redundant"
fi
diff --git a/git-push.sh b/git-push.sh
index 706db99..1a6c96d 100755
--- a/git-push.sh
+++ b/git-push.sh
@@ -2,6 +2,7 @@
USAGE='[--all] [--tags] [--force] <repository> [<refspec>...]'
. git-sh-setup
+: ${FIND:=find}
# Parse out parameters and then stop at remote, so that we can
# translate it using .git/branches information
@@ -46,9 +47,9 @@ case "$has_all" in
'')
case "$do_tags,$#" in
yes,1)
- set x $(cd "$GIT_DIR/refs" && find tags -type f -print) ;;
+ set x $(cd "$GIT_DIR/refs" && ${FIND} tags -type f -print) ;;
yes,*)
- set x $(cd "$GIT_DIR/refs" && find tags -type f -print) \
+ set x $(cd "$GIT_DIR/refs" && ${FIND} tags -type f -print) \
$(get_remote_refs_for_push "$@") ;;
,*)
set x $(get_remote_refs_for_push "$@") ;;
diff --git a/git-repack.sh b/git-repack.sh
index 1fafb6e..56a33a7 100755
--- a/git-repack.sh
+++ b/git-repack.sh
@@ -5,6 +5,7 @@
USAGE='[-a] [-d] [-l] [-n]'
. git-sh-setup
+: ${FIND:=find}
no_update_info= all_into_one= remove_redundant= local=
while case "$#" in 0) break ;; esac
@@ -36,7 +37,7 @@ case ",$all_into_one," in
# Redundancy check in all-into-one case is trivial.
existing=`cd "$PACKDIR" && \
- find . -type f \( -name '*.pack' -o -name '*.idx' \) -print`
+ ${FIND} . -type f \( -name '*.pack' -o -name '*.idx' \) -print`
;;
esac
if [ "$local" ]; then
--
1.1.6.g0d39d
^ permalink raw reply related
* Re: Comments on "status -v"
From: Junio C Hamano @ 2006-02-10 23:26 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060210225109.GQ31278@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
>> That is a good argument for (1). Since the diff output never
>> has '^---$' in itself,
>
> $ echo -- >a; >b; diff -u a b
Thanks. Good point. Forget what I said.
^ permalink raw reply
* Re: [PATCH] Ignore commits for which cvsps can't identify a branch
From: Linus Torvalds @ 2006-02-10 23:25 UTC (permalink / raw)
To: Christian Biesinger; +Cc: Junio C Hamano, git
In-Reply-To: <43ED0D63.5090105@web.de>
On Fri, 10 Feb 2006, Christian Biesinger wrote:
>
> I have to admit that I can't actually tell you for sure, since I still get a
> failure later (I think it's because cvsps orders changesets wrongly).
Do you have a recent version of "cvsps"? The wrong ordering happened quite
often with old cvsps versions. So make sure you absolutely have 2.1.
Also, David Mansfield may not be maintaining it horribly actively, but
that's probably because it's purely a "minimal maintenance" project for
him by now. He reacted in a very timely manner when we pointed out
specific bugs, so if you can pinpoint the exact thing cvsps does wrong, I
bet David will be more than happy to apply patches or perhaps even fix it
himself and make a new version.
So while it's fine to work around cvsps problems inside "git cvsimport",
it's even better if you could try to see if you can figure out why they
happen in the first place. The source code wasn't all that unreadable from
what I can remember.
Linus
^ permalink raw reply
* Re: [ANNOUNCE] pg - A patch porcelain for GIT
From: Greg KH @ 2006-02-10 23:20 UTC (permalink / raw)
To: git
In-Reply-To: <20060210210401.GA1604@spearce.org>
On Fri, Feb 10, 2006 at 04:04:01PM -0500, Shawn Pearce wrote:
> Greg KH <greg@kroah.com> wrote:
> > On Fri, Feb 10, 2006 at 02:59:14PM -0500, Shawn Pearce wrote:
> > > I just posted the first public version of pg, a GIT porcelain for
> > > managing patches. Think StGIT, but better in some ways:
> > >
> > > Feature Summary:
> >
> > Hm, is there any way to import an existing patch into pg?
>
> Doh! I haven't needed to do that yet. I'll code up a pg-import
> later tonight. But since git and pg play nice together you can
> do this:
>
> pg-new Patch-Name
> git-apply the-patch-file.patch
> pg-ci -m"Importing the-patch-file.patch..."
>
> or even:
>
> pg-new Patch-Name
> git-am mbox
well, as my quilt tree is around 200 patches right now, that would be
annoying to have to do by hand :)
thanks,
greg k-h
^ permalink raw reply
* Re: Comments on "status -v"
From: Petr Baudis @ 2006-02-10 22:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Carl Worth, git
In-Reply-To: <7vaccyx6ne.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Fri, Feb 10, 2006 at 10:09:41PM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Carl Worth <cworth@cworth.org> writes:
>
> > 1) I think the patch should come after the traditional status summary,
> > not before. If something is obviously "wrong" (non-updated file,
> > etc.) that will be more obvious in the summary, so it's good to
> > present that up front, and not bury it after the patch, (which
> > might make it initially invisible without scrolling).
>
> Maybe. A time for a quick poll.
It makes more sense to me. (Not that I'd be ever going to use the
command, though. ;)
> > 2) Using the "^---$" separator to separate the the edited contents
> > into a commit message and ignored content seems risky to me.
We do it for the mails (and Cogito for cg-mkpatch output) and it seems
to work out just fine.
> > Moving the patch after the summary (as discussed above) would help
> > greatly in avoiding the clobbered separator, but wouldn't address
> > the separator-appears-in-commit-message problem.
>
> That is a good argument for (1). Since the diff output never
> has '^---$' in itself,
$ echo -- >a; >b; diff -u a b
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: Comments on "status -v"
From: Junio C Hamano @ 2006-02-10 22:12 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Carl Worth, git
In-Reply-To: <Pine.LNX.4.64.0602101333570.19172@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> I think I agree. Especially if doing "git commit -v", the _top_ of the
> status message is what you'd normally be most aware of. I think.
Well the exactly same reasoning on my part, who keeps tons of
untracked files in his repository, left the patch output there.
Otherwise I have to scroll off a long "untracked files" list to
get to the patch ;-).
But even with that gripe, I'd agree that patch at the end would
be a better choice. The user asked for a patch so she wouldn't
fail to see it even if many '#' lines precede the patch. With
the current ordering, '#' lines will most likely be ignored.
^ permalink raw reply
* Re: [ANNOUNCE] pg - A patch porcelain for GIT
From: Junio C Hamano @ 2006-02-10 22:07 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060210214723.GP31278@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> On a second thought, this is probably simply caused by the web server
> not reporting 404 on missing files.
I suspect that is it. The webserver is broken^W not being a
good network citizen.
^ permalink raw reply
* Re: [PATCH] Ignore commits for which cvsps can't identify a branch
From: Christian Biesinger @ 2006-02-10 22:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmzgyvrih.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Does continuing with this kind of "fixups" produce usable
> history, perhaps just some changes missing but trees contained
> in other commits are still faithful reproductions of what the
> CVS repository would have given you? Or does it result in
> unusable history?
I have to admit that I can't actually tell you for sure, since I still
get a failure later (I think it's because cvsps orders changesets
wrongly). However, I was told that the revisions that give me this
CVSPS_NO_BRANCH issue came into existence by (partially) removing tags
from a file, so not listing them should be fine, I think. (This happened
by copying a ,v file and removing its tags, simulating a file copy)
Anyway, based on that, I expect that the history is the same as what I
get from cvs, but I can't verify that.
> Depending on the nature of corruption and its expected use,
> sometimes silently corrupt conversion result is worse than not
> having it at all.
Well, without the patch this error is fatal, and the conversion is very
partial. I'm not sure if that's better.
(This is also not "silent" corruption. I do show a message for it. Would
you rather have it displayed unconditionally?)
Would it be better to have a flag --continue-on-errors?
^ permalink raw reply
* Re: [ANNOUNCE] pg - A patch porcelain for GIT
From: Petr Baudis @ 2006-02-10 21:47 UTC (permalink / raw)
To: git
In-Reply-To: <20060210213818.GB1604@spearce.org>
Dear diary, on Fri, Feb 10, 2006 at 10:38:18PM CET, I got a letter
where Shawn Pearce <spearce@spearce.org> said that...
> But two things happened:
>
> 1) Cogito didn't run well on a Solaris box I wanted to try and
> use it in; apparently we don't have enough GNU shell commands
> available and Cogito fell over. (But right now I'd bet pg
> will behave the same if not worse. I haven't had time to try
> it. *sigh*)
I'm always listening for bugreports. Besides requiring bash, Cogito _is_
expected to run on POSIX stuff!
> 2) I found myself suddenly typing 'pg-log' and 'pg-diff' rather
> than 'git-log' and 'git-diff'. Call it future muscle memory?
> I hadn't written either of these scripts so I was getting a lot
> of '-bash: pg-log: command not found' errors from my shell.
> So they both became 1 line wrappers around the git-core
> versions, just to save my sanity.
I see. IIRC Catalin gave the similar reasoning. (Obviously, my
egoistical me might be just hurt by it not wrapping Cogito. ;))
> > But while it claims to be compatible with all the porcelains, it at
> > least cannot be clone by them. ;) The GIT repository is not quite a
> > valid GIT repository since it is missing the HEAD and Cogito clones
> > based on this file instead of just assuming that your head is on the
> > master branch.
>
> Fixed.
Thanks.
> > Also, when cloning it gives me a little unnerving errors like
> >
> > error: File 6427c0154400f578d9cdff178e01e946db6f714f
> > (http://www.spearce.org/projects/scm/pg.git/objects/64/27c0154400f578d9cdff178e01e946db6f714f)
> > corrupt
>
> I've seen the same. I think it is either a bug in my rsync script
> or a bug in the GIT http clone code; because that is the current
> tip commit of the master branch. And I've only seen that error for
> the tip commit, and only if the object doesn't exist in the object
> directory because I've done git-pack && git-prune-packed.
On a second thought, this is probably simply caused by the web server
not reporting 404 on missing files.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ 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