* Re: Some git performance measurements..
From: Johannes Schindelin @ 2007-12-08 11:05 UTC (permalink / raw)
To: Mike Ralphson
Cc: Steffen Prohaska, Junio C Hamano, Nicolas Pitre, Linus Torvalds,
Jakub Narebski, Git Mailing List
In-Reply-To: <e2b179460712071115k369dddcatb0f6456d0028acbb@mail.gmail.com>
Hi,
On Fri, 7 Dec 2007, Mike Ralphson wrote:
> On Dec 7, 2007 6:37 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Fri, 7 Dec 2007, Mike Ralphson wrote:
> >
> > > On Dec 7, 2007 1:49 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > > On Fri, 7 Dec 2007, Mike Ralphson wrote:
> > > >
> > > > > I benchmarked 3 alternative qsorts, qsortG [2] was the fastest
> > > > > on my system but has funky licensing, the NetBSD qsort was
> > > > > middle-range and the glibc one the slowest of the three (but
> > > > > that could be due to it being tuned for a "Sun 4/260"). All of
> > > > > them show over 100x speed improvements on a git-status of my
> > > > > main repo (104s -> ~0.7s)
> > > >
> >
> > Okay, sorry, I did not bother reading further when I read "You may use
> > it in anything you like;".
> >
> > But if the author did not respond, it might be a better idea to just
> > reimplement it.
> >
>
> I've just tried the mergesort implementation as used in msysgit and that
> performs faster for me. It's simpler, and compatibly licensed. It looks
> good.
Now I'm confused. You said you tested qsortG, NetBSD qsort and qlibc,
with glibc performing the slowest. Now, 4msysgit's implementation is
based on glibc (Thanks Brian!), so I wonder if you could redo the
performance tests and say if qsortG still is substantially faster than
4msysgit's qsort?
Ciao,
Dscho
^ permalink raw reply
* Re: git-svn branch naming question
From: Peter Baumann @ 2007-12-08 10:59 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20071208010438.GE3199@genesis.frugalware.org>
On Sat, Dec 08, 2007 at 02:04:38AM +0100, Miklos Vajna wrote:
> hi,
>
> i'm using git-svn for projects where i don't just want to commit to
> trunk but to other branches, too.
>
> for example:
>
> git-svn clone -s svn+ssh://vmiklos@svn.gnome.org/svn/ooo-build ooo-build
>
> then i have a local 'master' branch and all the other branches are local
> branches.
>
> so, when i want to work in the ooo-build-2-3 branch, i do a:
>
> git checkout -b ooo-build-2-3 ooo-build-2-3
>
> but when i do a git svn rebase, i get:
>
> warning: refname 'ooo-build-2-3' is ambiguous.
>
> what am i doing wrong?
Try using 'git svn rebase remotes/ooo-build-2-3'.
git-svn should produce its branches under refs/remotes/* and your
local branches are under refs/heads/*.
By using 'git checkout -b ooo-build-2-3 ooo-build-2-3' you created
refs/heads/ooo-build-2-3 as a copy of refs/remotes/ooo-build-2-3 and now
using only ooo-build-2-3 is ambigious. (at least in some cases where git
won't take refs/heads/ooo-build-2-3)
>
> in fact i suspect that in case i would use some other branch name, like
> simply '2-3' then i could get rid of this warning, but that's the
> problem with using the equivalent name of the remote branch when working
> in a branch locally?
>
See above.
> probably i miss some parameter to git-svn clone so that it would prefix
> the refs with some 'origin'?
Look up --prefix in the manpage for git-svn.
-Peter
^ permalink raw reply
* Re: [OT] perhaps we want to support copied-context diff output
From: Peter Baumann @ 2007-12-08 11:10 UTC (permalink / raw)
To: Mike Hommey; +Cc: Junio C Hamano, Nicolas Pitre, git, Jon Smirl
In-Reply-To: <20071208085302.GA13432@glandium.org>
On Sat, Dec 08, 2007 at 09:53:02AM +0100, Mike Hommey wrote:
> > Perhaps we may want to add "diff -c" (copied context) output format as
> > an option, which may be easier to read.
>
> Or maybe use the patience diff.
>
[... skip testcase showing a much nicer diff for human consumption ...]
AFAIR bzr uses the patience diff already. I don't actually use bzr
(obviously, because git is so much better:-) but it produces much nicer
diffs than git if you have many small changes nearby.
-Peter
^ permalink raw reply
* Re: git guidance
From: Johannes Schindelin @ 2007-12-08 11:13 UTC (permalink / raw)
To: Al Boldi
Cc: Jakub Narebski, Andreas Ericsson, Phillip Susi, Linus Torvalds,
Jing Xue, linux-kernel, git
In-Reply-To: <200712072204.48410.a1426z@gawab.com>
Hi,
On Fri, 7 Dec 2007, Al Boldi wrote:
> Jakub Narebski wrote:
>
> > Version control system is all about WORKFLOW B, where programmer
> > controls when it is time to commit (and in private repository he/she
> > can then rewrite history to arrive at "Perfect patch series"[*1*]);
> > something that for example CVS failed at, requiring programmer to do a
> > merge if upstream has any changes when trying to commit.
>
> Because WORKFLOW C is transparent, it won't affect other workflows. So
> you could still use your normal WORKFLOW B in addition to WORKFLOW C,
> gaining an additional level of version control detail at no extra cost
> other than the git-engine scratch repository overhead.
>
> BTW, is git efficient enough to handle WORKFLOW C?
The question is not if git is efficient enough to handle workflow C, but
if that worflow is efficient enough to help anybody.
Guess what takes me the longest time when committing? The commit message.
But it is really helpful, so there is a _point_ in writing one, and there
is a _point_ in committing when I do it: it is a point in time where I
expect the tree to be in a good shape, to be compilable, and to solve a
specific problem which I describe in the commit message.
So I absolutely hate this "transparency". Git _is_ transparent; it does
not affect any of my other tools; they still work very well
thankyouverymuch.
What your version of "transparency" would do: destroy bisectability, make
an absolute gibberish of the history, and more!
Nobody could read the output of "git log" and form an understanding what
was done. Nobody could read the commit message for a certain "git blame"d
line that she tries to make sense of.
IOW you would revert the whole meaning of the term Source Code Management.
Hth,
Dscho
^ permalink raw reply
* [PATCH 0/3] builtin-commit fixes
From: Wincent Colaiuta @ 2007-12-08 11:38 UTC (permalink / raw)
To: git; +Cc: gitster, krh
A little series to bring built-in commit back in line with the
behaviour as implemented by git-commit.sh and described in the
documentation.
1/3 Allow --no-verify to bypass commit-msg hook
- git-commit.sh used to do this, but builtin-commit wasn't.
2/3 Documentation: fix --no-verify documentation for "git commit"
- The "git commit" man page should mention the commit-msg hook to
bring it in line with what's in the hook notes and in
Documentation/hooks.txt.
3/3 Fix commit-msg hook to allow editing
- Again, git-commit.sh allowed this, but builtin-commit wasn't
doing so.
I have manually tested these changes and they seem to work, but
the fact that the test suite didn't break when the behaviour of
"git commit" changed is indicative of a hole in the suite. I am
not very familiar yet with the test machinery, but I am going
to see if I can whip something up.
Cheers,
Wincent
^ permalink raw reply
* [PATCH 1/3] Allow --no-verify to bypass commit-msg hook
From: Wincent Colaiuta @ 2007-12-08 11:38 UTC (permalink / raw)
To: git; +Cc: gitster, krh, Wincent Colaiuta
In-Reply-To: <1197113889-16243-1-git-send-email-win@wincent.com>
At the moment the --no-verify switch to "git commit" instructs it to
skip over the pre-commit hook. Here we teach "git commit --no-verify"
to skip over the commit-msg hook as well. This brings the behaviour
of builtin-commit back in line with git-commit.sh.
Signed-off-by: Wincent Colaiuta <win@wincent.com>
---
builtin-commit.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 2ec8223..df9377e 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -791,7 +791,8 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
rollback_index_files();
die("could not read commit message");
}
- if (run_hook(index_file, "commit-msg", git_path(commit_editmsg))) {
+ if (!no_verify &&
+ run_hook(index_file, "commit-msg", git_path(commit_editmsg))) {
rollback_index_files();
exit(1);
}
--
1.5.3.7.1115.gaa595
^ permalink raw reply related
* [PATCH 3/3] Fix commit-msg hook to allow editing
From: Wincent Colaiuta @ 2007-12-08 11:38 UTC (permalink / raw)
To: git; +Cc: gitster, krh, Wincent Colaiuta
In-Reply-To: <1197113889-16243-3-git-send-email-win@wincent.com>
The old git-commit.sh script allowed the commit-msg hook to not only
prevent a commit from proceding, but also to edit the commit message
on the fly and allow it to proceed. So here we teach builtin-commit
to do the same.
Signed-off-by: Wincent Colaiuta <win@wincent.com>
---
builtin-commit.c | 16 ++++++++++------
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index df9377e..a6223d2 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -787,14 +787,18 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
const char *env[2] = { index, NULL };
snprintf(index, sizeof(index), "GIT_INDEX_FILE=%s", index_file);
launch_editor(git_path(commit_editmsg), &sb, env);
- } else if (strbuf_read_file(&sb, git_path(commit_editmsg), 0) < 0) {
- rollback_index_files();
- die("could not read commit message");
}
- if (!no_verify &&
- run_hook(index_file, "commit-msg", git_path(commit_editmsg))) {
+ if (!no_verify) {
+ if (run_hook(index_file, "commit-msg", git_path(commit_editmsg))) {
+ rollback_index_files();
+ exit(1);
+ }
+ strbuf_setlen(&sb, header_len);
+ }
+ if ((no_edit || !no_verify) &&
+ strbuf_read_file(&sb, git_path(commit_editmsg), 0) < 0) {
rollback_index_files();
- exit(1);
+ die("could not read commit message");
}
/* Truncate the message just before the diff, if any. */
--
1.5.3.7.1115.gaa595
^ permalink raw reply related
* [PATCH 2/3] Documentation: fix --no-verify documentation for "git commit"
From: Wincent Colaiuta @ 2007-12-08 11:38 UTC (permalink / raw)
To: git; +Cc: gitster, krh, Wincent Colaiuta
In-Reply-To: <1197113889-16243-2-git-send-email-win@wincent.com>
The documentation for the --no-verify switch should mention the
commit-msg hook, not just the pre-commit hook.
Signed-off-by: Wincent Colaiuta <win@wincent.com>
---
Documentation/git-commit.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 4bb2791..4261384 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -86,7 +86,7 @@ OPTIONS
Add Signed-off-by line at the end of the commit message.
--no-verify::
- This option bypasses the pre-commit hook.
+ This option bypasses the pre-commit and commit-msg hooks.
See also link:hooks.html[hooks].
--allow-empty::
--
1.5.3.7.1115.gaa595
^ permalink raw reply related
* Re: RAM consumption when working with the gcc repo
From: Johannes Schindelin @ 2007-12-08 11:54 UTC (permalink / raw)
To: Marco Costalba; +Cc: Nicolas Pitre, david, Jon Smirl, Git Mailing List
In-Reply-To: <e5bfff550712071325k3d4dadf2gf34c069022cc005@mail.gmail.com>
Hi,
On Fri, 7 Dec 2007, Marco Costalba wrote:
> On Dec 7, 2007 9:46 PM, Nicolas Pitre <nico@cam.org> wrote:
> >
> > The other 2.3GB is hard to explain.
>
> BTW does exist a tool to profile memory consumption by each source level
> struct / vector/ or any other data container?
>
> Valgrind checks mainly memory leaks, callgrind gives profiling
> information in terms of call graphs and times/cycles consumed by each
> function.
Have you looked at Massif (also part of Valgrind)?
Ciao,
Dscho
^ permalink raw reply
* [PATCH] gitweb: Teach "a=blob" action to be more lenient about blob/file mime type
From: Jakub Narebski @ 2007-12-08 11:55 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jakub Narebski
Since 930cf7dd7cc6b87d173f182230763e1f1913d319 'blob' action knows the
file type; if the file type is not "text/*" or one of common network
image formats/mimetypes (gif, png, jpeg) then the action "blob"
defaulted to "blob_plain". This caused the problem if mimetypes file
was not well suited for web, for example returning "application/x-sh"
for "*.sh" shell scripts, instead of "text/plain" (or other "text/*").
Now "blob" action defaults to "blob_plain" ('raw' view) only if file
is of type which is neither "text/*" nor "image/{gif,png,jpeg}"
AND it is binary file. Otherwise it assumes that it can be displayed
either in <img> tag ("image/*" mimetype), or can be displayed line by
line (otherwise).
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
The patch I've send earlier
"[RFC/PATCH] gitweb: Try to sanitize mimetype for 'blob_plain' view"
Message-Id: <1195484054-18164-1-git-send-email-jnareb@gmail.com>
should also do what this patch is about. This one however IMHO
is much less invasive, and much less controversial.
P.S. BTW is there some plumbing for scripts to help with
gitattributes, for example showing all gitattributes (or status of
selected attributes) for given path?
gitweb/gitweb.perl | 24 ++++++++++++------------
1 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index eac7e16..b833327 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -4302,7 +4302,7 @@ sub git_blob {
open my $fd, "-|", git_cmd(), "cat-file", "blob", $hash
or die_error(undef, "Couldn't cat $file_name, $hash");
my $mimetype = blob_mimetype($fd, $file_name);
- if ($mimetype !~ m!^(?:text/|image/(?:gif|png|jpeg)$)!) {
+ if ($mimetype !~ m!^(?:text/|image/(?:gif|png|jpeg)$)! && -B $fd) {
close $fd;
return git_blob_plain($mimetype);
}
@@ -4343,16 +4343,7 @@ sub git_blob {
}
git_print_page_path($file_name, "blob", $hash_base);
print "<div class=\"page_body\">\n";
- if ($mimetype =~ m!^text/!) {
- my $nr;
- while (my $line = <$fd>) {
- chomp $line;
- $nr++;
- $line = untabify($line);
- printf "<div class=\"pre\"><a id=\"l%i\" href=\"#l%i\" class=\"linenr\">%4i</a> %s</div>\n",
- $nr, $nr, $nr, esc_html($line, -nbsp=>1);
- }
- } elsif ($mimetype =~ m!^image/!) {
+ if ($mimetype =~ m!^image/!) {
print qq!<img type="$mimetype"!;
if ($file_name) {
print qq! alt="$file_name" title="$file_name"!;
@@ -4361,7 +4352,16 @@ sub git_blob {
href(action=>"blob_plain", hash=>$hash,
hash_base=>$hash_base, file_name=>$file_name) .
qq!" />\n!;
- }
+ } else {
+ my $nr;
+ while (my $line = <$fd>) {
+ chomp $line;
+ $nr++;
+ $line = untabify($line);
+ printf "<div class=\"pre\"><a id=\"l%i\" href=\"#l%i\" class=\"linenr\">%4i</a> %s</div>\n",
+ $nr, $nr, $nr, esc_html($line, -nbsp=>1);
+ }
+ } els
close $fd
or print "Reading blob failed.\n";
print "</div>";
--
1.5.3.7
^ permalink raw reply related
* Re: Git and GCC
From: Johannes Schindelin @ 2007-12-08 12:00 UTC (permalink / raw)
To: Daniel Berlin
Cc: Giovanni Bajo, Jakub Narebski, Linus Torvalds, David Miller,
jonsmirl, peff, nico, harvey.harrison, ismail, gcc, git
In-Reply-To: <4aca3dc20712071533k3189d25dp901c5941e5326ead@mail.gmail.com>
Hi,
On Fri, 7 Dec 2007, Daniel Berlin wrote:
> On 12/7/07, Giovanni Bajo <rasky@develer.com> wrote:
> > On Fri, 2007-12-07 at 14:14 -0800, Jakub Narebski wrote:
> >
> > > > >> Is SHA a significant portion of the compute during these
> > > > >> repacks? I should run oprofile...
> > > > > SHA1 is almost totally insignificant on x86. It hardly shows up.
> > > > > But we have a good optimized version there. zlib tends to be a
> > > > > lot more noticeable (especially the *uncompression*: it may be
> > > > > faster than compression, but it's done _so_ much more that it
> > > > > totally dominates).
> > > >
> > > > Have you considered alternatives, like:
> > > > http://www.oberhumer.com/opensource/ucl/
> > >
> > > <quote>
> > > As compared to LZO, the UCL algorithms achieve a better
> > > compression ratio but *decompression* is a little bit slower. See
> > > below for some rough timings.
> > > </quote>
> > >
> > > It is uncompression speed that is more important, because it is used
> > > much more often.
> >
> > I know, but the point is not what is the fastestest, but if it's fast
> > enough to get off the profiles. I think UCL is fast enough since it's
> > still times faster than zlib. Anyway, LZO is GPL too, so why not
> > considering it too. They are good libraries.
>
>
> At worst, you could also use fastlz (www.fastlz.org), which is faster
> than all of these by a factor of 4 (and compression wise, is actually
> sometimes better, sometimes worse, than LZO).
fastLZ is awfully short on details when it comes to a comparison of the
resulting file sizes.
The only result I saw was that for the (single) example they chose,
compressed size was 470MB as opposed to 361MB for zip's _fastest_ mode.
Really, that's not acceptable for me in the context of git.
Besides, if you change the compression algorithm you will have to add
support for legacy clients to _recompress_ with libz. Which most likely
would make Sisyphos grin watching them servers.
Ciao,
Dscho
^ permalink raw reply
* [PATCH v2] git-help: simplify and fix option parsing.
From: Christian Couder @ 2007-12-08 12:18 UTC (permalink / raw)
To: Junio Hamano; +Cc: git
Also use "execl_git_cmd" to launch "git-browse-help".
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
help.c | 33 ++++++++++++---------------------
1 files changed, 12 insertions(+), 21 deletions(-)
Junio wrote:
> This should be execl_git_cmd() to honor GIT_TRACE and to help
> transition to bindir != gitexecdir layout, I think.
Here it is.
diff --git a/help.c b/help.c
index ecc8c66..9d7fc8a 100644
--- a/help.c
+++ b/help.c
@@ -241,7 +241,9 @@ void list_common_cmds_help(void)
static const char *cmd_to_page(const char *git_cmd)
{
- if (!prefixcmp(git_cmd, "git"))
+ if (!git_cmd)
+ return "git";
+ else if (!prefixcmp(git_cmd, "git"))
return git_cmd;
else {
int page_len = strlen(git_cmd) + 4;
@@ -268,7 +270,7 @@ static void show_info_page(const char *git_cmd)
static void show_html_page(const char *git_cmd)
{
const char *page = cmd_to_page(git_cmd);
- execlp("git-browse-help", "git-browse-help", page, NULL);
+ execl_git_cmd("browse-help", page, NULL);
}
void help_unknown_cmd(const char *cmd)
@@ -283,38 +285,27 @@ int cmd_version(int argc, const char **argv, const char *prefix)
return 0;
}
-static void check_help_cmd(const char *help_cmd)
+int cmd_help(int argc, const char **argv, const char *prefix)
{
- if (!help_cmd) {
+ if (argc < 2) {
printf("usage: %s\n\n", git_usage_string);
list_common_cmds_help();
exit(0);
}
- else if (!strcmp(help_cmd, "--all") || !strcmp(help_cmd, "-a")) {
+ const char *help_cmd = argv[1];
+
+ if (!strcmp(help_cmd, "--all") || !strcmp(help_cmd, "-a")) {
printf("usage: %s\n\n", git_usage_string);
list_commands();
- exit(0);
}
-}
-int cmd_help(int argc, const char **argv, const char *prefix)
-{
- const char *help_cmd = argc > 1 ? argv[1] : NULL;
- check_help_cmd(help_cmd);
-
- if (!strcmp(help_cmd, "--web") || !strcmp(help_cmd, "-w")) {
- help_cmd = argc > 2 ? argv[2] : NULL;
- check_help_cmd(help_cmd);
-
- show_html_page(help_cmd);
+ else if (!strcmp(help_cmd, "--web") || !strcmp(help_cmd, "-w")) {
+ show_html_page(argc > 2 ? argv[2] : NULL);
}
else if (!strcmp(help_cmd, "--info") || !strcmp(help_cmd, "-i")) {
- help_cmd = argc > 2 ? argv[2] : NULL;
- check_help_cmd(help_cmd);
-
- show_info_page(help_cmd);
+ show_info_page(argc > 2 ? argv[2] : NULL);
}
else
--
1.5.3.7.2200.g9275-dirty
^ permalink raw reply related
* Re: Git and GCC
From: Johannes Schindelin @ 2007-12-08 12:24 UTC (permalink / raw)
To: J.C. Pizarro; +Cc: Linus Torvalds, David Miller, gcc, git
In-Reply-To: <998d0e4a0712071821o520a75c4lbcaae92256071f48@mail.gmail.com>
Hi,
On Sat, 8 Dec 2007, J.C. Pizarro wrote:
> On 2007/12/07, "Linus Torvalds" <torvalds@linux-foundation.org> wrote:
>
> > SHA1 is almost totally insignificant on x86. It hardly shows up. But
> > we have a good optimized version there.
>
> If SHA1 is slow then why dont he contribute adding Haval160 (3 rounds)
> that it's faster than SHA1? And to optimize still more it with SIMD
> instructions in kernelspace and userland.
He said SHA-1 is insignificant.
> > zlib tends to be a lot more noticeable (especially the uncompression:
> > it may be faster than compression, but it's done _so_ much more that
> > it totally dominates).
>
> It's better
>
> 1. "Don't compress this repo but compact this uncompressed repo
> using minimal spanning forest and deltas"
> 2. "After, compress this whole repo with LZMA (e.g. 48MiB) from 7zip before
> burning it to DVD for backup reasons or before replicating it to
> internet".
Patches? ;-)
Ciao,
Dscho
^ permalink raw reply
* [PATCH 4/4] Add tests for pre-commit and commit-msg hooks
From: Wincent Colaiuta @ 2007-12-08 12:29 UTC (permalink / raw)
To: git; +Cc: gitster, krh, Wincent Colaiuta
In-Reply-To: <1197113889-16243-1-git-send-email-win@wincent.com>
As desired, these pass for git-commit.sh, fail for builtin-commit (prior
to the fixes), and succeeded for builtin-commit (after the fixes).
Signed-off-by: Wincent Colaiuta <win@wincent.com>
---
t/t7501-commit.sh | 2 +-
t/t7503-pre-commit-hook.sh | 64 ++++++++++++++++++++++++++++++++
t/t7504-commit-msg-hook.sh | 88 ++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 153 insertions(+), 1 deletions(-)
create mode 100755 t/t7503-pre-commit-hook.sh
create mode 100755 t/t7504-commit-msg-hook.sh
diff --git a/t/t7501-commit.sh b/t/t7501-commit.sh
index 19c4b2c..05aa97d 100755
--- a/t/t7501-commit.sh
+++ b/t/t7501-commit.sh
@@ -4,7 +4,7 @@
#
# FIXME: Test the various index usages, -i and -o, test reflog,
-# signoff, hooks
+# signoff
test_description='git-commit'
. ./test-lib.sh
diff --git a/t/t7503-pre-commit-hook.sh b/t/t7503-pre-commit-hook.sh
new file mode 100755
index 0000000..c8097a7
--- /dev/null
+++ b/t/t7503-pre-commit-hook.sh
@@ -0,0 +1,64 @@
+#!/bin/sh
+
+test_description='pre-commit hook'
+
+. ./test-lib.sh
+
+test_expect_success "with no hook" \
+ "echo 'foo' > file &&
+ git add file &&
+ git commit -m 'first'"
+
+test_expect_success "--no-verify with no hook" \
+ "echo 'bar' > file &&
+ git add file &&
+ git commit --no-verify -m 'bar'"
+
+# now install hook that always succeeds
+HOOKDIR="$(git rev-parse --git-dir)/hooks"
+HOOK="$HOOKDIR/pre-commit"
+mkdir -p "$HOOKDIR"
+cat > "$HOOK" <<EOF
+#!/bin/sh
+exit 0
+EOF
+chmod +x "$HOOK"
+
+test_expect_success "with succeeding hook" \
+ "echo 'more' >> file &&
+ git add file &&
+ git commit -m 'more'"
+
+test_expect_success "--no-verify with succeeding hook" \
+ "echo 'even more' >> file &&
+ git add file &&
+ git commit --no-verify -m 'even more'"
+
+# now a hook that fails
+cat > "$HOOK" <<EOF
+#!/bin/sh
+exit 1
+EOF
+
+test_expect_failure "with failing hook" \
+ "echo 'another' >> file &&
+ git add file &&
+ git commit -m 'another'"
+
+test_expect_success "--no-verify with failing hook" \
+ "echo 'stuff' >> file &&
+ git add file &&
+ git commit --no-verify -m 'stuff'"
+
+chmod -x "$HOOK"
+test_expect_success "with non-executable hook" \
+ "echo 'content' >> file &&
+ git add file &&
+ git commit -m 'content'"
+
+test_expect_success "--no-verify with non-executable hook" \
+ "echo 'more content' >> file &&
+ git add file &&
+ git commit --no-verify -m 'more content'"
+
+test_done
diff --git a/t/t7504-commit-msg-hook.sh b/t/t7504-commit-msg-hook.sh
new file mode 100755
index 0000000..17aad7c
--- /dev/null
+++ b/t/t7504-commit-msg-hook.sh
@@ -0,0 +1,88 @@
+#!/bin/sh
+
+test_description='commit-msg hook'
+
+. ./test-lib.sh
+
+test_expect_success "with no hook" \
+ "echo 'foo' > file &&
+ git add file &&
+ git commit -m 'first'"
+
+test_expect_success "--no-verify with no hook" \
+ "echo 'bar' > file &&
+ git add file &&
+ git commit --no-verify -m 'bar'"
+
+# now install hook that always succeeds
+HOOKDIR="$(git rev-parse --git-dir)/hooks"
+HOOK="$HOOKDIR/commit-msg"
+mkdir -p "$HOOKDIR"
+cat > "$HOOK" <<EOF
+#!/bin/sh
+exit 0
+EOF
+chmod +x "$HOOK"
+
+test_expect_success "with succeeding hook" \
+ "echo 'more' >> file &&
+ git add file &&
+ git commit -m 'more'"
+
+test_expect_success "--no-verify with succeeding hook" \
+ "echo 'even more' >> file &&
+ git add file &&
+ git commit --no-verify -m 'even more'"
+
+# now a hook that fails
+cat > "$HOOK" <<EOF
+#!/bin/sh
+exit 1
+EOF
+
+test_expect_failure "with failing hook" \
+ "echo 'another' >> file &&
+ git add file &&
+ git commit -m 'another'"
+
+test_expect_success "--no-verify with failing hook" \
+ "echo 'stuff' >> file &&
+ git add file &&
+ git commit --no-verify -m 'stuff'"
+
+chmod -x "$HOOK"
+test_expect_success "with non-executable hook" \
+ "echo 'content' >> file &&
+ git add file &&
+ git commit -m 'content'"
+
+test_expect_success "--no-verify with non-executable hook" \
+ "echo 'more content' >> file &&
+ git add file &&
+ git commit --no-verify -m 'more content'"
+
+# now a hook that edits the commit message
+cat > "$HOOK" <<'EOF'
+#!/bin/sh
+echo "new message" > "$1"
+exit 0
+EOF
+chmod +x "$HOOK"
+
+commit_msg_is () {
+ test "`git log --pretty=format:%s%b -1`" = "$1"
+}
+
+test_expect_success "hook edits commit message" \
+ "echo 'additional' >> file &&
+ git add file &&
+ git commit -m 'additional' &&
+ commit_msg_is 'new message'"
+
+test_expect_success "hook doesn't edit commit message" \
+ "echo 'plus' >> file &&
+ git add file &&
+ git commit --no-verify -m 'plus' &&
+ commit_msg_is 'plus'"
+
+test_done
--
1.5.3.7.1115.g3d1c
^ permalink raw reply related
* Removing redundant packs
From: Petr Baudis @ 2007-12-08 12:50 UTC (permalink / raw)
To: git
Hi,
before exporting whole repo.or.cz over rsync for mirroring, I would
like to clean up the worst repositories (esp. linux-2.6 repositories)
whose objects database looks absolutely horrible now.
At the same time, I have to be careful not to prune all unreferenced
objects since they can be referenced in forks.
How would you go about it? My idea was to do a fresh cummulative pack
of all referenced objects with
git repack -a
and then remove packs that contain _only_ objects that are already in
the fresh pack. But I have trouble with the second step; a very naive
grep loop ran for about a day when I stopped it and it was nowhere near
the half of the packs yet. I didn't figure out how to make use of
git-pack-redundant either.
Does anyone have any hints?
Thanks!
--
Petr "Pasky" Baudis
We don't know who it was that discovered water, but we're pretty sure
that it wasn't a fish. -- Marshall McLuhan
^ permalink raw reply
* Re: [PATCH 4/4] Add tests for pre-commit and commit-msg hooks
From: Wincent Colaiuta @ 2007-12-08 12:51 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: git, gitster, krh
In-Reply-To: <1197116987-21802-1-git-send-email-win@wincent.com>
El 8/12/2007, a las 13:29, Wincent Colaiuta escribió:
> As desired, these pass for git-commit.sh, fail for builtin-commit
> (prior
> to the fixes), and succeeded for builtin-commit (after the fixes).
Actually, that's a slight lie.
The commit-msg tests 9 and 10 (editing the commit message from the
hook) fail for git-commit.sh (tested 1.5.3.4 and 1.5.3.7).
By the looks of it, this discrepancy isn't actually a bug in git-
commit.sh, but is because of stuff that was in commit.c back in
1.5.3.7 and prior which causes a commit message like "foo" to yield
"foo<unknown>" when you do a "git log --pretty=format:%s%b -1"; post
1.5.3.7 (on master) it instead yields "foo", which is what I was
testing for.
Cheers,
Wincent
^ permalink raw reply
* [PATCH] gitweb: Make config_to_multi return [] instead of [undef]
From: Petr Baudis @ 2007-12-08 12:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This is important for the list of clone urls, where if there are
no per-repository clone URL configured, the default base URLs
are never used for URL construction with this patch.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
gitweb/gitweb.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 491a3f4..d5505a4 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1512,7 +1512,7 @@ sub config_to_int {
sub config_to_multi {
my $val = shift;
- return ref($val) ? $val : [ $val ];
+ return ref($val) ? $val : $val ? [ $val ] : [];
}
sub git_get_project_config {
^ permalink raw reply related
* Re: git-svn branch naming question
From: Miklos Vajna @ 2007-12-08 14:14 UTC (permalink / raw)
To: Peter Baumann; +Cc: git
In-Reply-To: <20071208105901.GA2844@xp.machine.xx>
[-- Attachment #1: Type: text/plain, Size: 533 bytes --]
On Sat, Dec 08, 2007 at 11:59:01AM +0100, Peter Baumann <waste.manager@gmx.de> wrote:
> Look up --prefix in the manpage for git-svn.
great, --prefix is what i missed.
a related question: is it possible to avoid even the "remotes" prefix?
it could be useful when creating an incremental import of an svn repo.
(ie when using git-svn as a replacement of git-svnimport.)
so after the clone, one will see all the svn branches as a remote
branch, since they will be local (and not remote) ones in the mirror
repo.
thanks,
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git-bisect feature suggestion: "git-bisect diff"
From: Ingo Molnar @ 2007-12-08 15:29 UTC (permalink / raw)
To: Christian Couder; +Cc: git, Junio C Hamano
In-Reply-To: <200712080636.12982.chriscool@tuxfamily.org>
* Christian Couder <chriscool@tuxfamily.org> wrote:
> > Right now i have this silly git-bisect-diff script:
> >
> > git-log -p "`git-bisect log | grep good | tail -1 | cut -d' '
> > -f3`".."\ `git-bisect log | grep bad | tail -1 | cut -d' ' -f3`"
> >
>
> Tell us if you have other scripts or suggestions related to
> git-bisect.
i have scripts around "git-bisect run" (which are custom to my test
environment so not generally applicable), but perhaps it would be useful
to extend it a little bit to have automatic support for "build error
bisection". 99% of the FOSS packages that developed under git can be
built via "make". So could you perhaps add fully automatic bisection
support that is driven by doing "make" in the current repository?
Currently, in the Linux kernel, if i do this:
$ git-bisect run make -j64 kernel/
it fails with:
running make -j64 kernel/
CHK include/linux/version.h
CHK include/linux/utsrelease.h
CALL scripts/checksyscalls.sh
bisect run failed:
bisect_good exited with error code 1
although the command "make -j64 kernel/" returns with 0.
i have to write a script around "make -j64 kernel/" to get this to work
- it would be nice to have this "out of box".
Ingo
^ permalink raw reply
* [PATCH] Fix off-by-one error: don't read the byte before a malloc'd buffer.
From: Jim Meyering @ 2007-12-08 15:48 UTC (permalink / raw)
To: git list
* config.c (store_write_pair): Don't read value[-1].
Signed-off-by: Jim Meyering <meyering@redhat.com>
---
config.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/config.c b/config.c
index ed96213..6031b38 100644
--- a/config.c
+++ b/config.c
@@ -652,7 +652,7 @@ static int store_write_pair(int fd, const char* key, const char* value)
for (i = 0; value[i]; i++)
if (value[i] == ';' || value[i] == '#')
quote = 1;
- if (value[i-1] == ' ')
+ if (i && value[i-1] == ' ')
quote = 1;
if (write_in_full(fd, "\t", 1) != 1 ||
--
1.5.3.7.1116.gae2a9
^ permalink raw reply related
* Re: [PATCH] gitweb: Make config_to_multi return [] instead of [undef]
From: Jakub Narebski @ 2007-12-08 16:13 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20071208123058.7364.25491.stgit@rover>
Petr Baudis <pasky@suse.cz> writes:
> This is important for the list of clone urls, where if there are
> no per-repository clone URL configured, the default base URLs
> are never used for URL construction with this patch.
Thanks.
> @@ -1512,7 +1512,7 @@ sub config_to_int {
> sub config_to_multi {
> my $val = shift;
>
> - return ref($val) ? $val : [ $val ];
> + return ref($val) ? $val : $val ? [ $val ] : [];
> }
Shouldn't it be
+ return ref($val) ? $val : defined($val) ? [ $val ] : [];
--
Jakub Narebski
^ permalink raw reply
* Re: git-svn branch naming question
From: Peter Baumann @ 2007-12-08 16:56 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20071208141449.GH3199@genesis.frugalware.org>
On Sat, Dec 08, 2007 at 03:14:49PM +0100, Miklos Vajna wrote:
> On Sat, Dec 08, 2007 at 11:59:01AM +0100, Peter Baumann <waste.manager@gmx.de> wrote:
> > Look up --prefix in the manpage for git-svn.
>
> great, --prefix is what i missed.
>
> a related question: is it possible to avoid even the "remotes" prefix?
>
> it could be useful when creating an incremental import of an svn repo.
> (ie when using git-svn as a replacement of git-svnimport.)
>
git svn init --stdlayout creates this entry in your .git/config per default
[svn-remote "svn"]
url = https://url/to/your/svn/repo
fetch = trunk:refs/remotes/trunk
branches = branches/*:refs/remotes/*
tags = tags/*:refs/remotes/tags/*
You could change this to
[svn-remote "svn"]
url = https://url/to/your/svn/repo
fetch = trunk:refs/remotes/origin/trunk
branches = branches/*:refs/remotes/origin/*
tags = tags/*:refs/remotes/origin/tags/*
to get what --prefix origin would do.
On the other hand you could forget completly the remote part by specifying
[svn-remote "svn"]
url = https://url/to/your/svn/repo
fetch = trunk:refs/heads/trunk
branches = branches/*:refs/heads/*
tags = tags/*:refs/heads/tags/*
but I advice you to not do this. refs/remotes has a special meaning in git,
e.g. you can't commit directly to it (which makes sense, because it only
tracks the state of the remote repo. On the other hand remote branches won't
get cloned per default.)
Side note, if you want to track only some branches, or if you have a strange
svn layout, you could use something like this:
[svn-remote "svn"]
url = https://url/to/your/svn/repo
fetch = trunk:refs/remotes/origin/trunk
fetch = branches/branchA:refs/remotes/origin/branchA
fetch = branches/branchB:refs/remotes/origin/branchB
...
-Peter
^ permalink raw reply
* Re: [PATCH 2/2] shortlog: code restruturing and clean-up
From: Alex Riesen @ 2007-12-08 17:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1197077573-14945-2-git-send-email-gitster@pobox.com>
Junio C Hamano, Sat, Dec 08, 2007 02:32:53 +0100:
> Subject: Re: [PATCH 2/2] shortlog: code restruturing and clean-up
restruturing -> restructuring
^ permalink raw reply
* [PATCH] send-email: Allow sleeping between sending mails
From: Dan Nicholson @ 2007-12-08 17:12 UTC (permalink / raw)
To: git
Sometimes when sending many mails, the thread appears out of order for
the recipient. This adds a simple workaround by sleeping between sending
mails. This is controlled by the option --sleep, which defaults to 0.
Since the perl builtin function sleep is used, only integer granularity
is offered. GetOptions seems to perform the necessary checking for this.
Signed-off-by: Dan Nicholson <dbn.lists@gmail.com>
---
Documentation/git-send-email.txt | 5 +++++
git-send-email.perl | 14 +++++++++++++-
2 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 659215a..45341db 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -71,6 +71,11 @@ The --cc option must be repeated for each user you want on the cc list.
Default is the value of 'sendemail.signedoffcc' configuration value;
if that is unspecified, default to --signed-off-by-cc.
+--sleep::
+ Specify an integer number of seconds to sleep between sending
+ mails. This can help when sending many mails at once and they
+ appear out of order for the recipient. Defaults to 0.
+
--quiet::
Make git-send-email less verbose. One line per email should be
all that is output.
diff --git a/git-send-email.perl b/git-send-email.perl
index 76baa8e..a105306 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -100,6 +100,9 @@ Options:
--envelope-sender Specify the envelope sender used to send the emails.
+ --sleep Specify an integer number of seconds to sleep between
+ sending mails. Defaults to 0.
+
EOT
exit(1);
}
@@ -158,6 +161,7 @@ my (@to,@cc,@initial_cc,@bcclist,@xh,
$initial_reply_to,$initial_subject,@files,$author,$sender,$compose,$time);
my $envelope_sender;
+my $mail_index;
# Example reply to:
#$initial_reply_to = ''; #<20050203173208.GA23964@foobar.com>';
@@ -171,7 +175,7 @@ if ($@) {
}
# Behavior modification variables
-my ($quiet, $dry_run) = (0, 0);
+my ($quiet, $dry_run, $sleep_time) = (0, 0, 0);
# Variables with corresponding config settings
my ($thread, $chain_reply_to, $suppress_from, $signed_off_cc, $cc_cmd);
@@ -222,6 +226,7 @@ my $rc = GetOptions("sender|from=s" => \$sender,
"dry-run" => \$dry_run,
"envelope-sender=s" => \$envelope_sender,
"thread!" => \$thread,
+ "sleep=i" => \$sleep_time,
);
unless ($rc) {
@@ -669,6 +674,7 @@ X-Mailer: git-send-email $gitversion
$reply_to = $initial_reply_to;
$references = $initial_reply_to || '';
$subject = $initial_subject;
+$mail_index = 0;
foreach my $t (@files) {
open(F,"<",$t) or die "can't open file $t";
@@ -803,6 +809,12 @@ foreach my $t (@files) {
$references = "$message_id";
}
}
+
+ # sleep if requested and there are any mails left
+ if ($sleep_time > 0 && $mail_index < $#files) {
+ sleep $sleep_time;
+ }
+ $mail_index++;
}
if ($compose) {
--
1.5.3.2
^ permalink raw reply related
* Re: RAM consumption when working with the gcc repo
From: Martin Koegler @ 2007-12-08 17:24 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: david, Jon Smirl, Git Mailing List
In-Reply-To: <alpine.LFD.0.99999.0712071529580.555@xanadu.home>
On Fri, Dec 07, 2007 at 03:46:30PM -0500, Nicolas Pitre wrote:
> On Fri, 7 Dec 2007, david@lang.hm wrote:
> > On Fri, 7 Dec 2007, Jon Smirl wrote:
> >
> > > I noticed two things when doing a repack of the gcc repo. First is
> > > that the git process is getting to be way too big. Turning off the
> > > delta caches had minimal impact. Why does the process still grow to
> > > 4.8GB?
> > >
> > > Putting this in perspective, this is a 4.8GB process constructing a
> > > 330MB file. Something isn't right. Memory leak or inefficient data
> > > structure?
> >
> > keep in mind that that 330MB file is _very_ heavily compressed. the simple
> > zlib compression is probably getting you 10:1 or 20:1 compression and the
> > delta compression is a significant multiplier on top of that.
>
> Doesn't matter. Something is indeed fishy.
>
> The bulk of pack-objects memory consumption can be estimated as follows:
>
> 1M objects * sizeof(struct object_entry) ~= 100MB
> 256 window entries with data (assuming a big 1MB per entry) = 256MB
For each (uncompressed) object in the delta window, a delta index is
created. It can have the same size as the uncompressed object.
Each thread has its own window, so using 4 threads means having 1024 objects
in memory => 1 GB
> Delta result caching was disabled therefore 0MB
> read-side delta cache limited to 16MB
>
> So the purely ram allocation might get to roughly 400MB.
>
> Then add the pack and index map, which, depending on the original pack
> size,
> might be 2GB.
>
> So we're pessimistically talking of about 2.5GB of virtual space.
>
> The other 2.3GB is hard to explain.
mfg Martin Kögler
^ 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