* Re: [ANNOUNCE] Git User's Survey 2011
From: Miles Bader @ 2011-09-05 5:37 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <201109050243.21299.jnareb@gmail.com>
Hmmm, a cool thing about the git survey is that I learn quite a few
new things (commands/concepts/websites) from it ...
Especially when it comes to various documentation/help/tool resources,
it's a nice concise list!
-miles
--
The key to happiness
is having dreams. [from a fortune cookie]
^ permalink raw reply
* [PATCH] shell portability: Use sed instead of non-portable variable expansion
From: Naohiro Aota @ 2011-09-05 5:11 UTC (permalink / raw)
To: git; +Cc: gitster, tarmigan+git
Variable expansions like "${foo#bar}" or "${foo%bar}" doesn't work on
shells like FreeBSD sh and they made the test to fail. This patch
replace such variable expansions with sed.
Signed-off-by: Naohiro Aota <naota@elisp.net>
---
Testing on FreeBSD failed because of this "bash-ism". After applying
this patch, I've verified the test to pass on FreeBSD. (and it worked
well also with GNU sed)
t/t5560-http-backend-noserver.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t5560-http-backend-noserver.sh b/t/t5560-http-backend-noserver.sh
index 0ad7ce0..c8237ef 100755
--- a/t/t5560-http-backend-noserver.sh
+++ b/t/t5560-http-backend-noserver.sh
@@ -9,8 +9,8 @@ test_have_prereq MINGW && export GREP_OPTIONS=-U
run_backend() {
echo "$2" |
- QUERY_STRING="${1#*\?}" \
- PATH_TRANSLATED="$HTTPD_DOCUMENT_ROOT_PATH/${1%%\?*}" \
+ QUERY_STRING=$(echo "$1"|sed -e 's/^[^?]*?\(.*\)$/\1/') \
+ PATH_TRANSLATED="$HTTPD_DOCUMENT_ROOT_PATH/$(echo "$1"|sed -e 's/^\([^?]*\)?.*$/\1/')" \
git http-backend >act.out 2>act.err
}
--
1.7.6
^ permalink raw reply related
* Re: git push output goes into stderr
From: Sitaram Chamarty @ 2011-09-05 4:39 UTC (permalink / raw)
To: Lynn Lin; +Cc: git
In-Reply-To: <CAPgpnMQuck_aPU0ciaGgj-C8rno7jbzZ7wZ4unU8CqA0eaiYQw@mail.gmail.com>
On Sun, Sep 4, 2011 at 2:56 PM, Lynn Lin <lynn.xin.lin@gmail.com> wrote:
> Hi all,
> When I create a local branch and then push it to remote. I find that
> the output without error goes into stderr, is this expected?
when the two sides of the conversation have an established protocol to
talk to each other and exchange data, any extraneous stuff (progress
message, tracing/debugging logs...) will confuse the protocol.
Shunting that aside to STDERR helps avoid protocol confusion.
^ permalink raw reply
* Pushing with --mirror over HTTP?
From: Eli Barzilay @ 2011-09-05 4:05 UTC (permalink / raw)
To: git
Is there anything broken with pushing with mirror over HTTP? I'm
trying that with a github url, and I get a broken-looking error
message:
remote part of refspec is not a valid name in :.have
and with the google code, I get:
error: unable to push to unqualified destination: HEAD
Pushing to both of these work fine without `--mirror'.
(BTW, as a workaround, I'm using
push --force --tags <url> :
is this achieving the same effect for a repo without weird refs?)
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
^ permalink raw reply
* Re: [PATCH 3/3] push: old receive-pack does not understand --quiet
From: Junio C Hamano @ 2011-09-05 3:01 UTC (permalink / raw)
To: git; +Cc: Clemens Buchacher, tobiasu
In-Reply-To: <7vy5y3yb6x.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Clemens Buchacher <drizzd@aon.at> writes:
> ...
>> @@ -636,6 +637,8 @@ static struct command *read_head_info(void)
>> report_status = 1;
>> if (strstr(refname + reflen + 1, "side-band-64k"))
>> use_sideband = LARGE_PACKET_MAX;
>> + if (strstr(refname + reflen + 1, "quiet"))
>> + quiet = 1;
>
> Side note.
>
> We may want to make sure that this is not part of a different token word
> (if we knew better, we would have written the other side so that we can
> just test against " quiet ", but that is not possible, sigh...).
... but we can do this.
-- >8 --
Subject: [PATCH] server_supports(): parse feature list more carefully
We have been carefully choosing feature names used in the protocol
extensions so that the vocabulary does not contain a word that is a
substring of another word, so it is not a real problem, but we have
recently added "quiet" feature word, which would mean we cannot later
add some other word with "quiet" (e.g. "quiet-push"), which is awkward.
Let's make sure that we can eventually be able to do so by teaching the
clients and servers that feature words consist of non whitespace
letters. This parser also allows us to later add features with parameters
e.g. "feature=1.5" (parameter values need to be quoted for whitespaces,
but we will worry about the detauls when we do introduce them).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin/receive-pack.c | 7 ++++---
cache.h | 1 +
connect.c | 23 +++++++++++++++++++++--
upload-pack.c | 22 +++++++++++++---------
4 files changed, 39 insertions(+), 14 deletions(-)
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index b71a1ca..927f307 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -600,11 +600,12 @@ static struct command *read_head_info(void)
refname = line + 82;
reflen = strlen(refname);
if (reflen + 82 < len) {
- if (strstr(refname + reflen + 1, "report-status"))
+ const char *feature_list = refname + reflen + 1;
+ if (parse_feature_request(feature_list, "report-status"))
report_status = 1;
- if (strstr(refname + reflen + 1, "side-band-64k"))
+ if (parse_feature_request(feature_list, "side-band-64k"))
use_sideband = LARGE_PACKET_MAX;
- if (strstr(refname + reflen + 1, "quiet"))
+ if (parse_feature_request(feature_list, "quiet"))
quiet = 1;
}
cmd = xcalloc(1, sizeof(struct command) + len - 80);
diff --git a/cache.h b/cache.h
index e11cf6a..2933d04 100644
--- a/cache.h
+++ b/cache.h
@@ -996,6 +996,7 @@ struct extra_have_objects {
};
extern struct ref **get_remote_heads(int in, struct ref **list, int nr_match, char **match, unsigned int flags, struct extra_have_objects *);
extern int server_supports(const char *feature);
+extern const char *parse_feature_request(const char *features, const char *feature);
extern struct packed_git *parse_pack_index(unsigned char *sha1, const char *idx_path);
diff --git a/connect.c b/connect.c
index 2119c3f..2184fd8 100644
--- a/connect.c
+++ b/connect.c
@@ -104,8 +104,27 @@ struct ref **get_remote_heads(int in, struct ref **list,
int server_supports(const char *feature)
{
- return server_capabilities &&
- strstr(server_capabilities, feature) != NULL;
+ return !!parse_feature_request(server_capabilities, feature);
+}
+
+const char *parse_feature_request(const char *feature_list, const char *feature)
+{
+ int len;
+
+ if (!feature_list)
+ return NULL;
+
+ len = strlen(feature);
+ while (*feature_list) {
+ const char *found = strstr(feature_list, feature);
+ if (!found)
+ return NULL;
+ if ((feature_list == found || isspace(found[-1])) &&
+ (!found[len] || isspace(found[len]) || found[len] == '='))
+ return found;
+ feature_list = found + 1;
+ }
+ return NULL;
}
int path_match(const char *path, int nr, char **match)
diff --git a/upload-pack.c b/upload-pack.c
index ce5cbbe..a47a556 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -509,6 +509,7 @@ static void receive_needs(void)
write_str_in_full(debug_fd, "#S\n");
for (;;) {
struct object *o;
+ const char *features;
unsigned char sha1_buf[20];
len = packet_read_line(0, line, sizeof(line));
reset_timeout();
@@ -540,23 +541,26 @@ static void receive_needs(void)
get_sha1_hex(line+5, sha1_buf))
die("git upload-pack: protocol error, "
"expected to get sha, not '%s'", line);
- if (strstr(line+45, "multi_ack_detailed"))
+
+ features = line + 45;
+
+ if (parse_feature_request(features, "multi_ack_detailed"))
multi_ack = 2;
- else if (strstr(line+45, "multi_ack"))
+ else if (parse_feature_request(features, "multi_ack"))
multi_ack = 1;
- if (strstr(line+45, "no-done"))
+ if (parse_feature_request(features, "no-done"))
no_done = 1;
- if (strstr(line+45, "thin-pack"))
+ if (parse_feature_request(features, "thin-pack"))
use_thin_pack = 1;
- if (strstr(line+45, "ofs-delta"))
+ if (parse_feature_request(features, "ofs-delta"))
use_ofs_delta = 1;
- if (strstr(line+45, "side-band-64k"))
+ if (parse_feature_request(features, "side-band-64k"))
use_sideband = LARGE_PACKET_MAX;
- else if (strstr(line+45, "side-band"))
+ else if (parse_feature_request(features, "side-band"))
use_sideband = DEFAULT_PACKET_MAX;
- if (strstr(line+45, "no-progress"))
+ if (parse_feature_request(features, "no-progress"))
no_progress = 1;
- if (strstr(line+45, "include-tag"))
+ if (parse_feature_request(features, "include-tag"))
use_include_tag = 1;
/* We have sent all our refs already, and the other end
--
1.7.7.rc0.175.gb3212
^ permalink raw reply related
* [ANNOUNCE] cj-git-splitrepo & removing 'empty' merge commits with filter-branch
From: Christian Jaeger @ 2011-09-05 2:34 UTC (permalink / raw)
To: git
Hello
I've needed a program to split a repository into multiple
repositories, each with part of the history according to file path
rules. I already wrote a wrapper around git filter-branch that took
care of the path filtering, but this time I finally wanted to take
care of merge commits that "do nothing", i.e. that have one parent
commit with the same tree as the merge commit and another parent
that's part of the history of the other parent. (Similar rule for
octopus merges if I happen to ever run across one of these.)
git-filter-branch doesn't have functionality to remove these by
itself, thus a custom commit filter is needed.
This turned out to be a bit of an adventure because arrays are really
well suited for this, but I've rarely used them in shell scripts, so I
tracked down the necessary syntactical vodoo for writing my code in
bash, only to find out that git filter-branch is actually calling my
code in sh, not bash (hence no arrays). After realizing this, and
coping with it by moving my code inside a bash invocation (and making
a copy of the library code from git-filter-branch--why isn't this in a
separate file, btw, then I could just include it from there?), I
thought I should perhaps send you all a notice about it, in case
anyone else wanted to split repositories cleanly, too. Or in case
someone wanted to point out that I'm doing this in a stupid way or a
nice solution exists elsewhere already: please tell me about it!
So, here's my wrapper around git-filter-branch that is able to remove
paths (including whole directories) and removes 'empty' merges:
https://github.com/pflanze/chj-bin/blob/master/cj-git-filter-branch
And a wrapper around cj-git-filter-branch that makes creating a
partial copy of a repository easy:
https://github.com/pflanze/chj-bin/blob/master/cj-git-splitrepo
If you want to actually run these, you need some of my libraries:
# cd /opt; mkdir chj; cd chj
# git clone https://github.com/pflanze/chj-perllib.git perllib
# git clone https://github.com/pflanze/chj-bin.git bin
# git clone https://github.com/pflanze/Class-Array.git
# mkdir /usr/local/lib/site_perl/ # if it doesn't exist already
# ln -s /opt/chj/perllib/Chj /usr/local/lib/site_perl/
# ln -s /opt/chj/Class-Array /usr/local/lib/site_perl/Class
and add /opt/chj/bin to your PATH (through your .bash_profile or
similar)
(or you could supposedly use the PERL5LIB env var instead of symlinks).
Christian.
^ permalink raw reply
* Re: [PATCH 3/3] push: old receive-pack does not understand --quiet
From: Junio C Hamano @ 2011-09-05 2:28 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: git, tobiasu
In-Reply-To: <1315067656-2846-4-git-send-email-drizzd@aon.at>
Clemens Buchacher <drizzd@aon.at> writes:
> @@ -114,7 +115,7 @@ static int show_ref(const char *path, const unsigned char *sha1, int flag, void
> else
> packet_write(1, "%s %s%c%s%s\n",
> sha1_to_hex(sha1), path, 0,
> - " report-status delete-refs side-band-64k",
> + " report-status delete-refs side-band-64k quiet",
> prefer_ofs_delta ? " ofs-delta" : "");
> sent_capabilities = 1;
> return 0;
> @@ -636,6 +637,8 @@ static struct command *read_head_info(void)
> report_status = 1;
> if (strstr(refname + reflen + 1, "side-band-64k"))
> use_sideband = LARGE_PACKET_MAX;
> + if (strstr(refname + reflen + 1, "quiet"))
> + quiet = 1;
Side note.
We may want to make sure that this is not part of a different token word
(if we knew better, we would have written the other side so that we can
just test against " quiet ", but that is not possible, sigh...).
> }
> cmd = xcalloc(1, sizeof(struct command) + len - 80);
> hashcpy(cmd->old_sha1, old_sha1);
> @@ -669,7 +672,7 @@ static const char *parse_pack_header(struct pack_header *hdr)
>
> static const char *pack_lockfile;
>
> -static const char *unpack(int quiet)
> +static const char *unpack()
I'll amend this as "static const char *unpack(void)" while applying.
^ permalink raw reply
* [PATCH 2/3] transfer.fsckobjects: unify fetch/receive.fsckobjects
From: Junio C Hamano @ 2011-09-05 2:21 UTC (permalink / raw)
To: git
In-Reply-To: <1315189297-19497-1-git-send-email-gitster@pobox.com>
This single variable can be used to set instead of setting fsckobjects
variable for fetch & receive independently.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/config.txt | 11 +++++++++--
builtin/fetch-pack.c | 14 ++++++++++++--
builtin/receive-pack.c | 17 ++++++++++++++---
3 files changed, 35 insertions(+), 7 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 4cbc4b9..d944403 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -824,7 +824,8 @@ fetch.fsckObjects::
If it is set to true, git-fetch-pack will check all fetched
objects. It will abort in the case of a malformed object or a
broken link. The result of an abort are only dangling objects.
- Defaults to false.
+ Defaults to false. If not set, the value of `transfer.fsckObjects`
+ is used instead.
fetch.unpackLimit::
If the number of objects fetched over the git native
@@ -1427,7 +1428,8 @@ receive.fsckObjects::
If it is set to true, git-receive-pack will check all received
objects. It will abort in the case of a malformed object or a
broken link. The result of an abort are only dangling objects.
- Defaults to false.
+ Defaults to false. If not set, the value of `transfer.fsckObjects`
+ is used instead.
receive.unpackLimit::
If the number of objects received in a push is below this
@@ -1616,6 +1618,11 @@ tar.umask::
archiving user's umask will be used instead. See umask(2) and
linkgit:git-archive[1].
+transfer.fsckObjects::
+ When `fetch.fsckObjects` or `receive.fsckObjects` are
+ not set, the value of this variable is used instead.
+ Defaults to false.
+
transfer.unpackLimit::
When `fetch.unpackLimit` or `receive.unpackLimit` are
not set, the value of this variable is used instead.
diff --git a/builtin/fetch-pack.c b/builtin/fetch-pack.c
index df6a8dc..dac3038 100644
--- a/builtin/fetch-pack.c
+++ b/builtin/fetch-pack.c
@@ -14,7 +14,8 @@ static int transfer_unpack_limit = -1;
static int fetch_unpack_limit = -1;
static int unpack_limit = 100;
static int prefer_ofs_delta = 1;
-static int fetch_fsck_objects;
+static int fetch_fsck_objects = -1;
+static int transfer_fsck_objects = -1;
static struct fetch_pack_args args = {
/* .uploadpack = */ "git-upload-pack",
};
@@ -664,7 +665,11 @@ static int get_pack(int xd[2], char **pack_lockfile)
}
if (*hdr_arg)
*av++ = hdr_arg;
- if (fetch_fsck_objects)
+ if (fetch_fsck_objects >= 0
+ ? fetch_fsck_objects
+ : transfer_fsck_objects >= 0
+ ? transfer_fsck_objects
+ : 0)
*av++ = "--strict";
*av++ = NULL;
@@ -784,6 +789,11 @@ static int fetch_pack_config(const char *var, const char *value, void *cb)
return 0;
}
+ if (!strcmp(var, "transfer.fsckobjects")) {
+ transfer_fsck_objects = git_config_bool(var, value);
+ return 0;
+ }
+
return git_default_config(var, value, cb);
}
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index 0559fcc..021ea65 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -23,7 +23,8 @@ static int deny_deletes;
static int deny_non_fast_forwards;
static enum deny_action deny_current_branch = DENY_UNCONFIGURED;
static enum deny_action deny_delete_current = DENY_UNCONFIGURED;
-static int receive_fsck_objects;
+static int receive_fsck_objects = -1;
+static int transfer_fsck_objects = -1;
static int receive_unpack_limit = -1;
static int transfer_unpack_limit = -1;
static int unpack_limit = 100;
@@ -77,6 +78,11 @@ static int receive_pack_config(const char *var, const char *value, void *cb)
return 0;
}
+ if (strcmp(var, "transfer.fsckobjects") == 0) {
+ transfer_fsck_objects = git_config_bool(var, value);
+ return 0;
+ }
+
if (!strcmp(var, "receive.denycurrentbranch")) {
deny_current_branch = parse_deny_action(var, value);
return 0;
@@ -586,6 +592,11 @@ static const char *unpack(void)
struct pack_header hdr;
const char *hdr_err;
char hdr_arg[38];
+ int fsck_objects = (receive_fsck_objects >= 0
+ ? receive_fsck_objects
+ : transfer_fsck_objects >= 0
+ ? transfer_fsck_objects
+ : 0);
hdr_err = parse_pack_header(&hdr);
if (hdr_err)
@@ -598,7 +609,7 @@ static const char *unpack(void)
int code, i = 0;
const char *unpacker[4];
unpacker[i++] = "unpack-objects";
- if (receive_fsck_objects)
+ if (fsck_objects)
unpacker[i++] = "--strict";
unpacker[i++] = hdr_arg;
unpacker[i++] = NULL;
@@ -618,7 +629,7 @@ static const char *unpack(void)
keeper[i++] = "index-pack";
keeper[i++] = "--stdin";
- if (receive_fsck_objects)
+ if (fsck_objects)
keeper[i++] = "--strict";
keeper[i++] = "--fix-thin";
keeper[i++] = hdr_arg;
--
1.7.7.rc0.175.gb3212
^ permalink raw reply related
* [PATCH 3/3] test: fetch/receive with fsckobjects
From: Junio C Hamano @ 2011-09-05 2:21 UTC (permalink / raw)
To: git
In-Reply-To: <1315189297-19497-1-git-send-email-gitster@pobox.com>
Add tests for the new fetch.fsckobjects, and also tests for
receive.fsckobjects we have had for quite some time.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
t/t5504-fetch-receive-strict.sh | 104 +++++++++++++++++++++++++++++++++++++++
1 files changed, 104 insertions(+), 0 deletions(-)
create mode 100755 t/t5504-fetch-receive-strict.sh
diff --git a/t/t5504-fetch-receive-strict.sh b/t/t5504-fetch-receive-strict.sh
new file mode 100755
index 0000000..6610012
--- /dev/null
+++ b/t/t5504-fetch-receive-strict.sh
@@ -0,0 +1,104 @@
+#!/bin/sh
+
+test_description='fetch/receive strict mode'
+. ./test-lib.sh
+
+test_expect_success setup '
+ echo hello >greetings &&
+ git add greetings &&
+ git commit -m greetings &&
+
+ S=$(git rev-parse :greetings | sed -e "s|^..|&/|") &&
+ X=$(echo bye | git hash-object -w --stdin | sed -e "s|^..|&/|") &&
+ mv -f .git/objects/$X .git/objects/$S &&
+
+ test_must_fail git fsck
+'
+
+test_expect_success 'fetch without strict' '
+ rm -rf dst &&
+ git init dst &&
+ (
+ cd dst &&
+ git config fetch.fsckobjects false &&
+ git config transfer.fsckobjects false &&
+ git fetch ../.git master
+ )
+'
+
+test_expect_success 'fetch with !fetch.fsckobjects' '
+ rm -rf dst &&
+ git init dst &&
+ (
+ cd dst &&
+ git config fetch.fsckobjects false &&
+ git config transfer.fsckobjects true &&
+ git fetch ../.git master
+ )
+'
+
+test_expect_success 'fetch with fetch.fsckobjects' '
+ rm -rf dst &&
+ git init dst &&
+ (
+ cd dst &&
+ git config fetch.fsckobjects true &&
+ git config transfer.fsckobjects false &&
+ test_must_fail git fetch ../.git master
+ )
+'
+
+test_expect_success 'fetch with transfer.fsckobjects' '
+ rm -rf dst &&
+ git init dst &&
+ (
+ cd dst &&
+ git config transfer.fsckobjects true &&
+ test_must_fail git fetch ../.git master
+ )
+'
+
+test_expect_success 'push without strict' '
+ rm -rf dst &&
+ git init dst &&
+ (
+ cd dst &&
+ git config fetch.fsckobjects false &&
+ git config transfer.fsckobjects false
+ ) &&
+ git push dst master:refs/heads/test
+'
+
+test_expect_success 'push with !receive.fsckobjects' '
+ rm -rf dst &&
+ git init dst &&
+ (
+ cd dst &&
+ git config receive.fsckobjects false &&
+ git config transfer.fsckobjects true
+ ) &&
+ git push dst master:refs/heads/test
+'
+
+test_expect_success 'push with receive.fsckobjects' '
+ rm -rf dst &&
+ git init dst &&
+ (
+ cd dst &&
+ git config receive.fsckobjects true &&
+ git config transfer.fsckobjects false
+ ) &&
+ test_must_fail git push dst master:refs/heads/test
+'
+
+test_expect_success 'push with transfer.fsckobjects' '
+ rm -rf dst &&
+ git init dst &&
+ (
+ cd dst &&
+ git config transfer.fsckobjects true
+ ) &&
+ test_must_fail git push dst master:refs/heads/test
+'
+
+test_done
--
1.7.7.rc0.175.gb3212
^ permalink raw reply related
* [PATCH 0/3] Add fetch.fsckobjects
From: Junio C Hamano @ 2011-09-05 2:21 UTC (permalink / raw)
To: git
In-Reply-To: <7vliu4yv8w.fsf@alter.siamese.dyndns.org>
Interestingly enough, when we added receive.fsckobjects long time ago,
for some reason we forgot to add the corresponding fetch.fsckobjects,
which would have been an obvious thing to do.
So here is a series to add it.
Junio C Hamano (3):
fetch.fsckobjects: verify downloaded objects
transfer.fsckobjects: unify fetch/receive.fsckobjects
test: fetch/receive with fsckobjects
Documentation/config.txt | 15 +++++-
builtin/fetch-pack.c | 18 +++++++
builtin/receive-pack.c | 17 +++++-
t/t5504-fetch-receive-strict.sh | 104 +++++++++++++++++++++++++++++++++++++++
4 files changed, 150 insertions(+), 4 deletions(-)
create mode 100755 t/t5504-fetch-receive-strict.sh
--
1.7.7.rc0.175.gb3212
^ permalink raw reply
* [PATCH 1/3] fetch.fsckobjects: verify downloaded objects
From: Junio C Hamano @ 2011-09-05 2:21 UTC (permalink / raw)
To: git
In-Reply-To: <1315189297-19497-1-git-send-email-gitster@pobox.com>
This corresponds to receive.fsckobjects configuration variable added (a
lot) earlier in 20dc001 (receive-pack: allow using --strict mode for
unpacking objects, 2008-02-25).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/config.txt | 6 ++++++
builtin/fetch-pack.c | 8 ++++++++
2 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 664de6b..4cbc4b9 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -820,6 +820,12 @@ diff.wordRegex::
sequences that match the regular expression are "words", all other
characters are *ignorable* whitespace.
+fetch.fsckObjects::
+ If it is set to true, git-fetch-pack will check all fetched
+ objects. It will abort in the case of a malformed object or a
+ broken link. The result of an abort are only dangling objects.
+ Defaults to false.
+
fetch.unpackLimit::
If the number of objects fetched over the git native
transfer is below this
diff --git a/builtin/fetch-pack.c b/builtin/fetch-pack.c
index dbd8b7b..df6a8dc 100644
--- a/builtin/fetch-pack.c
+++ b/builtin/fetch-pack.c
@@ -14,6 +14,7 @@ static int transfer_unpack_limit = -1;
static int fetch_unpack_limit = -1;
static int unpack_limit = 100;
static int prefer_ofs_delta = 1;
+static int fetch_fsck_objects;
static struct fetch_pack_args args = {
/* .uploadpack = */ "git-upload-pack",
};
@@ -663,6 +664,8 @@ static int get_pack(int xd[2], char **pack_lockfile)
}
if (*hdr_arg)
*av++ = hdr_arg;
+ if (fetch_fsck_objects)
+ *av++ = "--strict";
*av++ = NULL;
cmd.in = demux.out;
@@ -776,6 +779,11 @@ static int fetch_pack_config(const char *var, const char *value, void *cb)
return 0;
}
+ if (!strcmp(var, "fetch.fsckobjects")) {
+ fetch_fsck_objects = git_config_bool(var, value);
+ return 0;
+ }
+
return git_default_config(var, value, cb);
}
--
1.7.7.rc0.175.gb3212
^ permalink raw reply related
* Re: git push output goes into stderr
From: Junio C Hamano @ 2011-09-05 0:57 UTC (permalink / raw)
To: Lynn Lin; +Cc: git
In-Reply-To: <CAPgpnMQuck_aPU0ciaGgj-C8rno7jbzZ7wZ4unU8CqA0eaiYQw@mail.gmail.com>
Lynn Lin <lynn.xin.lin@gmail.com> writes:
> When I create a local branch and then push it to remote. I find that
> the output without error goes into stderr, is this expected?
Progress output are sent to the stderr stream.
In general, any program or script is buggy if it assumes that some output
that are emitted to the standard error output from programs it invokes
indicates an error (IIRC, that includes tcl/tk).
^ permalink raw reply
* [ANNOUNCE] Git User's Survey 2011
From: Jakub Narebski @ 2011-09-05 0:43 UTC (permalink / raw)
To: git
Hello all,
We would like to ask you a few questions about your use of the Git
version control system. This survey is mainly to understand who is
using Git, how and why.
The results will be published to the Git wiki on the GitSurvey2011
page (https://git.wiki.kernel.org/index.php/GitSurvey2011) and
discussed on the git mailing list.
The survey would be open from 5 September till 3 October 2011.
Please devote a few minutes of your time to fill this simple
questionnaire, it will help a lot the git community to understand your
needs, what you like of Git, and of course what you don't like of it.
The survey can be found here:
http://tinyurl.com/GitSurvey2011
https://www.survs.com/survey/VCAGZA8CT5
There is also alternate version which does not require cookies,
but it doesn't allow one to go back to response and edit it.
https://www.survs.com/survey/MRRGT8OEFV
P.S. At request I can open a separate channel in survey, with a separate
survey URL, so that responses from particular site or organization could
be separated out.
Please send me a email with name of channel, and I will return with
a separate survey URL to use.
--
Git Development Community
^ permalink raw reply
* Re: [PATCH] Support sizes >=2G in various config options accepting 'g' sizes.
From: Nix @ 2011-09-04 23:49 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: git
In-Reply-To: <CA+Jd1rGjkiabc9VePMmY6+8vhiGr7MgdwSNFToMsC0oBFNL6+g@mail.gmail.com>
On 4 Sep 2011, Clemens Buchacher uttered the following:
> On Sep 4, 2011 11:25 PM, "Nix" <nix@esperi.org.uk> wrote:
>>
>> I haven't tried to fix things on 32-bit platforms, because there
>> is no real point setting any values to >2G on such platforms
>> anyway, and minimal likelihood that anyone would try.
>
> I absolutely would not count on that.
I was just operating under the assumption that since nobody had spotted
this in years... OK, OK, perhaps that's a bad idea.
>> The only
>> real fix possible would be a diagnostic warning of an attempt to
>> set a ridiculously high value, unless we want to use 'long long'
>> everywhere, which I doubt.
>
> I think an error message would be appropriate. Best if we die immediately
> when that option is read.
Yeah. None of the affected options impact the pack format (as, say,
pack.depth does) so there is no danger of 32-bit users being barred from
reading packs created by 64-bit users with high values for these
settings.
(We have no way of guaranteeing that we can even report this, though:
we can only even read in a >32-bit number if NO_STRTOULL is not
defined. Still, I agree that if we *can* report this, we should.)
> We wouldn't want e.g. clone to die when it just
> finished downloading. And some documentation for those limits would be
> great, while you're at it. :-)
I'll send a new patch tomorrow.
... hm, pack.packsizelimit is also affected. I'll plug that too.
--
NULL && (void)
^ permalink raw reply
* [PATCH] Support sizes >=2G in various config options accepting 'g' sizes.
From: Nix @ 2011-09-04 21:03 UTC (permalink / raw)
To: git
The config options core.packedGitWindowSize, core.packedGitLimit,
core.deltaBaseCacheLimit and core.bigFileThreshold all claim
to support suffixes up to and including 'g'. This implies that
they should accept sizes >=2G on 64-bit systems: certainly,
specifying a size of 3g should not silently be translated to zero
or transformed into a large negative value due to integer
overflow. However, due to use of git_config_int() rather than
git_config_ulong(), that is exactly what happens:
% git config core.bigFileThreshold 2g
% git gc --aggressive # with extra debugging code to print out
# core.bigfilethreshold after parsing
bigfilethreshold: -2147483648
[...]
This is probably irrelevant for core.deltaBaseCacheLimit, but
is problematic for the other values. (It is particularly
problematic for core.packedGitLimit, which can't even be set to
its default value in the config file due to this bug.)
I haven't tried to fix things on 32-bit platforms, because there
is no real point setting any values to >2G on such platforms
anyway, and minimal likelihood that anyone would try. The only
real fix possible would be a diagnostic warning of an attempt to
set a ridiculously high value, unless we want to use 'long long'
everywhere, which I doubt.
Signed-off-by: Nick Alcock <nix@esperi.org.uk>
---
config.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/config.c b/config.c
index 4183f80..919f581 100644
--- a/config.c
+++ b/config.c
@@ -550,7 +550,7 @@ static int git_default_core_config(const char *var, const char *value)
if (!strcmp(var, "core.packedgitwindowsize")) {
int pgsz_x2 = getpagesize() * 2;
- packed_git_window_size = git_config_int(var, value);
+ packed_git_window_size = git_config_ulong(var, value);
/* This value must be multiple of (pagesize * 2) */
packed_git_window_size /= pgsz_x2;
@@ -561,18 +561,18 @@ static int git_default_core_config(const char *var, const char *value)
}
if (!strcmp(var, "core.bigfilethreshold")) {
- long n = git_config_int(var, value);
+ long n = git_config_ulong(var, value);
big_file_threshold = 0 < n ? n : 0;
return 0;
}
if (!strcmp(var, "core.packedgitlimit")) {
- packed_git_limit = git_config_int(var, value);
+ packed_git_limit = git_config_ulong(var, value);
return 0;
}
if (!strcmp(var, "core.deltabasecachelimit")) {
- delta_base_cache_limit = git_config_int(var, value);
+ delta_base_cache_limit = git_config_ulong(var, value);
return 0;
}
--
1.7.6.1.138.g03ab.dirty
^ permalink raw reply related
* Re: [PATCH] Documentation: "on for all" configuration of notes.rewriteRef
From: Tor Arntsen @ 2011-09-04 20:43 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, urbanjost, knittl, Junio C Hamano
In-Reply-To: <f415402994735a60664e1f9f85be490a68b25ed3.1315167848.git.trast@student.ethz.ch>
On 04/09/2011 22:28, Thomas Rast wrote:
>
> Users had problems finding a working setting for notes.rewriteRef.
> Document how to enable rewriting for all notes.
>
> Signed-off-by: Thomas Rast <trast@student.ethz.ch>
> ---
> [Sorry for the spam; the first one lacks my reply blurb and the
> in-reply-to. :-( ]
>
> Tor Arntsen wrote:
>> Thanks. Got it working. So it's not by default, as was suggested by
>> knittl, it has to be enabled. BTW, it's not at all obvious from the
>> manpage what it should be set to, there's no actual example. Found it
>> by trial&error plus finding a diff for a test.
>
> Let's document it then. This still won't help you find out about the
> option/feature in the first place, though. Maybe we should flip the
> default to enabled?
>
> Documentation/config.txt | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index 0ecef9d..302b2d0 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -1464,7 +1464,8 @@ notes.rewriteRef::
> You may also specify this configuration several times.
> +
> Does not have a default value; you must configure this variable to
> -enable note rewriting.
> +enable note rewriting. Set it to `refs/notes/*` to enable rewriting
> +for all notes.
> +
> This setting can be overridden with the `GIT_NOTES_REWRITE_REF`
> environment variable, which must be a colon separated list of refs or
Looks good to me, it would have been sufficient for me to find it
right away. But, as you say, it requires you to know or be told about
the feature in the first place..
As far as I'm concerned it would be perfect if it was set to refs/notes/*
by default, but people are using notes for all kinds of things. Maybe there
are issues with using that default that I don't know about.
-Tor
^ permalink raw reply
* [PATCH] Documentation: "on for all" configuration of notes.rewriteRef
From: Thomas Rast @ 2011-09-04 20:28 UTC (permalink / raw)
To: git; +Cc: John S. Urban", Tor Arntsen, knittl, Junio C Hamano
In-Reply-To: <CABNEGjy8M-pFTOs504Q1+G_DtocJwvzDyOAsJp9cn4BOSkv1TQ@mail.gmail.com>
Users had problems finding a working setting for notes.rewriteRef.
Document how to enable rewriting for all notes.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
[Sorry for the spam; the first one lacks my reply blurb and the
in-reply-to. :-( ]
Tor Arntsen wrote:
> Thanks. Got it working. So it's not by default, as was suggested by
> knittl, it has to be enabled. BTW, it's not at all obvious from the
> manpage what it should be set to, there's no actual example. Found it
> by trial&error plus finding a diff for a test.
Let's document it then. This still won't help you find out about the
option/feature in the first place, though. Maybe we should flip the
default to enabled?
Documentation/config.txt | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 0ecef9d..302b2d0 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1464,7 +1464,8 @@ notes.rewriteRef::
You may also specify this configuration several times.
+
Does not have a default value; you must configure this variable to
-enable note rewriting.
+enable note rewriting. Set it to `refs/notes/*` to enable rewriting
+for all notes.
+
This setting can be overridden with the `GIT_NOTES_REWRITE_REF`
environment variable, which must be a colon separated list of refs or
--
1.7.7.rc0.420.g468b7
^ permalink raw reply related
* Re: Lost association between TAGS and COMMITs when rebased a git(1) repository
From: John S. Urban @ 2011-09-04 20:18 UTC (permalink / raw)
To: Tor Arntsen, Thomas Rast; +Cc: knittl, git
In-Reply-To: <CABNEGjy8M-pFTOs504Q1+G_DtocJwvzDyOAsJp9cn4BOSkv1TQ@mail.gmail.com>
Thanks for catching how this is not the default, and that it needs set. But
exactly what is the value that works?
----- Original Message -----
From: "Tor Arntsen" <tor@spacetec.no>
To: "Thomas Rast" <trast@student.ethz.ch>
Cc: "knittl" <knittl89@googlemail.com>; "John S. Urban"
<urbanjost@comcast.net>; <git@vger.kernel.org>
Sent: Sunday, September 04, 2011 3:11 PM
Subject: Re: Lost association between TAGS and COMMITs when rebased a git(1)
repository
On Sun, Sep 4, 2011 at 8:43 PM, Thomas Rast <trast@student.ethz.ch> wrote:
> Tor Arntsen wrote:
>> On Sun, Sep 4, 2011 at 4:30 PM, knittl <knittl89@googlemail.com> wrote:
>> >
>> > On Sun, Sep 4, 2011 at 3:32 AM, John S. Urban <urbanjost@comcast.net>
>> > wrote:
>> > > With my first use of git(1) I created a small project with about 200
>> > > "commits". When this was complete, I needed to label each commit with
>> > > information pointing it to a section of a document. I used tags for
>> > > this.
>> >
>> > Use git notes[1] to attach additional info to existing commits. Git
>> > notes will by default be copied when using git rebase or git commit
>> > --amend (cf. notes.rewrite.<command> config)
>>
>> Is that true? I've always lost the notes when rebasing. I just tried
>> that again now (1.7.5.4), and after a rebase the notes attached to any
>> commit that was rebased just disappeared. I've always had to hunt down
>> and re-create the notes. It would indeed be much more convenient if
>> the notes would tag along.
>
> Yes, that support has been present since 1.7.1, but it's not enabled
> by default: you need to configure notes.rewriteRef.
Thanks. Got it working. So it's not by default, as was suggested by
knittl, it has to be enabled. BTW, it's not at all obvious from the
manpage what it should be set to, there's no actual example. Found it
by trial&error plus finding a diff for a test.
-Tor
^ permalink raw reply
* [PATCH 2/2] git svn dcommit: add a test serie for 'git svn dcommit --interactive'
From: Frédéric Heitzmann @ 2011-09-04 19:21 UTC (permalink / raw)
To: git; +Cc: gitster, normalperson, jaysoffian, Frédéric Heitzmann
In-Reply-To: <1315164113-26539-1-git-send-email-frederic.heitzmann@gmail.com>
test several combinations of potential answers to 'git svn dcommit
--interactive'. For each of them, test whether patches were commited to SVN or
not
Signed-off-by: Frédéric Heitzmann <frederic.heitzmann@gmail.com>
---
t/t9160-git-svn-dcommit-interactive.sh | 64 ++++++++++++++++++++++++++++++++
1 files changed, 64 insertions(+), 0 deletions(-)
create mode 100644 t/t9160-git-svn-dcommit-interactive.sh
diff --git a/t/t9160-git-svn-dcommit-interactive.sh b/t/t9160-git-svn-dcommit-interactive.sh
new file mode 100644
index 0000000..e38d9fa
--- /dev/null
+++ b/t/t9160-git-svn-dcommit-interactive.sh
@@ -0,0 +1,64 @@
+#!/bin/sh
+#
+# Copyright (c) 2011 Frédéric Heitzmann
+
+test_description='git svn dcommit --interactive series'
+. ./lib-git-svn.sh
+
+test_expect_success 'initialize repo' '
+ svn_cmd mkdir -m"mkdir test-interactive" "$svnrepo/test-interactive" &&
+ git svn clone "$svnrepo/test-interactive" test-interactive &&
+ cd test-interactive &&
+ touch foo && git add foo && git commit -m"foo: first commit" &&
+ git svn dcommit
+ '
+
+test_expect_success 'answers: y [\n] yes' '
+ (
+ echo "change #1" >> foo && git commit -a -m"change #1" &&
+ echo "change #2" >> foo && git commit -a -m"change #2" &&
+ echo "change #3" >> foo && git commit -a -m"change #3" &&
+ ( echo "y
+
+y" | GIT_SVN_NOTTY=1 git svn dcommit --interactive ) &&
+ test $(git rev-parse HEAD) = $(git rev-parse remotes/git-svn)
+ )
+ '
+
+test_expect_success 'answers: yes yes no' '
+ (
+ echo "change #1" >> foo && git commit -a -m"change #1" &&
+ echo "change #2" >> foo && git commit -a -m"change #2" &&
+ echo "change #3" >> foo && git commit -a -m"change #3" &&
+ ( echo "yes
+yes
+no" | GIT_SVN_NOTTY=1 git svn dcommit --interactive ) &&
+ test $(git rev-parse HEAD^^^) = $(git rev-parse remotes/git-svn) &&
+ git reset --hard remotes/git-svn
+ )
+ '
+
+test_expect_success 'answers: yes quit' '
+ (
+ echo "change #1" >> foo && git commit -a -m"change #1" &&
+ echo "change #2" >> foo && git commit -a -m"change #2" &&
+ echo "change #3" >> foo && git commit -a -m"change #3" &&
+ ( echo "yes
+quit" | GIT_SVN_NOTTY=1 git svn dcommit --interactive ) &&
+ test $(git rev-parse HEAD^^^) = $(git rev-parse remotes/git-svn) &&
+ git reset --hard remotes/git-svn
+ )
+ '
+
+test_expect_success 'answers: all' '
+ (
+ echo "change #1" >> foo && git commit -a -m"change #1" &&
+ echo "change #2" >> foo && git commit -a -m"change #2" &&
+ echo "change #3" >> foo && git commit -a -m"change #3" &&
+ ( echo "all" | GIT_SVN_NOTTY=1 git svn dcommit --interactive ) &&
+ test $(git rev-parse HEAD) = $(git rev-parse remotes/git-svn) &&
+ git reset --hard remotes/git-svn
+ )
+ '
+
+test_done
--
1.7.6.447.gb9176
^ permalink raw reply related
* [PATCH 1/2] git svn dcommit: new option --interactive.
From: Frédéric Heitzmann @ 2011-09-04 19:21 UTC (permalink / raw)
To: git; +Cc: gitster, normalperson, jaysoffian, Frédéric Heitzmann
In-Reply-To: <1315164113-26539-1-git-send-email-frederic.heitzmann@gmail.com>
Allow the user to check the patch set before it is commited to SNV. It is then
possible to accept/discard one patch, accept all, or quit.
This interactive mode is similar with 'git send email' behaviour. However,
'git svn dcommit' returns as soon as one patch is discarded.
Part of the code was taken from git-send-email.perl
Thanks-to: Eric Wong <normalperson@yhbt.net> for the initial idea.
Signed-off-by: Frédéric Heitzmann <frederic.heitzmann@gmail.com>
---
I would have preferred not duplicating the code snippets taken from
git-send-email ('ask' function, Term related code, ...) but I preferred not
to spoil Git.pm with it.
Any comment on a better way to factor perl code would be appreciated.
Documentation/git-svn.txt | 8 +++++
git-svn.perl | 71 ++++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 78 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index ed5eca1..08188a5 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -214,6 +214,14 @@ discouraged.
version 1.5 can make use of it. 'git svn' currently does not use it
and does not set it automatically.
+--interactive;;
+ Ask the user to confirm that a patch set should actually be sent to SVN.
+ For each patch, one may answer "yes" (accept this patch), "no" (discard this
+ patch), "all" (accept all patches), or "quit".
+ +
+ 'git svn dcommit' returns immediately if answer if "no" or "quit", without
+ commiting anything to SVN.
+
'branch'::
Create a branch in the SVN repository.
diff --git a/git-svn.perl b/git-svn.perl
index 89f83fd..fd5eaa2 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -87,7 +87,7 @@ my ($_stdin, $_help, $_edit,
$_version, $_fetch_all, $_no_rebase, $_fetch_parent,
$_merge, $_strategy, $_dry_run, $_local,
$_prefix, $_no_checkout, $_url, $_verbose,
- $_git_format, $_commit_url, $_tag, $_merge_info);
+ $_git_format, $_commit_url, $_tag, $_merge_info, $_interactive);
$Git::SVN::_follow_parent = 1;
$_q ||= 0;
my %remote_opts = ( 'username=s' => \$Git::SVN::Prompt::_username,
@@ -158,6 +158,7 @@ my %cmd = (
'revision|r=i' => \$_revision,
'no-rebase' => \$_no_rebase,
'mergeinfo=s' => \$_merge_info,
+ 'interactive|i' => \$_interactive,
%cmt_opts, %fc_opts } ],
branch => [ \&cmd_branch,
'Create a branch in the SVN repository',
@@ -251,6 +252,27 @@ my %cmd = (
{} ],
);
+use Term::ReadLine;
+package FakeTerm;
+sub new {
+ my ($class, $reason) = @_;
+ return bless \$reason, shift;
+}
+sub readline {
+ my $self = shift;
+ die "Cannot use readline on FakeTerm: $$self";
+}
+package main;
+
+my $term = eval {
+ $ENV{"GIT_SVN_NOTTY"}
+ ? new Term::ReadLine 'git-svn', \*STDIN, \*STDOUT
+ : new Term::ReadLine 'git-svn';
+};
+if ($@) {
+ $term = new FakeTerm "$@: going non-interactive";
+}
+
my $cmd;
for (my $i = 0; $i < @ARGV; $i++) {
if (defined $cmd{$ARGV[$i]}) {
@@ -361,6 +383,31 @@ sub version {
exit 0;
}
+sub ask {
+ my ($prompt, %arg) = @_;
+ my $valid_re = $arg{valid_re};
+ my $default = $arg{default};
+ my $resp;
+ my $i = 0;
+ return defined $default ? $default : undef
+ unless defined $term->IN and defined fileno($term->IN) and
+ defined $term->OUT and defined fileno($term->OUT);
+ while ($i++ < 10) {
+ $resp = $term->readline($prompt);
+ if (!defined $resp) { # EOF
+ print "\n";
+ return defined $default ? $default : undef;
+ }
+ if ($resp eq '' and defined $default) {
+ return $default;
+ }
+ if (!defined $valid_re or $resp =~ /$valid_re/) {
+ return $resp;
+ }
+ }
+ return undef;
+}
+
sub do_git_init_db {
unless (-d $ENV{GIT_DIR}) {
my @init_db = ('init');
@@ -546,6 +593,28 @@ sub cmd_dcommit {
"If these changes depend on each other, re-running ",
"without --no-rebase may be required."
}
+
+ if (defined $_interactive){
+ my $ask_default = "y";
+ foreach my $d (@$linear_refs){
+ print "debug : d = $d\n";
+ my ($fh, $ctx) = command_output_pipe(qw(show --summary), "$d");
+ while (<$fh>){
+ print $_;
+ }
+ command_close_pipe($fh, $ctx);
+ $_ = ask("Commit this patch to SVN? ([y]es (default)|[n]o|[q]uit|[a]ll): ",
+ valid_re => qr/^(?:yes|y|no|n|quit|q|all|a)/i,
+ default => $ask_default);
+ die "Commit this patch reply required" unless defined $_;
+ if (/^[nq]/i) {
+ exit(0);
+ } elsif (/^a/i) {
+ last;
+ }
+ }
+ }
+
my $expect_url = $url;
Git::SVN::remove_username($expect_url);
while (1) {
--
1.7.6.447.gb9176
^ permalink raw reply related
* [PATCH] git svn dcommit : new option --interactive
From: Frédéric Heitzmann @ 2011-09-04 19:21 UTC (permalink / raw)
To: git; +Cc: gitster, normalperson, jaysoffian
I use git svn daily, at work, and it is so useful that I started using it to
track some files which are not supposed to find their way up to the SVN
server.
For instance, it may be useful to 'git add & commit' some reference data
files, refactor some code, check against the data files, git commit, ..., then discard
commits with data files.
This way, it is very easy to monitor the functional changes in your code.
Unfortunately, it may happen that I forget to remove useless commits, and 'git
svn dcommit' everything ... forever.
These 2 patches add a --interactive option to 'git svn dcommit', which provides
an interactive mode, similar to git-send-email.
Documentation/git-svn.txt | 8 ++++
git-svn.perl | 71 +++++++++++++++++++++++++++++++-
t/t9160-git-svn-dcommit-interactive.sh | 64 ++++++++++++++++++++++++++++
3 files changed, 142 insertions(+), 1 deletions(-)
^ permalink raw reply
* Re: Funnies with "git fetch"
From: Junio C Hamano @ 2011-09-04 19:15 UTC (permalink / raw)
To: git
In-Reply-To: <7vpqjkw3nb.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> I just did this in an empty directory.
>
> $ git init src
> $ cd src
> $ echo hello >greetings ; git add . ; git commit -m greetings
> $ S=$(git rev-parse :greetings | sed -e 's|^..|&/|')
> $ X=$(echo bye | git hash-object -w --stdin | sed -e 's|^..|&/|')
> $ mv -f .git/objects/$X .git/objects/$S
>
> The tip commit _thinks_ it has "greetings" that contains "hello", but
> somebody replaced it with a corrupt "bye" that does not match self
> integrity.
>
> $ git fsck
> error: sha1 mismatch ce013625030ba8dba906f756967f9e9ca394464a
>
> error: ce013625030ba8dba906f756967f9e9ca394464a: object corrupt or missing
> missing blob ce013625030ba8dba906f756967f9e9ca394464a
>
> The "hello" blob is ce0136, and the tree contained in HEAD expects "hello"
> in that loose object file, but notices the contents do not match the
> filename.
>
> So far, so good. Let's see what others see when they interact with this
> repository.
>
> cd ../
> git init dst
> cd dst
> git config receive.fsckobjects true
> git remote add origin ../src
> git config branch.master.remote origin
> git config branch.master.merge refs/heads/master
> git fetch
> remote: Counting objects: 3, done.
> remote: Total 3 (delta 0), reused 0 (delta 0)
> Unpacking objects: 100% (3/3), done.
> From ../src
> * [new branch] master -> origin/master
>
> Oops? If we run "fsck" at this point, we would notice the breakage:
> ...
> But the straight "fetch" did not notice anything fishy going on. Shouldn't
> we have? Even though we may be reasonably safe, unpack-objects should be
> able to do better, especially under receive.fsckobjects option.
We do not have fetch.fsckobjects, and here is a quick patch to add it. I
would also add transfer.fsckobjects to cover both with a single variable
in a follow-up patch, but with this, it fails as expected:
$ git config fetch.fsckobjects true
$ git fetch
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
error: unable to find ce013625030ba8dba906f756967f9e9ca394464a
fatal: object of unexpected type
fatal: unpack-objects failed
during the transfer phase. The "rev-list --verify-objects" addition is a
fix to a related but independent issue, so both are probably good to have,
but this makes it unnecessary to run fsck_object() during the update-ref
phase.
builtin/fetch-pack.c | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/builtin/fetch-pack.c b/builtin/fetch-pack.c
index 412bd32..bfed536 100644
--- a/builtin/fetch-pack.c
+++ b/builtin/fetch-pack.c
@@ -16,6 +16,7 @@ static int fetch_unpack_limit = -1;
static int unpack_limit = 100;
static int prefer_ofs_delta = 1;
static int no_done = 0;
+static int fetch_fsck_objects;
static struct fetch_pack_args args = {
/* .uploadpack = */ "git-upload-pack",
};
@@ -734,6 +735,8 @@ static int get_pack(int xd[2], char **pack_lockfile)
}
if (*hdr_arg)
*av++ = hdr_arg;
+ if (fetch_fsck_objects)
+ *av++ = "--strict";
*av++ = NULL;
cmd.in = demux.out;
@@ -853,6 +856,11 @@ static int fetch_pack_config(const char *var, const char *value, void *cb)
return 0;
}
+ if (!strcmp(var, "fetch.fsckobjects")) {
+ fetch_fsck_objects = git_config_bool(var, value);
+ return 0;
+ }
+
return git_default_config(var, value, cb);
}
^ permalink raw reply related
* Re: Lost association between TAGS and COMMITs when rebased a git(1) repository
From: Tor Arntsen @ 2011-09-04 19:11 UTC (permalink / raw)
To: Thomas Rast; +Cc: knittl, John S. Urban, git
In-Reply-To: <201109042043.01159.trast@student.ethz.ch>
On Sun, Sep 4, 2011 at 8:43 PM, Thomas Rast <trast@student.ethz.ch> wrote:
> Tor Arntsen wrote:
>> On Sun, Sep 4, 2011 at 4:30 PM, knittl <knittl89@googlemail.com> wrote:
>> >
>> > On Sun, Sep 4, 2011 at 3:32 AM, John S. Urban <urbanjost@comcast.net> wrote:
>> > > With my first use of git(1) I created a small project with about 200
>> > > "commits". When this was complete, I needed to label each commit with
>> > > information pointing it to a section of a document. I used tags for this.
>> >
>> > Use git notes[1] to attach additional info to existing commits. Git
>> > notes will by default be copied when using git rebase or git commit
>> > --amend (cf. notes.rewrite.<command> config)
>>
>> Is that true? I've always lost the notes when rebasing. I just tried
>> that again now (1.7.5.4), and after a rebase the notes attached to any
>> commit that was rebased just disappeared. I've always had to hunt down
>> and re-create the notes. It would indeed be much more convenient if
>> the notes would tag along.
>
> Yes, that support has been present since 1.7.1, but it's not enabled
> by default: you need to configure notes.rewriteRef.
Thanks. Got it working. So it's not by default, as was suggested by
knittl, it has to be enabled. BTW, it's not at all obvious from the
manpage what it should be set to, there's no actual example. Found it
by trial&error plus finding a diff for a test.
-Tor
^ permalink raw reply
* Re: t5800-*.sh: Intermittent test failures
From: Junio C Hamano @ 2011-09-04 19:06 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Ramsay Jones, GIT Mailing-list, Jeff King, Jonathan Nieder
In-Reply-To: <CAGdFq_jv_T-x7VGqm_j-fDfeW6TsBG95=1TWn91Yk9B3TGZdsQ@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> Heya,
>
> On Tue, Aug 9, 2011 at 20:30, Ramsay Jones <ramsay@ramsay1.demon.co.uk> wrote:
>> The git-fast-import is hung in the read() syscall waiting for data which will
>> never arrive. This is because the git(fast-export) process, started by the above
>> git(push), executes (producing it's data on stdout) and completes successfully
>> and exits *before* the above git-fast-import process starts.
>>
>> I haven't looked to see how the git(fast-export)/git-fast-import processes are
>> plumbed together, but there seems to be a synchronization problem somewhere ...
>
> This seems odd, before the fast-export process is even started it's
> stdout are wired to the stdin of the helper (and thus the fast-import
> process). What indication do you have that fast-import hasn't started
> and that fast-export has finished?
>
> Also, you say git remote-test everywhere, but it should be git
> remote-testgit, typo?
FWIW, I have been seeing this every once in a while.
^ permalink raw reply
* Re: [BUG] git push --quiet fails with older versions
From: Junio C Hamano @ 2011-09-04 19:02 UTC (permalink / raw)
To: Tobias Ulmer; +Cc: git, Clemens Buchacher
In-Reply-To: <20110903105723.GA16304@tin.tmux.org>
Tobias Ulmer <tobiasu@tmux.org> writes:
> my distro updated git to 1.7.6.1. Now git push --quiet, used in various
> scripts, blows up against 1.7.6.
This kind of regression is not acceptable not just for point maintenance
release, but for feature releases. 1.7.7 client must work with 1.7.6
server just fine without such a breakage. I should have been more careful
when reviewing.
Thanks for a report, Tobias, and thanks for a quick fix, Clemens.
^ 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