* Re: checkout to a reflog entry
From: bill lam @ 2009-08-25 5:37 UTC (permalink / raw)
To: git
In-Reply-To: <20090825052200.GA15880@coredump.intra.peff.net>
On Tue, 25 Aug 2009, Jeff King wrote:
> A reflog entry is not a branch; it is just a pointer to the commit where
> a branch was at some point. Using "git checkout" on it will let you
> explore the contents, just as you might with a tag. If you want to build
Thank you for explanation on the difference between checkout and
reset.
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
^ permalink raw reply
* Re: [PATCH] fix simple deepening of a repo
From: Junio C Hamano @ 2009-08-25 5:21 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Nicolas Pitre, Julian Phillips, Daniel Barkalow,
Johannes Schindelin, git
In-Reply-To: <20090825021223.GE1033@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> We aren't quite at the 50k ref stage yet, but we're starting to
> consider that some of our repositories have a ton of refs, and
> that the initial advertisement for either fetch or push is horrid.
>
> Since the refs are immutable I could actually teach the JGit
> daemon to hide them from JGit's receive-pack, thus cutting down the
> advertisement on push, but the refs exist so you can literally say:
What do you mean "refs are immutable"?
Do you mean "In the particular application, Gerrit, the server knows that
certain refs will never move nor get deleted, once they are created"? If
so, then I would understand, but otherwise what you are describing is not
git anymore ;-)
And I think it is probably worth thinking things through to find a way to
take advantage of that knowledge.
Even though refs under refs/changes/ hierarchy may have that property, the
client won't know what's available unless you advertise it in some way.
You could assume some offline measure outside the git protocol exists for
clients to find out about them, and protocol extension could say "I do not
want to hear about refs that match these globs during this exchange,
because I have learnt about them offline", and the server could skip
advertisement.
> git fetch --uploadpack='git upload-pack --ref refs/changes/88/4488/2' URL refs/changes/88/4488/2
>
> Personally I'd prefer extending the protocol, because making the
> end user supply information twice is stupid.
In the upload-pack protocol, the server talks first, so it is rather hard
to shoehorn a request from a client to ask "I know about refs/changes/*
hiearchy, so don't talk about them".
I however think it is entirely reasonable to have a server side
configuration that tells upload-pack not to advertise refs/changes/*
hierarchy but still remembers they are OUR_REF. In send_ref() in
upload-pack.c, you'd do something like (I know, I know, you'd be doing
an equivalent of this in jgit):
static const char *capabilities = "multi_ack ...";
struct object *o = parse_object(sha1);
int skip_advertisement = exclude_ref_from_advertisement(refname);
if (!o)
die("git upload-pack: cannot find object %s:", sha1_to_hex(sha1));
if (!skip_advertisement) {
if (capabilities)
packet_write(1, "%s %s%c%s\n", sha1_to_hex(sha1), refname,
0, capabilities);
else
packet_write(1, "%s %s\n", sha1_to_hex(sha1), refname);
capabilities = NULL;
}
if (!(o->flags & OUR_REF)) {
o->flags |= OUR_REF;
nr_our_refs++;
}
if (o->type == OBJ_TAG) {
o = deref_tag(o, refname, 0);
if (o && !skip_advertisement)
packet_write(1, "%s %s^{}\n", sha1_to_hex(o->sha1), refname);
}
return 0;
Doing it this way, receive_needs() will allow refs/changes/88/4488/2 to be
requested, because that is what send_ref() saw and marked as OUR_REF. It
was just not sent to the client. And get_common_commits() will behave the
same with or without this abbreviated advertisement,
Of course, the client side cannot grab everything with refs/*:refs/remotes/*
wildcard refspecs from such a server, but I think that can be considered a
feature.
^ permalink raw reply
* Re: checkout to a reflog entry
From: Jeff King @ 2009-08-25 5:22 UTC (permalink / raw)
To: git
In-Reply-To: <20090825045235.GB391@debian.b2j>
On Tue, Aug 25, 2009 at 12:52:35PM +0800, bill lam wrote:
> project(master)$ git checkout master@{1}
> Note: moving to 'master@{1}' which isn't a local branch
> [...]
> It becomes (no branch) although the SHA1 is correct. If I then
> checkout master, then it revert and jump back up the previous master
> HEAD. I tried HEAD@{xx} also failed. What is the correct way of to
> checkout that master@{..} and stay in that master branch? (Sometimes
> it worked I forgot how and why)
A reflog entry is not a branch; it is just a pointer to the commit where
a branch was at some point. Using "git checkout" on it will let you
explore the contents, just as you might with a tag. If you want to build
on it, you need to either:
1. Make a new branch to work on, starting at that point:
git checkout -b my-topic master@{1}
2. Reset your current branch (and worktree) to point at that commit:
git reset --hard master@{1}
-Peff
^ permalink raw reply
* [PATCH v2 3/3] gitweb: add t9501 tests for checking HTTP status codes
From: Mark Rada @ 2009-08-25 5:03 UTC (permalink / raw)
To: Junio C Hamano, Jakub Narebski; +Cc: git
Commit message changed as suggested by Jakub.
Also added a test_description, and removed a bit of whitespace
that I hadn't noticed before.
--
Mark A Rada (ferrous26)
marada@uwaterloo.ca
--->8---
This commit adds a new test file, t9501, that is used for gitweb
test cases that check HTTP status codes and messages.
Currently, the only tests are for the snapshot feature.
Signed-off-by: Mark Rada <marada@uwaterloo.ca>
---
t/t9501-gitweb-standalone-http-status.sh | 78 ++++++++++++++++++++++++++++++
1 files changed, 78 insertions(+), 0 deletions(-)
create mode 100644 t/t9501-gitweb-standalone-http-status.sh
diff --git a/t/t9501-gitweb-standalone-http-status.sh b/t/t9501-gitweb-standalone-http-status.sh
new file mode 100644
index 0000000..d0ff21d
--- /dev/null
+++ b/t/t9501-gitweb-standalone-http-status.sh
@@ -0,0 +1,78 @@
+#!/bin/sh
+#
+# Copyright (c) 2009 Mark Rada
+#
+
+test_description='gitweb as standalone script (http status tests).
+
+This test runs gitweb (git web interface) as a CGI script from the
+commandline, and checks that it returns the expected HTTP status
+code and message.'
+
+
+. ./gitweb-lib.sh
+
+# ----------------------------------------------------------------------
+# snapshot settings
+
+test_commit \
+ 'SnapshotTests' \
+ 'i can has snapshot?'
+
+cat >>gitweb_config.perl <<\EOF
+$feature{'snapshot'}{'override'} = 0;
+EOF
+
+test_expect_success \
+ 'snapshots: tgz only default format enabled' \
+ 'gitweb_run "p=.git;a=snapshot;h=HEAD;sf=tgz" &&
+ grep "Status: 200 OK" gitweb.output &&
+ gitweb_run "p=.git;a=snapshot;h=HEAD;sf=tbz2" &&
+ grep "403 - Unsupported snapshot format" gitweb.output &&
+ gitweb_run "p=.git;a=snapshot;h=HEAD;sf=txz" &&
+ grep "403 - Snapshot format not allowed" gitweb.output &&
+ gitweb_run "p=.git;a=snapshot;h=HEAD;sf=zip" &&
+ grep "403 - Unsupported snapshot format" gitweb.output'
+test_debug 'cat gitweb.output'
+
+
+cat >>gitweb_config.perl <<\EOF
+$feature{'snapshot'}{'default'} = ['tgz','tbz2','txz','zip'];
+EOF
+
+test_expect_success \
+ 'snapshots: all enabled in default, use default disabled value' \
+ 'gitweb_run "p=.git;a=snapshot;h=HEAD;sf=tgz" &&
+ grep "Status: 200 OK" gitweb.output &&
+ gitweb_run "p=.git;a=snapshot;h=HEAD;sf=tbz2" &&
+ grep "Status: 200 OK" gitweb.output &&
+ gitweb_run "p=.git;a=snapshot;h=HEAD;sf=txz" &&
+ grep "403 - Snapshot format not allowed" gitweb.output &&
+ gitweb_run "p=.git;a=snapshot;h=HEAD;sf=zip" &&
+ grep "Status: 200 OK" gitweb.output'
+test_debug 'cat gitweb.output'
+
+
+cat >>gitweb_config.perl <<\EOF
+$known_snapshot_formats{'zip'}{'disabled'} = 1;
+EOF
+
+test_expect_success \
+ 'snapshots: zip explicitly disabled' \
+ 'gitweb_run "p=.git;a=snapshot;h=HEAD;sf=zip" &&
+ grep "403 - Snapshot format not allowed" gitweb.output'
+test_debug 'cat gitweb.output'
+
+
+cat >>gitweb_config.perl <<\EOF
+$known_snapshot_formats{'tgz'}{'disabled'} = 0;
+EOF
+
+test_expect_success \
+ 'snapshots: tgz explicitly enabled' \
+ 'gitweb_run "p=.git;a=snapshot;h=HEAD;sf=tgz" &&
+ grep "Status: 200 OK" gitweb.output'
+test_debug 'cat gitweb.output'
+
+
+test_done
--
1.6.4
^ permalink raw reply related
* [PATCH v2 2/3] gitweb: split test suite into library and tests
From: Mark Rada @ 2009-08-25 5:00 UTC (permalink / raw)
To: Junio C Hamano, Jakub Narebski; +Cc: git
Change the subject from saying 'break' to 'split', because break
may have given people the wrong idea about what the commit is doing.
I also put the test_description back into t9500, having it in
gitweb-lib.sh was a mistake.
--
Mark A Rada (ferrous26)
marada@uwaterloo.ca
--->8---
To accommodate additions to the tests cases for gitweb, the preamble
from t9500 is now in its own library so that new sets of tests for
gitweb can use the same setup without copying the code.
Signed-off-by: Mark Rada <marada@uwaterloo.ca>
---
t/gitweb-lib.sh | 73 ++++++++++++++++++++++++++++++++
t/t9500-gitweb-standalone-no-errors.sh | 67 +----------------------------
2 files changed, 74 insertions(+), 66 deletions(-)
create mode 100644 t/gitweb-lib.sh
diff --git a/t/gitweb-lib.sh b/t/gitweb-lib.sh
new file mode 100644
index 0000000..8452532
--- /dev/null
+++ b/t/gitweb-lib.sh
@@ -0,0 +1,73 @@
+#!/bin/sh
+#
+# Copyright (c) 2007 Jakub Narebski
+#
+
+gitweb_init () {
+ safe_pwd="$(perl -MPOSIX=getcwd -e 'print quotemeta(getcwd)')"
+ cat >gitweb_config.perl <<EOF
+#!/usr/bin/perl
+
+# gitweb configuration for tests
+
+our \$version = 'current';
+our \$GIT = 'git';
+our \$projectroot = "$safe_pwd";
+our \$project_maxdepth = 8;
+our \$home_link_str = 'projects';
+our \$site_name = '[localhost]';
+our \$site_header = '';
+our \$site_footer = '';
+our \$home_text = 'indextext.html';
+our @stylesheets = ('file:///$TEST_DIRECTORY/../gitweb/gitweb.css');
+our \$logo = 'file:///$TEST_DIRECTORY/../gitweb/git-logo.png';
+our \$favicon = 'file:///$TEST_DIRECTORY/../gitweb/git-favicon.png';
+our \$projects_list = '';
+our \$export_ok = '';
+our \$strict_export = '';
+
+EOF
+
+ cat >.git/description <<EOF
+$0 test repository
+EOF
+}
+
+gitweb_run () {
+ GATEWAY_INTERFACE='CGI/1.1'
+ HTTP_ACCEPT='*/*'
+ REQUEST_METHOD='GET'
+ SCRIPT_NAME="$TEST_DIRECTORY/../gitweb/gitweb.perl"
+ QUERY_STRING=""$1""
+ PATH_INFO=""$2""
+ export GATEWAY_INTERFACE HTTP_ACCEPT REQUEST_METHOD \
+ SCRIPT_NAME QUERY_STRING PATH_INFO
+
+ GITWEB_CONFIG=$(pwd)/gitweb_config.perl
+ export GITWEB_CONFIG
+
+ # some of git commands write to STDERR on error, but this is not
+ # written to web server logs, so we are not interested in that:
+ # we are interested only in properly formatted errors/warnings
+ rm -f gitweb.log &&
+ perl -- "$SCRIPT_NAME" \
+ >gitweb.output 2>gitweb.log &&
+ if grep '^[[]' gitweb.log >/dev/null 2>&1; then false; else true; fi
+
+ # gitweb.log is left for debugging
+ # gitweb.output is used to parse http output
+}
+
+. ./test-lib.sh
+
+if ! test_have_prereq PERL; then
+ say 'skipping gitweb tests, perl not available'
+ test_done
+fi
+
+perl -MEncode -e 'decode_utf8("", Encode::FB_CROAK)' >/dev/null 2>&1 || {
+ say 'skipping gitweb tests, perl version is too old'
+ test_done
+}
+
+gitweb_init
diff --git a/t/t9500-gitweb-standalone-no-errors.sh b/t/t9500-gitweb-standalone-no-errors.sh
index 6275181..2fc7fdb 100755
--- a/t/t9500-gitweb-standalone-no-errors.sh
+++ b/t/t9500-gitweb-standalone-no-errors.sh
@@ -9,73 +9,8 @@ This test runs gitweb (git web interface) as CGI script from
commandline, and checks that it would not write any errors
or warnings to log.'
-gitweb_init () {
- safe_pwd="$(perl -MPOSIX=getcwd -e 'print quotemeta(getcwd)')"
- cat >gitweb_config.perl <<EOF
-#!/usr/bin/perl
-
-# gitweb configuration for tests
-
-our \$version = "current";
-our \$GIT = "git";
-our \$projectroot = "$safe_pwd";
-our \$project_maxdepth = 8;
-our \$home_link_str = "projects";
-our \$site_name = "[localhost]";
-our \$site_header = "";
-our \$site_footer = "";
-our \$home_text = "indextext.html";
-our @stylesheets = ("file:///$TEST_DIRECTORY/../gitweb/gitweb.css");
-our \$logo = "file:///$TEST_DIRECTORY/../gitweb/git-logo.png";
-our \$favicon = "file:///$TEST_DIRECTORY/../gitweb/git-favicon.png";
-our \$projects_list = "";
-our \$export_ok = "";
-our \$strict_export = "";
-EOF
-
- cat >.git/description <<EOF
-$0 test repository
-EOF
-}
-
-gitweb_run () {
- GATEWAY_INTERFACE="CGI/1.1"
- HTTP_ACCEPT="*/*"
- REQUEST_METHOD="GET"
- SCRIPT_NAME="$TEST_DIRECTORY/../gitweb/gitweb.perl"
- QUERY_STRING=""$1""
- PATH_INFO=""$2""
- export GATEWAY_INTERFACE HTTP_ACCEPT REQUEST_METHOD \
- SCRIPT_NAME QUERY_STRING PATH_INFO
-
- GITWEB_CONFIG=$(pwd)/gitweb_config.perl
- export GITWEB_CONFIG
-
- # some of git commands write to STDERR on error, but this is not
- # written to web server logs, so we are not interested in that:
- # we are interested only in properly formatted errors/warnings
- rm -f gitweb.log &&
- perl -- "$SCRIPT_NAME" \
- >/dev/null 2>gitweb.log &&
- if grep "^[[]" gitweb.log >/dev/null 2>&1; then false; else true; fi
-
- # gitweb.log is left for debugging
-}
-
-. ./test-lib.sh
-
-if ! test_have_prereq PERL; then
- say 'skipping gitweb tests, perl not available'
- test_done
-fi
-
-perl -MEncode -e 'decode_utf8("", Encode::FB_CROAK)' >/dev/null 2>&1 || {
- say 'skipping gitweb tests, perl version is too old'
- test_done
-}
-
-gitweb_init
+. ./gitweb-lib.sh
# ----------------------------------------------------------------------
# no commits (empty, just initialized repository)
--
1.6.4
^ permalink raw reply related
* Re: [PATCH] fix simple deepening of a repo
From: Sverre Rabbelier @ 2009-08-25 5:00 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Nicolas Pitre, Julian Phillips, Daniel Barkalow, Junio C Hamano,
Johannes Schindelin, git
In-Reply-To: <20090825021223.GE1033@spearce.org>
Heya,
On Mon, Aug 24, 2009 at 19:12, Shawn O. Pearce<spearce@spearce.org> wrote:
> git fetch --uploadpack='git upload-pack --ref refs/changes/88/4488/2' URL refs/changes/88/4488/2
>
> Personally I'd prefer extending the protocol, because making the
> end user supply information twice is stupid.
$ git fetch --unadvertised URL refs/changes/88/4488/2
And we expand that to the above behind the screens?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* [PATCH v2 1/3] gitweb: improve snapshot error handling
From: Mark Rada @ 2009-08-25 4:59 UTC (permalink / raw)
To: Junio C Hamano, Jakub Narebski; +Cc: git
I reworded the message to be more specific about what code was
being changed.
--
Mark A Rada (ferrous26)
marada@uwaterloo.ca
--->8---
The last check in the second block of checks in the &git_snapshot
routine is never executed because the second last check is a superset
of the last check.
This change will switch the order of the last two checks. It has the
advantage of giving clients a more specific reason why they cannot get
a snapshot format if the format they have chosen is disabled.
Signed-off-by: Mark Rada <marada@uwaterloo.ca>
---
gitweb/gitweb.perl | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 4a42f61..7068db2 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -5174,10 +5174,10 @@ sub git_snapshot {
die_error(400, "Invalid snapshot format parameter");
} elsif (!exists($known_snapshot_formats{$format})) {
die_error(400, "Unknown snapshot format");
- } elsif (!grep($_ eq $format, @snapshot_fmts)) {
- die_error(403, "Unsupported snapshot format");
} elsif ($known_snapshot_formats{$format}{'disabled'}) {
die_error(403, "Snapshot format not allowed");
+ } elsif (!grep($_ eq $format, @snapshot_fmts)) {
+ die_error(403, "Unsupported snapshot format");
}
if (!defined $hash) {
--
1.6.4
^ permalink raw reply related
* checkout to a reflog entry
From: bill lam @ 2009-08-25 4:52 UTC (permalink / raw)
To: git
Sometimes when git reflog and try to checkout to a previous commit,
project((6a33dbc...))$ git reflog show master
77aa688 master@{0}: rebase -i (finish): refs/heads/master onto fc3eaa4
6a33dbc master@{1}: commit: wip
.....
project(master)$ git checkout master@{1}
Note: moving to 'master@{1}' which isn't a local branch
If you want to create a new branch from this checkout, you may do so
(now or later) by using -b with the checkout command again. Example:
git checkout -b <new_branch_name>
HEAD is now at 6a33dbc... wip
project((6a33dbc...))$
project((6a33dbc...))$ git branch
* (no branch)
master
It becomes (no branch) although the SHA1 is correct. If I then checkout master,
then it revert and jump back up the previous master HEAD. I tried HEAD@{xx}
also failed. What is the correct way of to checkout that master@{..} and stay
in that master branch? (Sometimes it worked I forgot how and why)
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
^ permalink raw reply
* Re: hitting home directory's parent
From: Jeff King @ 2009-08-25 4:48 UTC (permalink / raw)
To: Daniel Convissor; +Cc: Git Mailing List
In-Reply-To: <20090823051244.GB10761@panix.com>
On Sun, Aug 23, 2009 at 01:12:44AM -0400, Daniel Convissor wrote:
> That explains what's happening. cmd_help() calls git_config(). Though
> it seems it would be more, uh, helpful, if help produced basic usage
> output no matter what, and then produce the more detailed config based
> output if possible.
I agree, but the way the code is structured right now means doing this
right is probably a pretty big change (see my other message to Duy). So
I think it will probably go unfixed for the time being.
> Is there a bug tracker y'all use where I can enter a ticket?
We don't have a formal bug tracker, but this is really just a sub-part
of another issue, so it will get addressed when the parent issue is
fixed.
-Peff
^ permalink raw reply
* Re: rebase hint unmerged file removed
From: bill lam @ 2009-08-25 4:42 UTC (permalink / raw)
To: git
In-Reply-To: <20090824143657.GA12809@coredump.intra.peff.net>
On Mon, 24 Aug 2009, Jeff King wrote:
> The version of "git status" in next (and presumably what will be in
> v1.6.5) shows unmerged paths with more information. In this case,
Thanks, Jeff, Johannes,
I'll wait to see.
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
^ permalink raw reply
* Re: hitting home directory's parent
From: Jeff King @ 2009-08-25 4:42 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Daniel Convissor, Git Mailing List
In-Reply-To: <fcaeb9bf0908222107i6d999335r998a304aaa3cd405@mail.gmail.com>
On Sun, Aug 23, 2009 at 11:07:39AM +0700, Nguyen Thai Ngoc Duy wrote:
> It is (and should be worked around with GIT_CEILING_DIRECTORIES).
> Unfortunately in my test, it could not chdir() back when it failed to
> find gitdir. chdir() was called with an absolute directory, and one
> directory in that path was inaccesible, leading another die("Cannot
> come back to cwd"). This one is fatal and should not be ignored. I
> don't know whether having an inaccesible parent directory is a real
> scenario, as lots of tools would break.
Hmm, good point. Some of those die()s really can't be removed, because
we have munged state in a way that can't be recovered (or is hard to
recover).
Also, thinking about it a bit more, I'm not sure it is correct to turn
such a die() into a "return -1" without passing more information along
to the caller. Because there are really three possible outcomes:
1. we are in a git repo
2. we are not in a git repo
3. some error occurred and we could not determine which
of (1) and (2) is the case
And the "gently" bit really just refers to (1) versus (2). It is
tempting to fold (3) into (2), but I'm not sure that is the right thing
to do; some callers (including script callers not under our control) may
care about the distinction (though I think we already blur it; for
example, a non-existent '.git' regular file is treated the same as one
which we couldn't stat for permission problems).
So perhaps the right thing is to either pass back a tri-state status, or
to have an extra_gently mode, either of which could be used by "git
help". The problem with either is that the current setup process is not
amenable to exiting in the middle -- it really may leave us in a weird
and buggy state due to the chdir.
So short of major surgery on the setup procedure, I think we may have to
leave this bug be for now (especially because I'm not convinced the
setup of a non-executable parent directory isn't a little bit crazy).
-Peff
^ permalink raw reply
* Re: [PATCH/RFC] make the new block-sha1 the default
From: Jeff King @ 2009-08-25 4:18 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LFD.2.00.0908242249420.6044@xanadu.home>
On Mon, Aug 24, 2009 at 11:04:37PM -0400, Nicolas Pitre wrote:
> ... and remove support for linking against the openssl SHA1 code.
>
> The block-sha1 implementation is not significantly worse and sometimes
> even faster than the openssl SHA1 implementation. This allows for
Is there a reason not to leave the option of linking against openssl?
I'm still getting better numbers for OpenSSL over block-sha1 when doing
"git fsck --full" in some repos. Particularly those with large files and
few deltas, where the time is heavily influenced by sha-1 performance.
I'm seeing up to 20% speed improvement using OpenSSL on those repos, and
about 8% on linux-2.6 (the processor is a Conroe Core 2, git compiled
with -O2).
But what really kills me is that I usually compile git with '-O0'
because I am often investigating bugs and I like the debugger to act
sanely. The performance hit is usually not noticeable, but in this case
it is: my "git fsck --full" times jump from ~8.2s (OpenSSL) and ~10.3s
(block-sha1, -O2) to ~18.2s (block-sha1, -O0).
Certainly you can argue that it is idiotic to benchmark anything at -O0.
But right now, it is perfectly reasonable to compile git with -O0 and
assume OpenSSL is compiled with sane optimizations. I'd rather not take
that away without a good reason.
-Peff
^ permalink raw reply
* [PATCH/RFC] make the new block-sha1 the default
From: Nicolas Pitre @ 2009-08-25 3:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
... and remove support for linking against the openssl SHA1 code.
The block-sha1 implementation is not significantly worse and sometimes
even faster than the openssl SHA1 implementation. This allows for
getting rid of the dependency and runtime linking to openssl which is
a relatively important source of latency when executing git commands.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
OK... So here it is. After all, wanting to get rid of openssl is what
started it all in the first place.
diff --git a/INSTALL b/INSTALL
index ae7f750..55eb962 100644
--- a/INSTALL
+++ b/INSTALL
@@ -52,13 +52,6 @@ Issues of note:
- "zlib", the compression library. Git won't build without it.
- - "openssl". Unless you specify otherwise, you'll get the SHA1
- library from here.
-
- If you don't have openssl, you can use one of the SHA1 libraries
- that come with git (git includes the one from Mozilla, and has
- its own PowerPC and ARM optimized ones too - see the Makefile).
-
- libcurl library; git-http-fetch and git-fetch use them. You
might also want the "curl" executable for debugging purposes.
If you do not use http transfer, you are probably OK if you
diff --git a/Makefile b/Makefile
index 4190a5d..8f28b09 100644
--- a/Makefile
+++ b/Makefile
@@ -16,7 +16,6 @@ all::
# when attempting to read from an fopen'ed directory.
#
# Define NO_OPENSSL environment variable if you do not have OpenSSL.
-# This also implies BLK_SHA1.
#
# Define NO_CURL if you do not have libcurl installed. git-http-pull and
# git-http-push are not built, and you cannot use http:// and https://
@@ -84,10 +83,6 @@ all::
# specify your own (or DarwinPort's) include directories and
# library directories by defining CFLAGS and LDFLAGS appropriately.
#
-# Define BLK_SHA1 environment variable if you want the C version
-# of the SHA1 that assumes you can do unaligned 32-bit loads and
-# have a fast htonl() function.
-#
# Define PPC_SHA1 environment variable when running make to make use of
# a bundled SHA1 routine optimized for PowerPC.
#
@@ -1013,7 +1008,6 @@ ifndef NO_OPENSSL
endif
else
BASIC_CFLAGS += -DNO_OPENSSL
- BLK_SHA1 = 1
OPENSSL_LIBSSL =
endif
ifdef NEEDS_SSL_WITH_CRYPTO
@@ -1162,18 +1156,14 @@ ifdef NO_DEFLATE_BOUND
BASIC_CFLAGS += -DNO_DEFLATE_BOUND
endif
-ifdef BLK_SHA1
- SHA1_HEADER = "block-sha1/sha1.h"
- LIB_OBJS += block-sha1/sha1.o
-else
ifdef PPC_SHA1
SHA1_HEADER = "ppc/sha1.h"
LIB_OBJS += ppc/sha1.o ppc/sha1ppc.o
else
- SHA1_HEADER = <openssl/sha.h>
- EXTLIBS += $(LIB_4_CRYPTO)
-endif
+ SHA1_HEADER = "block-sha1/sha1.h"
+ LIB_OBJS += block-sha1/sha1.o
endif
+
ifdef NO_PERL_MAKEMAKER
export NO_PERL_MAKEMAKER
endif
diff --git a/cache.h b/cache.h
index dd7f71e..39a4edd 100644
--- a/cache.h
+++ b/cache.h
@@ -6,12 +6,6 @@
#include "hash.h"
#include SHA1_HEADER
-#ifndef git_SHA_CTX
-#define git_SHA_CTX SHA_CTX
-#define git_SHA1_Init SHA1_Init
-#define git_SHA1_Update SHA1_Update
-#define git_SHA1_Final SHA1_Final
-#endif
#include <zlib.h>
#if defined(NO_DEFLATE_BOUND) || ZLIB_VERNUM < 0x1200
diff --git a/configure.ac b/configure.ac
index b09b8e4..634186c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -160,7 +160,6 @@ AC_MSG_NOTICE([CHECKS for site configuration])
# a bundled SHA1 routine optimized for PowerPC.
#
# Define NO_OPENSSL environment variable if you do not have OpenSSL.
-# This also implies BLK_SHA1.
#
# Define OPENSSLDIR=/foo/bar if your openssl header and library files are in
# /foo/bar/include and /foo/bar/lib directories.
^ permalink raw reply related
* Re: Possible regression: overwriting untracked files in a fresh repo
From: Jeff King @ 2009-08-25 3:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vk50sve00.fsf@alter.siamese.dyndns.org>
On Mon, Aug 24, 2009 at 07:11:43PM -0700, Junio C Hamano wrote:
> This looks a lot saner; I like it. Care to wrap it up with the usual
> supporting material?
Patch is below. I did a little digging to see the origin of the
current behavior. It looks like invoking "force" was probably the
easiest way to make the shell version work, and then the behavior just
got ported to C (see below for details).
> I think the "You appear to be" can just go, but I do not feel very
> strongly either way.
I don't feel strongly, either. I couldn't think of a reason a user would
care, and it is potentially confusing to new users (though most will
simply clone and never see it), so I ripped it out.
And now you can try your new scissors patch. ;)
-- >8 --
Subject: [PATCH] checkout: do not imply "-f" on unborn branches
When checkout sees that HEAD points to a non-existent ref,
it currently acts as if "-f" was given; this behavior dates
back to 5a03e7f, which enabled checkout from unborn branches
in the shell version of "git-checkout". The reasoning given
is to avoid the code path which tries to merge the tree
contents. When checkout was converted to C, this code
remained intact.
The unfortunate side effect of this strategy is that the
"force" code path will overwrite working tree and index
state that may be precious to the user. Instead of enabling
"force", this patch uses the normal "merge" codepath for an
unborn branch, but substitutes the empty tree for the "old"
commit.
This means that in the absence of an index, any files in the
working tree will be treated as untracked files, and a
checkout which would overwrite them is aborted. Similarly,
any paths in the index will be merged with an empty entry
as the base, meaning that unless the new branch's content is
identical to what's in the index, there will be a conflict
and the checkout will be aborted.
The user is then free to correct the situation or proceed
with "-f" as appropriate.
This patch also removes the "warning: you are on a branch
yet to be born" message. Its function was to warn the user
that we were enabling the "-f" option. Since we are no
longer doing that, there is no reason for the user to care
whether we are switching away from an unborn branch.
Signed-off-by: Jeff King <peff@peff.net>
---
builtin-checkout.c | 12 +++---------
t/t2015-checkout-unborn.sh | 40 ++++++++++++++++++++++++++++++++++++++++
2 files changed, 43 insertions(+), 9 deletions(-)
create mode 100755 t/t2015-checkout-unborn.sh
diff --git a/builtin-checkout.c b/builtin-checkout.c
index 8a9a474..c6d6ac9 100644
--- a/builtin-checkout.c
+++ b/builtin-checkout.c
@@ -402,7 +402,9 @@ static int merge_working_tree(struct checkout_opts *opts,
topts.dir = xcalloc(1, sizeof(*topts.dir));
topts.dir->flags |= DIR_SHOW_IGNORED;
topts.dir->exclude_per_dir = ".gitignore";
- tree = parse_tree_indirect(old->commit->object.sha1);
+ tree = parse_tree_indirect(old->commit ?
+ old->commit->object.sha1 :
+ (unsigned char *)EMPTY_TREE_SHA1_BIN);
init_tree_desc(&trees[0], tree->buffer, tree->size);
tree = parse_tree_indirect(new->commit->object.sha1);
init_tree_desc(&trees[1], tree->buffer, tree->size);
@@ -541,14 +543,6 @@ static int switch_branches(struct checkout_opts *opts, struct branch_info *new)
parse_commit(new->commit);
}
- if (!old.commit && !opts->force) {
- if (!opts->quiet) {
- warning("You appear to be on a branch yet to be born.");
- warning("Forcing checkout of %s.", new->name);
- }
- opts->force = 1;
- }
-
ret = merge_working_tree(opts, &old, new);
if (ret)
return ret;
diff --git a/t/t2015-checkout-unborn.sh b/t/t2015-checkout-unborn.sh
new file mode 100755
index 0000000..c551d39
--- /dev/null
+++ b/t/t2015-checkout-unborn.sh
@@ -0,0 +1,40 @@
+#!/bin/sh
+
+test_description='checkout from unborn branch protects contents'
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+ mkdir parent &&
+ (cd parent &&
+ git init &&
+ echo content >file &&
+ git add file &&
+ git commit -m base
+ ) &&
+ git fetch parent master:origin
+'
+
+test_expect_success 'checkout from unborn preserves untracked files' '
+ echo precious >expect &&
+ echo precious >file &&
+ test_must_fail git checkout -b new origin &&
+ test_cmp expect file
+'
+
+test_expect_success 'checkout from unborn preserves index contents' '
+ echo precious >expect &&
+ echo precious >file &&
+ git add file &&
+ test_must_fail git checkout -b new origin &&
+ test_cmp expect file &&
+ git show :file >file &&
+ test_cmp expect file
+'
+
+test_expect_success 'checkout from unborn merges identical index contents' '
+ echo content >file &&
+ git add file &&
+ git checkout -b new origin
+'
+
+test_done
--
1.6.4.1.330.g14cea.dirty
^ permalink raw reply related
* Re: gitosis-lite
From: Sitaram Chamarty @ 2009-08-25 3:00 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Jakub Narebski, Git Mailing List, Tommi Virtanen
In-Reply-To: <20090824151051.GB1033@spearce.org>
On Mon, Aug 24, 2009 at 8:40 PM, Shawn O. Pearce<spearce@spearce.org> wrote:
> Sitaram Chamarty <sitaramc@gmail.com> wrote:
>> I'll be honest: I
>> came away feeling very stupid after trying to read and
>> understand that program. It was... humbling :(
> *sigh* That's not good, the hook is meant as a practical example,
> if it was too complex to understand, I did a poor job of writing it.
Hmmm no. It was just doing too much to grasp in one
reading, especially by someone whose perl seems to have
rusted a wee bit, if you've seen Jakub's reply :)
I took a slightly longer look after your mail and I grokked
it a lot better. And wow... I guess you called it
"paranoid" for a reason :-)
In the environments I'm catering to, every commit will be
reviewed by someone else (usually someone more experienced,
and having a bigger picture), so "you're not allowed to
touch this file" type of thing will all come out.
All I need is to make sure the important branches can only
be pushed to by certain people; the "process" will take care
of the rest.
^ permalink raw reply
* Re: [PATCH] Add option -b/--branch to clone for select a new HEAD
From: Junio C Hamano @ 2009-08-25 2:13 UTC (permalink / raw)
To: Jeff King; +Cc: Kirill A. Korinskiy, gitster, git
In-Reply-To: <20090825015726.GB7655@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Tue, Aug 25, 2009 at 12:42:48AM +0400, Kirill A. Korinskiy wrote:
>
>> Sometimes (especially on production systems) we need to use only one
>> remote branch for building software. It really annoying to clone
>> origin and then swith branch by hand everytime. So this patch provide
>> functionality to clone remote branch with one command without using
>> checkout after clone.
>
> If you are doing this a lot, it is probably a sign that you should
> repoint the "HEAD" of the parent repository.
>
> That being said, you may want one branch half the time, and another
> branch the other half. So I think this is a good feature.
>
> A few comments:
Very good review snipped, as I agree with everything you said (except that
you did not point out the lack of sign-off).
^ permalink raw reply
* Re: [PATCH] fix simple deepening of a repo
From: Shawn O. Pearce @ 2009-08-25 2:12 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Julian Phillips, Daniel Barkalow, Junio C Hamano,
Johannes Schindelin, git
In-Reply-To: <alpine.LFD.2.00.0908242001250.6044@xanadu.home>
Nicolas Pitre <nico@cam.org> wrote:
> Well... Johan Herland says he has to deal with repositories containing
> around 50000 refs. So in that case it is certainly a good idea not to
> send the whole 50000 refs back if only one or two (or a hundred) need to
> be updated. And quickfetch() won't help in that case since its purpose
> is only to determine if there is anything at all to update.
...
> 50000 refs * 45 bytes each = 2.25 MB. That's all wasted bandwidth if
> only one ref needs updating.
Not just Johan Herland. Gerrit Code Review creates a new ref
for every patch proposed for review. Imagine taking every email
message on git ML that has "[PATCH]" in the subject, and creating
a new ref for that in a git.git clone.
We aren't quite at the 50k ref stage yet, but we're starting to
consider that some of our repositories have a ton of refs, and
that the initial advertisement for either fetch or push is horrid.
Since the refs are immutable I could actually teach the JGit
daemon to hide them from JGit's receive-pack, thus cutting down the
advertisement on push, but the refs exist so you can literally say:
git fetch URL refs/changes/88/4488/2
git show FETCH_HEAD
to inspect the "v2" version of whatever 4488 is, and if 4488 was
the last commit in a patch series, you'd also be able to do:
git log -p --reverse ..FETCH_HEAD
to see the complete series.
Given how infrequent it is to grab a given change is though, I'm
starting to consider either a protocol extension that allows the
client to probe for a ref which wasn't in the initial advertisement,
or take it on a command line flag, e.g.:
git fetch --uploadpack='git upload-pack --ref refs/changes/88/4488/2' URL refs/changes/88/4488/2
Personally I'd prefer extending the protocol, because making the
end user supply information twice is stupid.
I don't know enough about Johan's case though to know whether or
not he can get away with hiding the bulk of the refs in the initial
advertisement. In the case of Gerrit Code Review, the bulk of the
refs is under refs/changes/, only a handful of things are under the
refs/heads/ and ref/tags/ namespace, and most fetches actually are
for only refs/heads/ and refs/tags/. So hiding the refs/changes/
namespace would make large improvement in the advertisement cost.
--
Shawn.
^ permalink raw reply
* Re: Possible regression: overwriting untracked files in a fresh repo
From: Junio C Hamano @ 2009-08-25 2:11 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, git
In-Reply-To: <20090825013601.GA3515@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> diff --git a/builtin-checkout.c b/builtin-checkout.c
> index 8a9a474..1f2f84d 100644
> --- a/builtin-checkout.c
> +++ b/builtin-checkout.c
> @@ -402,7 +402,9 @@ static int merge_working_tree(struct checkout_opts *opts,
> topts.dir = xcalloc(1, sizeof(*topts.dir));
> topts.dir->flags |= DIR_SHOW_IGNORED;
> topts.dir->exclude_per_dir = ".gitignore";
> - tree = parse_tree_indirect(old->commit->object.sha1);
> + tree = parse_tree_indirect(old->commit ?
> + old->commit->object.sha1 :
> + (unsigned char *)EMPTY_TREE_SHA1_BIN);
> init_tree_desc(&trees[0], tree->buffer, tree->size);
> tree = parse_tree_indirect(new->commit->object.sha1);
> init_tree_desc(&trees[1], tree->buffer, tree->size);
This looks a lot saner; I like it. Care to wrap it up with the usual
supporting material?
I think the "You appear to be" can just go, but I do not feel very
strongly either way.
^ permalink raw reply
* Re: [PATCH] Add option -b/--branch to clone for select a new HEAD
From: Jeff King @ 2009-08-25 1:57 UTC (permalink / raw)
To: Kirill A. Korinskiy; +Cc: gitster, git
In-Reply-To: <1251146568-25248-1-git-send-email-catap@catap.ru>
On Tue, Aug 25, 2009 at 12:42:48AM +0400, Kirill A. Korinskiy wrote:
> Sometimes (especially on production systems) we need to use only one
> remote branch for building software. It really annoying to clone
> origin and then swith branch by hand everytime. So this patch provide
> functionality to clone remote branch with one command without using
> checkout after clone.
If you are doing this a lot, it is probably a sign that you should
repoint the "HEAD" of the parent repository.
That being said, you may want one branch half the time, and another
branch the other half. So I think this is a good feature.
A few comments:
> ---
> Documentation/git-clone.txt | 4 ++++
> builtin-clone.c | 26 +++++++++++++++++++++++---
> 2 files changed, 27 insertions(+), 3 deletions(-)
Tests?
> - const struct ref *refs, *head_points_at, *remote_head, *mapped_refs;
> - struct strbuf key = STRBUF_INIT, value = STRBUF_INIT;
> + const struct ref *refs, *head_points_at, *remote_head = NULL, *mapped_refs;
> + struct strbuf key = STRBUF_INIT, value = STRBUF_INIT, branch_head = STRBUF_INIT;
Style nit: I don't know if we have a style guideline for declaring
variables, but I find these "many variables on a line" declarations
annoying for reviewing, since it is hard to see what actually changed
(and yes, you only added a declaration on one, so I am partially
complaining about the person who came before you :) ).
> + if (option_branch)
> + die("--bare and --branch %s options are incompatible.",
> + option_branch);
Hmm. Would it perhaps make sense to have "--bare --branch foo" point the
HEAD of the newly created bare repo, but not impact the (nonexistent)
working tree?
-Peff
^ permalink raw reply
* Re: Possible regression: overwriting untracked files in a fresh repo
From: Jeff King @ 2009-08-25 1:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <20090825013601.GA3515@coredump.intra.peff.net>
On Mon, Aug 24, 2009 at 09:36:01PM -0400, Jeff King wrote:
> I don't think this is the right thing to do. We have _no_ current
> branch, which means that everything in the working tree can be
> considered untracked (and therefore precious). So I think the right
> thing to do is barf and say "this untracked file would be overwritten".
> The user can sort it out as appropriate, either deleting files that are
> in the way, or using "-f" themselves (after they make the decision that
> what they have can be overwritten).
Actually, let me clarify that a bit. If we have no branch _and_ we have
no index, then everything is untracked. If we do have an index, then we
do a two-way merge from the HEAD. So if we have no branch in that case,
it makes sense to me to treat every element of the index as an addition,
meaning that anything in the new tree that is different should be a
conflict.
And that is what my patch does: it pretends that the HEAD is the empty
tree, which should produce sane output in both cases:
$ echo content >file
$ git checkout -b foo origin ;# origin has 'file' in it
error: Untracked working tree file 'file' would be overwritten by merge.
$ git add file
$ git checkout -b foo origin
error: Entry 'file' would be overwritten by merge. Cannot merge.
and it even handles the matching-index case when the merge is a no-op:
$ git show origin:file >file ;# match contents
$ git checkout -b foo origin
error: Untracked working tree file 'file' would be overwritten by merge.
$ git add file
$ git checkout -b foo origin
Switched to a new branch 'foo'
-Peff
^ permalink raw reply
* Re: Possible regression: overwriting untracked files in a fresh repo
From: Jeff King @ 2009-08-25 1:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vab1o3ikz.fsf@alter.siamese.dyndns.org>
On Mon, Aug 24, 2009 at 04:20:12PM -0700, Junio C Hamano wrote:
> I do not think that this is the correct fix, but it should be a good start
> for other people to take a look at the issue. With this change, any
> leftover work tree files will remain, but it has an interesting effect.
>
> $ git checkout maint
> $ echo 'ref: refs/heads/nosuch' >.git/HEAD
> $ git checkout -b foo master
>
> You will notice that the index matches master (as expected), but the work
> tree mostly matches maint. Knowing what these files are (i.e. "these are
> git.git source files that match 'maint' branch, and are vastly behind what
> are in 'master' branch we are switching to"), this result is utterly
> counterintuitive and feels wrong, but if you consider a case like what
> Dscho brought up originally in the thread of having a freshly initialized
> empty repository with some uncommitted files, totally unrelated to what
> you are checking out, I think you could argue that it is the right thing.
I don't think this is the right thing to do. We have _no_ current
branch, which means that everything in the working tree can be
considered untracked (and therefore precious). So I think the right
thing to do is barf and say "this untracked file would be overwritten".
The user can sort it out as appropriate, either deleting files that are
in the way, or using "-f" themselves (after they make the decision that
what they have can be overwritten).
Something like the patch below seems to work on the test case I posted
earlier, and passes the test suite (but other than that, I am very
unconfident, never having really looked at the checkout code before).
As an aside, if an unborn branch stops implying "-f", should we bother
even mentioning it? It seems superfluous now.
---
diff --git a/builtin-checkout.c b/builtin-checkout.c
index 8a9a474..1f2f84d 100644
--- a/builtin-checkout.c
+++ b/builtin-checkout.c
@@ -402,7 +402,9 @@ static int merge_working_tree(struct checkout_opts *opts,
topts.dir = xcalloc(1, sizeof(*topts.dir));
topts.dir->flags |= DIR_SHOW_IGNORED;
topts.dir->exclude_per_dir = ".gitignore";
- tree = parse_tree_indirect(old->commit->object.sha1);
+ tree = parse_tree_indirect(old->commit ?
+ old->commit->object.sha1 :
+ (unsigned char *)EMPTY_TREE_SHA1_BIN);
init_tree_desc(&trees[0], tree->buffer, tree->size);
tree = parse_tree_indirect(new->commit->object.sha1);
init_tree_desc(&trees[1], tree->buffer, tree->size);
@@ -541,13 +543,8 @@ static int switch_branches(struct checkout_opts *opts, struct branch_info *new)
parse_commit(new->commit);
}
- if (!old.commit && !opts->force) {
- if (!opts->quiet) {
- warning("You appear to be on a branch yet to be born.");
- warning("Forcing checkout of %s.", new->name);
- }
- opts->force = 1;
- }
+ if (!old.commit && !opts->force && !opts->quiet)
+ warning("You appear to be on a branch yet to be born.");
ret = merge_working_tree(opts, &old, new);
if (ret)
^ permalink raw reply related
* Re: What's cooking in git.git (Aug 2009, #04; Sun, 23)
From: Brandon Casey @ 2009-08-25 0:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, git
In-Reply-To: <7vy6p86f9y.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Brandon Casey <brandon.casey.ctr@nrlssc.navy.mil> writes:
>
>> Nicolas is right, the code compiles and executes correctly on Solaris as-is.
>>
>> Here is the state of the two unsubmitted optimization patches:
>>
>> 1) Change things like __i386__ to __i386 since GCC defines both, but
>> SUNWspro only defines __i386.
>>
>> This works correctly in my testing. I'm assuming that a test for
>> __amd64 is not necessary and expect that __x86_64 is set whenever
>> __amd64 is set.
>>
>> 2) Set __GNUC__ on SUNWspro v5.10 and up.
>>
>> This compiles correctly and passes the test suite, but produces
>> warnings for __attribute__'s that sun's compiler has not implemented.
>> This produces a very noisy compile.
>>
>> I've wanted to do some performance testing to see whether this actually
>> produces an _improvement_. I'll try today.
>
> Thanks.
>
> I agree (1) would be a reasonable thing to do.
>
> (2) feels very iffy/hacky. As far as I can see, by defining __GNUC__,
> Solaris would also use builtin-alloca in compat/regex/regex.c, which may
> or may not be what you want.
>
> It might be cleaner to do:
>
> #if __GNUC__ || SUNWspro > 5.10
> #define GCC_LIKE_INLINE_ASM
> #define GCC_LIKE_STMT_EXPR
> #endif
>
> and use them, instead of __GNUC__, to enable the inline assembly used in
> the block sha1 codepath.
Yes, this sounds saner, but alas it will have to be tomorrow...
-brandon
^ permalink raw reply
* Re: git-mail-commits (Re:What's a good setup for submitting patches to the list properly?)
From: Nicolas Sebrecht @ 2009-08-25 0:14 UTC (permalink / raw)
To: Julian Phillips; +Cc: Nicolas Sebrecht, Christian Couder, Thell Fowler, git
In-Reply-To: <alpine.LNX.2.00.0908250102580.28400@reaper.quantumfyre.co.uk>
The 25/08/09, Julian Phillips wrote:
> On Mon, 24 Aug 2009, Nicolas Sebrecht wrote:
>
> > I think it worth. That said, I would first add some config options like
> > mail-commits.cc (not reviewed that much yet) to be a bit more consistent
> > with the send-email program. I would also add README and INSTALL files.
>
> Yeah ... it would be nice to have more options settable via config. Some
> form of documentation would also be a good idea, and I would like to tidy
> the code up a bit. Kinda sort on tuits just at the moment though ... :(
Will have help from me. I find it nice to have a python alternative to
send-email. ,-p
> > Could you please consider to place your code under GPLv2?
>
> I have added a license statement.
Thank you. Patches comming.
--
Nicolas Sebrecht
^ permalink raw reply
* Re: [PATCH] fix simple deepening of a repo
From: Nicolas Pitre @ 2009-08-25 0:18 UTC (permalink / raw)
To: Julian Phillips; +Cc: Daniel Barkalow, Junio C Hamano, Johannes Schindelin, git
In-Reply-To: <alpine.LNX.2.00.0908242212260.26869@reaper.quantumfyre.co.uk>
On Mon, 24 Aug 2009, Julian Phillips wrote:
> On Mon, 24 Aug 2009, Daniel Barkalow wrote:
>
> > On Sun, 23 Aug 2009, Junio C Hamano wrote:
> >
> > > What is the point of not asking for the refs that we know are the same?
> >
> > This code is part of the original C implementation of fetch; I suspect the
> > optimization was somehow in the shell version and made sense there,
> > perhaps because there wasn't a quickfetch in the shell version or that
> > there was some non-negligable per-ref cost in the code around there, since
> > it was calling helper programs and such.
>
> I don't remember copying it from the shell version but my memory is terrible,
> so I could easily be wrong. The relevant commit message was:
>
> "git-fetch2: remove ref_maps that are not interesting
>
> Once we have the full list of ref_maps, remove any where the local
> and remote sha1s are the same - as we don't need to do anything for
> them."
>
> So that doesn't help. I was very concerned about performance though (which
> was why I wanted fetch in C in the first place), so may have added it to speed
> up fetches that have only updated a few refs - and I assume that quickfetch
> was something that came along later after you absorbed the work into the
> transport series?
Well... Johan Herland says he has to deal with repositories containing
around 50000 refs. So in that case it is certainly a good idea not to
send the whole 50000 refs back if only one or two (or a hundred) need to
be updated. And quickfetch() won't help in that case since its purpose
is only to determine if there is anything at all to update.
> > Anyway, I think it makes sense to remove the filtering from
> > transport_fetch_refs(), like your patch does.
> >
> > If it makes a difference for the actual protocol, fetch_refs_via_pack()
> > could filter them at that stage.
>
> I think it would certainly be worth investigating the performance aspects ...
> no time tonight, but maybe tomorrow.
50000 refs * 45 bytes each = 2.25 MB. That's all wasted bandwidth if
only one ref needs updating.
Nicolas
^ permalink raw reply
* Re: git-mail-commits (Re:What's a good setup for submitting patches to the list properly?)
From: Julian Phillips @ 2009-08-25 0:06 UTC (permalink / raw)
To: Nicolas Sebrecht; +Cc: Christian Couder, Thell Fowler, git
In-Reply-To: <20090823234108.GB3526@vidovic>
On Mon, 24 Aug 2009, Nicolas Sebrecht wrote:
> The 24/08/09, Julian Phillips wrote:
>> On Sun, 23 Aug 2009, Christian Couder wrote:
>>
>> Using the awsome power of git I have managed to extract it from my random
>> tools private repo to here as if I had written it to be a separate entity
>> from the start:
>>
>> git://git.q42.co.uk/mail_commits.git
>> (gitweb: http://git.q42.co.uk/w/mail_commits.git)
>
> Thanks a lot.
>
>> If it would be considered useful, then I can also create a patch to add
>> it to contrib
>
> I think it worth. That said, I would first add some config options like
> mail-commits.cc (not reviewed that much yet) to be a bit more consistent
> with the send-email program. I would also add README and INSTALL files.
Yeah ... it would be nice to have more options settable via config. Some
form of documentation would also be a good idea, and I would like to tidy
the code up a bit. Kinda sort on tuits just at the moment though ... :(
> Could you please consider to place your code under GPLv2?
I have added a license statement.
--
Julian
---
Thus spake the master programmer:
"When a program is being tested, it is too late to make design changes."
-- Geoffrey James, "The Tao of Programming"
^ 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