Git development
 help / color / mirror / Atom feed
* [PATCH v6 8/8] push: cleanup push rules comment
From: Chris Rorvick @ 2012-11-30  1:41 UTC (permalink / raw)
  To: git
  Cc: Chris Rorvick, Angelo Borsotti, Drew Northup, Michael Haggerty,
	Philip Oakley, Johannes Sixt, Kacper Kornet, Jeff King,
	Felipe Contreras, Junio C Hamano
In-Reply-To: <1354239700-3325-1-git-send-email-chris@rorvick.com>

Rewrite to remove inter-dependencies amongst the rules.

Signed-off-by: Chris Rorvick <chris@rorvick.com>
---
 remote.c | 32 +++++++++++++++++---------------
 1 file changed, 17 insertions(+), 15 deletions(-)

diff --git a/remote.c b/remote.c
index ee0c1e5..6309a87 100644
--- a/remote.c
+++ b/remote.c
@@ -1319,27 +1319,29 @@ void set_ref_status_for_push(struct ref *remote_refs, int send_mirror,
 			continue;
 		}
 
-		/* This part determines what can overwrite what.
-		 * The rules are:
+		/*
+		 * The below logic determines whether an individual
+		 * refspec A:B can be pushed.  The push will succeed
+		 * if any of the following are true:
 		 *
-		 * (0) you can always use --force or +A:B notation to
-		 *     selectively force individual ref pairs.
+		 * (1) the remote reference B does not exist
 		 *
-		 * (1) if the old thing does not exist, it is OK.
+		 * (2) the remote reference B is being removed (i.e.,
+		 *     pushing :B where no source is specified)
 		 *
-		 * (2) if the destination is under refs/tags/ you are
-		 *     not allowed to overwrite it; tags are expected
-		 *     to be static once created
+		 * (3) the update meets all fast-forwarding criteria:
 		 *
-		 * (3) if you do not have the old thing, you are not allowed
-		 *     to overwrite it; you would not know what you are losing
-		 *     otherwise.
+		 *     (a) the destination is not under refs/tags/
+		 *     (b) the old is a commit
+		 *     (c) the new is a descendant of the old
 		 *
-		 * (4) if old is a commit and new is a descendant of old
-		 *     (implying new is commit-ish), it is OK.
+		 *     NOTE: We must actually have the old object in
+		 *     order to overwrite it in the remote reference,
+		 *     and that the new object must be commit-ish.
+		 *     These are implied by (b) and (c) respectively.
 		 *
-		 * (5) regardless of all of the above, removing :B is
-		 *     always allowed.
+		 * (4) it is forced using the +A:B notation, or by
+		 *     passing the --force argument
 		 */
 
 		ref->not_forwardable = !is_forwardable(ref);
-- 
1.8.0.158.g0c4328c

^ permalink raw reply related

* [PATCH v6 6/8] push: require force for annotated tags
From: Chris Rorvick @ 2012-11-30  1:41 UTC (permalink / raw)
  To: git
  Cc: Chris Rorvick, Angelo Borsotti, Drew Northup, Michael Haggerty,
	Philip Oakley, Johannes Sixt, Kacper Kornet, Jeff King,
	Felipe Contreras, Junio C Hamano
In-Reply-To: <1354239700-3325-1-git-send-email-chris@rorvick.com>

Do not allow fast-forwarding of references that point to a tag object.
Updating from a tag is potentially destructive since it would likely
leave the tag dangling.  Disallowing updates to a tag also makes sense
semantically and is consistent with the behavior of lightweight tags.

Signed-off-by: Chris Rorvick <chris@rorvick.com>
---
 Documentation/git-push.txt | 10 +++++-----
 remote.c                   | 11 +++++++++--
 t/t5516-fetch-push.sh      | 21 +++++++++++++++++++++
 3 files changed, 35 insertions(+), 7 deletions(-)

diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 09bdec7..7a04ce5 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -52,11 +52,11 @@ updated.
 +
 The object referenced by <src> is used to update the <dst> reference
 on the remote side.  By default this is only allowed if <dst> is not
-under refs/tags/, and then only if it can fast-forward <dst>.  By having
-the optional leading `+`, you can tell git to update the <dst> ref even
-if it is not allowed by default (e.g., it is not a fast-forward.)  This
-does *not* attempt to merge <src> into <dst>.  See EXAMPLES below for
-details.
+a tag (annotated or lightweight), and then only if it can fast-forward
+<dst>.  By having the optional leading `+`, you can tell git to update
+the <dst> ref even if it is not allowed by default (e.g., it is not a
+fast-forward.)  This does *not* attempt to merge <src> into <dst>.  See
+EXAMPLES below for details.
 +
 `tag <tag>` means the same as `refs/tags/<tag>:refs/tags/<tag>`.
 +
diff --git a/remote.c b/remote.c
index 012b52f..f5bc4e7 100644
--- a/remote.c
+++ b/remote.c
@@ -1281,9 +1281,16 @@ int match_push_refs(struct ref *src, struct ref **dst,
 
 static inline int is_forwardable(struct ref* ref)
 {
+	struct object *o;
+
 	if (!prefixcmp(ref->name, "refs/tags/"))
 		return 0;
 
+	/* old object must be a commit */
+	o = parse_object(ref->old_sha1);
+	if (!o || o->type != OBJ_COMMIT)
+		return 0;
+
 	return 1;
 }
 
@@ -1323,8 +1330,8 @@ void set_ref_status_for_push(struct ref *remote_refs, int send_mirror,
 		 *     to overwrite it; you would not know what you are losing
 		 *     otherwise.
 		 *
-		 * (4) if both new and old are commit-ish, and new is a
-		 *     descendant of old, it is OK.
+		 * (4) if old is a commit and new is a descendant of old
+		 *     (implying new is commit-ish), it is OK.
 		 *
 		 * (5) regardless of all of the above, removing :B is
 		 *     always allowed.
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index 8f024a0..6009372 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -950,6 +950,27 @@ test_expect_success 'push requires --force to update lightweight tag' '
 	)
 '
 
+test_expect_success 'push requires --force to update annotated tag' '
+	mk_test heads/master &&
+	mk_child child1 &&
+	mk_child child2 &&
+	(
+		cd child1 &&
+		git tag -a -m "message 1" Tag &&
+		git push ../child2 Tag:refs/tmp/Tag &&
+		git push ../child2 Tag:refs/tmp/Tag &&
+		>file1 &&
+		git add file1 &&
+		git commit -m "file1" &&
+		git tag -f -a -m "message 2" Tag &&
+		test_must_fail git push ../child2 Tag:refs/tmp/Tag &&
+		git push --force ../child2 Tag:refs/tmp/Tag &&
+		git tag -f -a -m "message 3" Tag HEAD~ &&
+		test_must_fail git push ../child2 Tag:refs/tmp/Tag &&
+		git push --force ../child2 Tag:refs/tmp/Tag
+	)
+'
+
 test_expect_success 'push --porcelain' '
 	mk_empty &&
 	echo >.git/foo  "To testrepo" &&
-- 
1.8.0.158.g0c4328c

^ permalink raw reply related

* [PATCH v6 5/8] push: require force for refs under refs/tags/
From: Chris Rorvick @ 2012-11-30  1:41 UTC (permalink / raw)
  To: git
  Cc: Chris Rorvick, Angelo Borsotti, Drew Northup, Michael Haggerty,
	Philip Oakley, Johannes Sixt, Kacper Kornet, Jeff King,
	Felipe Contreras, Junio C Hamano
In-Reply-To: <1354239700-3325-1-git-send-email-chris@rorvick.com>

References are allowed to update from one commit-ish to another if the
former is an ancestor of the latter.  This behavior is oriented to
branches which are expected to move with commits.  Tag references are
expected to be static in a repository, though, thus an update to
something under refs/tags/ should be rejected unless the update is
forced.

Signed-off-by: Chris Rorvick <chris@rorvick.com>
---
 Documentation/git-push.txt | 11 ++++++-----
 builtin/push.c             |  2 +-
 builtin/send-pack.c        |  5 +++++
 cache.h                    |  1 +
 remote.c                   | 18 ++++++++++++++----
 send-pack.c                |  1 +
 t/t5516-fetch-push.sh      | 23 ++++++++++++++++++++++-
 transport-helper.c         |  6 ++++++
 transport.c                |  8 ++++++--
 9 files changed, 62 insertions(+), 13 deletions(-)

diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index fe46c42..09bdec7 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -51,11 +51,12 @@ be named. If `:`<dst> is omitted, the same ref as <src> will be
 updated.
 +
 The object referenced by <src> is used to update the <dst> reference
-on the remote side, but by default this is only allowed if the
-update can fast-forward <dst>.  By having the optional leading `+`,
-you can tell git to update the <dst> ref even when the update is not a
-fast-forward.  This does *not* attempt to merge <src> into <dst>.  See
-EXAMPLES below for details.
+on the remote side.  By default this is only allowed if <dst> is not
+under refs/tags/, and then only if it can fast-forward <dst>.  By having
+the optional leading `+`, you can tell git to update the <dst> ref even
+if it is not allowed by default (e.g., it is not a fast-forward.)  This
+does *not* attempt to merge <src> into <dst>.  See EXAMPLES below for
+details.
 +
 `tag <tag>` means the same as `refs/tags/<tag>:refs/tags/<tag>`.
 +
diff --git a/builtin/push.c b/builtin/push.c
index e08485d..83a3cc8 100644
--- a/builtin/push.c
+++ b/builtin/push.c
@@ -222,7 +222,7 @@ static const char message_advice_checkout_pull_push[] =
 
 static const char message_advice_ref_already_exists[] =
 	N_("Updates were rejected because the destination reference already exists\n"
-	   "in the remote and the update is not a fast-forward.");
+	   "in the remote.");
 
 static void advise_pull_before_push(void)
 {
diff --git a/builtin/send-pack.c b/builtin/send-pack.c
index 9f98607..f849e0a 100644
--- a/builtin/send-pack.c
+++ b/builtin/send-pack.c
@@ -44,6 +44,11 @@ static void print_helper_status(struct ref *ref)
 			msg = "non-fast forward";
 			break;
 
+		case REF_STATUS_REJECT_ALREADY_EXISTS:
+			res = "error";
+			msg = "already exists";
+			break;
+
 		case REF_STATUS_REJECT_NODELETE:
 		case REF_STATUS_REMOTE_REJECT:
 			res = "error";
diff --git a/cache.h b/cache.h
index b7ab4ac..a32a0ea 100644
--- a/cache.h
+++ b/cache.h
@@ -1011,6 +1011,7 @@ struct ref {
 		REF_STATUS_NONE = 0,
 		REF_STATUS_OK,
 		REF_STATUS_REJECT_NONFASTFORWARD,
+		REF_STATUS_REJECT_ALREADY_EXISTS,
 		REF_STATUS_REJECT_NODELETE,
 		REF_STATUS_UPTODATE,
 		REF_STATUS_REMOTE_REJECT,
diff --git a/remote.c b/remote.c
index 4a6f822..012b52f 100644
--- a/remote.c
+++ b/remote.c
@@ -1315,14 +1315,18 @@ void set_ref_status_for_push(struct ref *remote_refs, int send_mirror,
 		 *
 		 * (1) if the old thing does not exist, it is OK.
 		 *
-		 * (2) if you do not have the old thing, you are not allowed
+		 * (2) if the destination is under refs/tags/ you are
+		 *     not allowed to overwrite it; tags are expected
+		 *     to be static once created
+		 *
+		 * (3) if you do not have the old thing, you are not allowed
 		 *     to overwrite it; you would not know what you are losing
 		 *     otherwise.
 		 *
-		 * (3) if both new and old are commit-ish, and new is a
+		 * (4) if both new and old are commit-ish, and new is a
 		 *     descendant of old, it is OK.
 		 *
-		 * (4) regardless of all of the above, removing :B is
+		 * (5) regardless of all of the above, removing :B is
 		 *     always allowed.
 		 */
 
@@ -1337,7 +1341,13 @@ void set_ref_status_for_push(struct ref *remote_refs, int send_mirror,
 				!has_sha1_file(ref->old_sha1)
 				  || !ref_newer(ref->new_sha1, ref->old_sha1);
 
-			if (ref->nonfastforward) {
+			if (ref->not_forwardable) {
+				ref->requires_force = 1;
+				if (!force_ref_update) {
+					ref->status = REF_STATUS_REJECT_ALREADY_EXISTS;
+					continue;
+				}
+			} else if (ref->nonfastforward) {
 				ref->requires_force = 1;
 				if (!force_ref_update) {
 					ref->status = REF_STATUS_REJECT_NONFASTFORWARD;
diff --git a/send-pack.c b/send-pack.c
index f50dfd9..1c375f0 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -229,6 +229,7 @@ int send_pack(struct send_pack_args *args,
 		/* Check for statuses set by set_ref_status_for_push() */
 		switch (ref->status) {
 		case REF_STATUS_REJECT_NONFASTFORWARD:
+		case REF_STATUS_REJECT_ALREADY_EXISTS:
 		case REF_STATUS_UPTODATE:
 			continue;
 		default:
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index b5417cc..8f024a0 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -368,7 +368,7 @@ test_expect_success 'push with colon-less refspec (2)' '
 		git branch -D frotz
 	fi &&
 	git tag -f frotz &&
-	git push testrepo frotz &&
+	git push -f testrepo frotz &&
 	check_push_result $the_commit tags/frotz &&
 	check_push_result $the_first_commit heads/frotz
 
@@ -929,6 +929,27 @@ test_expect_success 'push into aliased refs (inconsistent)' '
 	)
 '
 
+test_expect_success 'push requires --force to update lightweight tag' '
+	mk_test heads/master &&
+	mk_child child1 &&
+	mk_child child2 &&
+	(
+		cd child1 &&
+		git tag Tag &&
+		git push ../child2 Tag &&
+		git push ../child2 Tag &&
+		>file1 &&
+		git add file1 &&
+		git commit -m "file1" &&
+		git tag -f Tag &&
+		test_must_fail git push ../child2 Tag &&
+		git push --force ../child2 Tag &&
+		git tag -f Tag &&
+		test_must_fail git push ../child2 Tag HEAD~ &&
+		git push --force ../child2 Tag
+	)
+'
+
 test_expect_success 'push --porcelain' '
 	mk_empty &&
 	echo >.git/foo  "To testrepo" &&
diff --git a/transport-helper.c b/transport-helper.c
index 4713b69..965b778 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -661,6 +661,11 @@ static void push_update_ref_status(struct strbuf *buf,
 			free(msg);
 			msg = NULL;
 		}
+		else if (!strcmp(msg, "already exists")) {
+			status = REF_STATUS_REJECT_ALREADY_EXISTS;
+			free(msg);
+			msg = NULL;
+		}
 	}
 
 	if (*ref)
@@ -720,6 +725,7 @@ static int push_refs_with_push(struct transport *transport,
 		/* Check for statuses set by set_ref_status_for_push() */
 		switch (ref->status) {
 		case REF_STATUS_REJECT_NONFASTFORWARD:
+		case REF_STATUS_REJECT_ALREADY_EXISTS:
 		case REF_STATUS_UPTODATE:
 			continue;
 		default:
diff --git a/transport.c b/transport.c
index f3160b1..2673d27 100644
--- a/transport.c
+++ b/transport.c
@@ -695,6 +695,10 @@ static int print_one_push_status(struct ref *ref, const char *dest, int count, i
 		print_ref_status('!', "[rejected]", ref, ref->peer_ref,
 						 "non-fast-forward", porcelain);
 		break;
+	case REF_STATUS_REJECT_ALREADY_EXISTS:
+		print_ref_status('!', "[rejected]", ref, ref->peer_ref,
+						 "already exists", porcelain);
+		break;
 	case REF_STATUS_REMOTE_REJECT:
 		print_ref_status('!', "[remote rejected]", ref,
 						 ref->deletion ? NULL : ref->peer_ref,
@@ -740,12 +744,12 @@ void transport_print_push_status(const char *dest, struct ref *refs,
 		    ref->status != REF_STATUS_OK)
 			n += print_one_push_status(ref, dest, n, porcelain);
 		if (ref->status == REF_STATUS_REJECT_NONFASTFORWARD) {
-			if (ref->not_forwardable)
-				*reject_reasons |= REJECT_ALREADY_EXISTS;
 			if (!strcmp(head, ref->name))
 				*reject_reasons |= REJECT_NON_FF_HEAD;
 			else
 				*reject_reasons |= REJECT_NON_FF_OTHER;
+		} else if (ref->status == REF_STATUS_REJECT_ALREADY_EXISTS) {
+			*reject_reasons |= REJECT_ALREADY_EXISTS;
 		}
 	}
 }
-- 
1.8.0.158.g0c4328c

^ permalink raw reply related

* [PATCH v6 7/8] push: clarify rejection of update to non-commit-ish
From: Chris Rorvick @ 2012-11-30  1:41 UTC (permalink / raw)
  To: git
  Cc: Chris Rorvick, Angelo Borsotti, Drew Northup, Michael Haggerty,
	Philip Oakley, Johannes Sixt, Kacper Kornet, Jeff King,
	Felipe Contreras, Junio C Hamano
In-Reply-To: <1354239700-3325-1-git-send-email-chris@rorvick.com>

Pushes must already (by default) update to a commit-ish due to the fast-
forward check in set_ref_status_for_push().  But rejecting for not being
a fast-forward suggests the situation can be resolved with a merge.
Flag these updates (i.e., to a blob or a tree) as not forwardable so the
user is presented with more appropriate advice.

While updating *from* a tag object is potentially destructive, updating
*to* a tag is not.  Additionally, a push to the refs/tags/ hierarchy is
already excluded from fast-forwarding, and refs/heads/ is protected from
anything but commit objects by a check in write_ref_sha1().  Thus
someone fast-forwarding to a tag is probably not doing so by accident.
Since updating to a tag is benign and unlikely to cause confusion, allow
it in case someone finds the behavior useful.

Signed-off-by: Chris Rorvick <chris@rorvick.com>
---
 remote.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/remote.c b/remote.c
index f5bc4e7..ee0c1e5 100644
--- a/remote.c
+++ b/remote.c
@@ -1291,6 +1291,11 @@ static inline int is_forwardable(struct ref* ref)
 	if (!o || o->type != OBJ_COMMIT)
 		return 0;
 
+	/* new object must be commit-ish */
+	o = deref_tag(parse_object(ref->new_sha1), NULL, 0);
+	if (!o || o->type != OBJ_COMMIT)
+		return 0;
+
 	return 1;
 }
 
-- 
1.8.0.158.g0c4328c

^ permalink raw reply related

* [PATCH v6 3/8] push: flag updates
From: Chris Rorvick @ 2012-11-30  1:41 UTC (permalink / raw)
  To: git
  Cc: Chris Rorvick, Angelo Borsotti, Drew Northup, Michael Haggerty,
	Philip Oakley, Johannes Sixt, Kacper Kornet, Jeff King,
	Felipe Contreras, Junio C Hamano
In-Reply-To: <1354239700-3325-1-git-send-email-chris@rorvick.com>

If the reference exists on the remote and it is not being removed, then
mark as an update.  This is in preparation for handling tags (lightweight
and annotated) exceptionally.

Signed-off-by: Chris Rorvick <chris@rorvick.com>
---
 cache.h  |  1 +
 remote.c | 18 +++++++++++-------
 2 files changed, 12 insertions(+), 7 deletions(-)

diff --git a/cache.h b/cache.h
index d72b64d..722321c 100644
--- a/cache.h
+++ b/cache.h
@@ -1003,6 +1003,7 @@ struct ref {
 		merge:1,
 		nonfastforward:1,
 		not_forwardable:1,
+		update:1,
 		deletion:1;
 	enum {
 		REF_STATUS_NONE = 0,
diff --git a/remote.c b/remote.c
index 5101683..07040b8 100644
--- a/remote.c
+++ b/remote.c
@@ -1326,15 +1326,19 @@ void set_ref_status_for_push(struct ref *remote_refs, int send_mirror,
 
 		ref->not_forwardable = !is_forwardable(ref);
 
-		ref->nonfastforward =
+		ref->update =
 			!ref->deletion &&
-			!is_null_sha1(ref->old_sha1) &&
-			(!has_sha1_file(ref->old_sha1)
-			  || !ref_newer(ref->new_sha1, ref->old_sha1));
+			!is_null_sha1(ref->old_sha1);
 
-		if (ref->nonfastforward && !ref->force && !force_update) {
-			ref->status = REF_STATUS_REJECT_NONFASTFORWARD;
-			continue;
+		if (ref->update) {
+			ref->nonfastforward =
+				!has_sha1_file(ref->old_sha1)
+				  || !ref_newer(ref->new_sha1, ref->old_sha1);
+
+			if (ref->nonfastforward && !ref->force && !force_update) {
+				ref->status = REF_STATUS_REJECT_NONFASTFORWARD;
+				continue;
+			}
 		}
 	}
 }
-- 
1.8.0.158.g0c4328c

^ permalink raw reply related

* [PATCH v6 4/8] push: flag updates that require force
From: Chris Rorvick @ 2012-11-30  1:41 UTC (permalink / raw)
  To: git
  Cc: Chris Rorvick, Angelo Borsotti, Drew Northup, Michael Haggerty,
	Philip Oakley, Johannes Sixt, Kacper Kornet, Jeff King,
	Felipe Contreras, Junio C Hamano
In-Reply-To: <1354239700-3325-1-git-send-email-chris@rorvick.com>

Add a flag for indicating an update to a reference requires force.
Currently the `nonfastforward` flag is used for this when generating the
status message.  A separate flag insulates dependent logic from the
details of set_ref_status_for_push().

Signed-off-by: Chris Rorvick <chris@rorvick.com>
---
 cache.h     |  4 +++-
 remote.c    | 11 ++++++++---
 transport.c |  2 +-
 3 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/cache.h b/cache.h
index 722321c..b7ab4ac 100644
--- a/cache.h
+++ b/cache.h
@@ -999,7 +999,9 @@ struct ref {
 	unsigned char old_sha1[20];
 	unsigned char new_sha1[20];
 	char *symref;
-	unsigned int force:1,
+	unsigned int
+		force:1,
+		requires_force:1,
 		merge:1,
 		nonfastforward:1,
 		not_forwardable:1,
diff --git a/remote.c b/remote.c
index 07040b8..4a6f822 100644
--- a/remote.c
+++ b/remote.c
@@ -1293,6 +1293,8 @@ void set_ref_status_for_push(struct ref *remote_refs, int send_mirror,
 	struct ref *ref;
 
 	for (ref = remote_refs; ref; ref = ref->next) {
+		int force_ref_update = ref->force || force_update;
+
 		if (ref->peer_ref)
 			hashcpy(ref->new_sha1, ref->peer_ref->new_sha1);
 		else if (!send_mirror)
@@ -1335,9 +1337,12 @@ void set_ref_status_for_push(struct ref *remote_refs, int send_mirror,
 				!has_sha1_file(ref->old_sha1)
 				  || !ref_newer(ref->new_sha1, ref->old_sha1);
 
-			if (ref->nonfastforward && !ref->force && !force_update) {
-				ref->status = REF_STATUS_REJECT_NONFASTFORWARD;
-				continue;
+			if (ref->nonfastforward) {
+				ref->requires_force = 1;
+				if (!force_ref_update) {
+					ref->status = REF_STATUS_REJECT_NONFASTFORWARD;
+					continue;
+				}
 			}
 		}
 	}
diff --git a/transport.c b/transport.c
index bc31e8e..f3160b1 100644
--- a/transport.c
+++ b/transport.c
@@ -659,7 +659,7 @@ static void print_ok_ref_status(struct ref *ref, int porcelain)
 		const char *msg;
 
 		strcpy(quickref, status_abbrev(ref->old_sha1));
-		if (ref->nonfastforward) {
+		if (ref->requires_force) {
 			strcat(quickref, "...");
 			type = '+';
 			msg = "forced update";
-- 
1.8.0.158.g0c4328c

^ permalink raw reply related

* [PATCH v6 1/8] push: return reject reasons as a bitset
From: Chris Rorvick @ 2012-11-30  1:41 UTC (permalink / raw)
  To: git
  Cc: Chris Rorvick, Angelo Borsotti, Drew Northup, Michael Haggerty,
	Philip Oakley, Johannes Sixt, Kacper Kornet, Jeff King,
	Felipe Contreras, Junio C Hamano
In-Reply-To: <1354239700-3325-1-git-send-email-chris@rorvick.com>

Pass all rejection reasons back from transport_push().  The logic is
simpler and more flexible with regard to providing useful feedback.

Signed-off-by: Chris Rorvick <chris@rorvick.com>
---
 builtin/push.c      | 13 ++++---------
 builtin/send-pack.c |  4 ++--
 transport.c         | 17 ++++++++---------
 transport.h         |  9 +++++----
 4 files changed, 19 insertions(+), 24 deletions(-)

diff --git a/builtin/push.c b/builtin/push.c
index db9ba30..9d17fc7 100644
--- a/builtin/push.c
+++ b/builtin/push.c
@@ -244,7 +244,7 @@ static void advise_checkout_pull_push(void)
 static int push_with_options(struct transport *transport, int flags)
 {
 	int err;
-	int nonfastforward;
+	unsigned int reject_reasons;
 
 	transport_set_verbosity(transport, verbosity, progress);
 
@@ -257,7 +257,7 @@ static int push_with_options(struct transport *transport, int flags)
 	if (verbosity > 0)
 		fprintf(stderr, _("Pushing to %s\n"), transport->url);
 	err = transport_push(transport, refspec_nr, refspec, flags,
-			     &nonfastforward);
+			     &reject_reasons);
 	if (err != 0)
 		error(_("failed to push some refs to '%s'"), transport->url);
 
@@ -265,18 +265,13 @@ static int push_with_options(struct transport *transport, int flags)
 	if (!err)
 		return 0;
 
-	switch (nonfastforward) {
-	default:
-		break;
-	case NON_FF_HEAD:
+	if (reject_reasons & REJECT_NON_FF_HEAD) {
 		advise_pull_before_push();
-		break;
-	case NON_FF_OTHER:
+	} else if (reject_reasons & REJECT_NON_FF_OTHER) {
 		if (default_matching_used)
 			advise_use_upstream();
 		else
 			advise_checkout_pull_push();
-		break;
 	}
 
 	return 1;
diff --git a/builtin/send-pack.c b/builtin/send-pack.c
index d342013..9f98607 100644
--- a/builtin/send-pack.c
+++ b/builtin/send-pack.c
@@ -85,7 +85,7 @@ int cmd_send_pack(int argc, const char **argv, const char *prefix)
 	int send_all = 0;
 	const char *receivepack = "git-receive-pack";
 	int flags;
-	int nonfastforward = 0;
+	unsigned int reject_reasons;
 	int progress = -1;
 
 	argv++;
@@ -223,7 +223,7 @@ int cmd_send_pack(int argc, const char **argv, const char *prefix)
 	ret |= finish_connect(conn);
 
 	if (!helper_status)
-		transport_print_push_status(dest, remote_refs, args.verbose, 0, &nonfastforward);
+		transport_print_push_status(dest, remote_refs, args.verbose, 0, &reject_reasons);
 
 	if (!args.dry_run && remote) {
 		struct ref *ref;
diff --git a/transport.c b/transport.c
index 9932f40..d4568e7 100644
--- a/transport.c
+++ b/transport.c
@@ -714,7 +714,7 @@ static int print_one_push_status(struct ref *ref, const char *dest, int count, i
 }
 
 void transport_print_push_status(const char *dest, struct ref *refs,
-				  int verbose, int porcelain, int *nonfastforward)
+				  int verbose, int porcelain, unsigned int *reject_reasons)
 {
 	struct ref *ref;
 	int n = 0;
@@ -733,18 +733,17 @@ void transport_print_push_status(const char *dest, struct ref *refs,
 		if (ref->status == REF_STATUS_OK)
 			n += print_one_push_status(ref, dest, n, porcelain);
 
-	*nonfastforward = 0;
+	*reject_reasons = 0;
 	for (ref = refs; ref; ref = ref->next) {
 		if (ref->status != REF_STATUS_NONE &&
 		    ref->status != REF_STATUS_UPTODATE &&
 		    ref->status != REF_STATUS_OK)
 			n += print_one_push_status(ref, dest, n, porcelain);
-		if (ref->status == REF_STATUS_REJECT_NONFASTFORWARD &&
-		    *nonfastforward != NON_FF_HEAD) {
+		if (ref->status == REF_STATUS_REJECT_NONFASTFORWARD) {
 			if (!strcmp(head, ref->name))
-				*nonfastforward = NON_FF_HEAD;
+				*reject_reasons |= REJECT_NON_FF_HEAD;
 			else
-				*nonfastforward = NON_FF_OTHER;
+				*reject_reasons |= REJECT_NON_FF_OTHER;
 		}
 	}
 }
@@ -1031,9 +1030,9 @@ static void die_with_unpushed_submodules(struct string_list *needs_pushing)
 
 int transport_push(struct transport *transport,
 		   int refspec_nr, const char **refspec, int flags,
-		   int *nonfastforward)
+		   unsigned int *reject_reasons)
 {
-	*nonfastforward = 0;
+	*reject_reasons = 0;
 	transport_verify_remote_names(refspec_nr, refspec);
 
 	if (transport->push) {
@@ -1099,7 +1098,7 @@ int transport_push(struct transport *transport,
 		if (!quiet || err)
 			transport_print_push_status(transport->url, remote_refs,
 					verbose | porcelain, porcelain,
-					nonfastforward);
+					reject_reasons);
 
 		if (flags & TRANSPORT_PUSH_SET_UPSTREAM)
 			set_upstreams(transport, remote_refs, pretend);
diff --git a/transport.h b/transport.h
index 4a61c0c..404b113 100644
--- a/transport.h
+++ b/transport.h
@@ -140,11 +140,12 @@ int transport_set_option(struct transport *transport, const char *name,
 void transport_set_verbosity(struct transport *transport, int verbosity,
 	int force_progress);
 
-#define NON_FF_HEAD 1
-#define NON_FF_OTHER 2
+#define REJECT_NON_FF_HEAD     0x01
+#define REJECT_NON_FF_OTHER    0x02
+
 int transport_push(struct transport *connection,
 		   int refspec_nr, const char **refspec, int flags,
-		   int * nonfastforward);
+		   unsigned int * reject_reasons);
 
 const struct ref *transport_get_remote_refs(struct transport *transport);
 
@@ -170,7 +171,7 @@ void transport_update_tracking_ref(struct remote *remote, struct ref *ref, int v
 int transport_refs_pushed(struct ref *ref);
 
 void transport_print_push_status(const char *dest, struct ref *refs,
-		  int verbose, int porcelain, int *nonfastforward);
+		  int verbose, int porcelain, unsigned int *reject_reasons);
 
 typedef void alternate_ref_fn(const struct ref *, void *);
 extern void for_each_alternate_ref(alternate_ref_fn, void *);
-- 
1.8.0.158.g0c4328c

^ permalink raw reply related

* [PATCH v6 2/8] push: add advice for rejected tag reference
From: Chris Rorvick @ 2012-11-30  1:41 UTC (permalink / raw)
  To: git
  Cc: Chris Rorvick, Angelo Borsotti, Drew Northup, Michael Haggerty,
	Philip Oakley, Johannes Sixt, Kacper Kornet, Jeff King,
	Felipe Contreras, Junio C Hamano
In-Reply-To: <1354239700-3325-1-git-send-email-chris@rorvick.com>

Advising the user to fetch and merge only makes sense if the rejected
reference is a branch.  If none of the rejections are for branches, just
tell the user the reference already exists.

Signed-off-by: Chris Rorvick <chris@rorvick.com>
---
 builtin/push.c | 11 +++++++++++
 cache.h        |  1 +
 remote.c       | 10 ++++++++++
 transport.c    |  2 ++
 transport.h    |  1 +
 5 files changed, 25 insertions(+)

diff --git a/builtin/push.c b/builtin/push.c
index 9d17fc7..e08485d 100644
--- a/builtin/push.c
+++ b/builtin/push.c
@@ -220,6 +220,10 @@ static const char message_advice_checkout_pull_push[] =
 	   "(e.g. 'git pull') before pushing again.\n"
 	   "See the 'Note about fast-forwards' in 'git push --help' for details.");
 
+static const char message_advice_ref_already_exists[] =
+	N_("Updates were rejected because the destination reference already exists\n"
+	   "in the remote and the update is not a fast-forward.");
+
 static void advise_pull_before_push(void)
 {
 	if (!advice_push_non_ff_current || !advice_push_nonfastforward)
@@ -241,6 +245,11 @@ static void advise_checkout_pull_push(void)
 	advise(_(message_advice_checkout_pull_push));
 }
 
+static void advise_ref_already_exists(void)
+{
+	advise(_(message_advice_ref_already_exists));
+}
+
 static int push_with_options(struct transport *transport, int flags)
 {
 	int err;
@@ -272,6 +281,8 @@ static int push_with_options(struct transport *transport, int flags)
 			advise_use_upstream();
 		else
 			advise_checkout_pull_push();
+	} else if (reject_reasons & REJECT_ALREADY_EXISTS) {
+		advise_ref_already_exists();
 	}
 
 	return 1;
diff --git a/cache.h b/cache.h
index dbd8018..d72b64d 100644
--- a/cache.h
+++ b/cache.h
@@ -1002,6 +1002,7 @@ struct ref {
 	unsigned int force:1,
 		merge:1,
 		nonfastforward:1,
+		not_forwardable:1,
 		deletion:1;
 	enum {
 		REF_STATUS_NONE = 0,
diff --git a/remote.c b/remote.c
index 04fd9ea..5101683 100644
--- a/remote.c
+++ b/remote.c
@@ -1279,6 +1279,14 @@ int match_push_refs(struct ref *src, struct ref **dst,
 	return 0;
 }
 
+static inline int is_forwardable(struct ref* ref)
+{
+	if (!prefixcmp(ref->name, "refs/tags/"))
+		return 0;
+
+	return 1;
+}
+
 void set_ref_status_for_push(struct ref *remote_refs, int send_mirror,
 	int force_update)
 {
@@ -1316,6 +1324,8 @@ void set_ref_status_for_push(struct ref *remote_refs, int send_mirror,
 		 *     always allowed.
 		 */
 
+		ref->not_forwardable = !is_forwardable(ref);
+
 		ref->nonfastforward =
 			!ref->deletion &&
 			!is_null_sha1(ref->old_sha1) &&
diff --git a/transport.c b/transport.c
index d4568e7..bc31e8e 100644
--- a/transport.c
+++ b/transport.c
@@ -740,6 +740,8 @@ void transport_print_push_status(const char *dest, struct ref *refs,
 		    ref->status != REF_STATUS_OK)
 			n += print_one_push_status(ref, dest, n, porcelain);
 		if (ref->status == REF_STATUS_REJECT_NONFASTFORWARD) {
+			if (ref->not_forwardable)
+				*reject_reasons |= REJECT_ALREADY_EXISTS;
 			if (!strcmp(head, ref->name))
 				*reject_reasons |= REJECT_NON_FF_HEAD;
 			else
diff --git a/transport.h b/transport.h
index 404b113..bfd2df5 100644
--- a/transport.h
+++ b/transport.h
@@ -142,6 +142,7 @@ void transport_set_verbosity(struct transport *transport, int verbosity,
 
 #define REJECT_NON_FF_HEAD     0x01
 #define REJECT_NON_FF_OTHER    0x02
+#define REJECT_ALREADY_EXISTS  0x04
 
 int transport_push(struct transport *connection,
 		   int refspec_nr, const char **refspec, int flags,
-- 
1.8.0.158.g0c4328c

^ permalink raw reply related

* [PATCH v6 0/8] push: update remote tags only with force
From: Chris Rorvick @ 2012-11-30  1:41 UTC (permalink / raw)
  To: git
  Cc: Chris Rorvick, Angelo Borsotti, Drew Northup, Michael Haggerty,
	Philip Oakley, Johannes Sixt, Kacper Kornet, Jeff King,
	Felipe Contreras, Junio C Hamano

This patch series originated in response to the following thread:

  http://thread.gmane.org/gmane.comp.version-control.git/208354

I made some adjustments based on Junio's last round of feedback
including a new patch reworking the "push rules" comment in remote.c.
Also refined some of the log messages--nothing major.  Finally, took a
stab at putting something together for the release notes, see below.

Chris

Release notes:

"git push" no longer updates tags (lightweight or annotated) by default.
Specifically, if the destination reference already exists and is under
refs/tags/ or it points to a tag object, it is not allowed to fast-
forward (unless forced using +A:B notation or by passing --force.)  This
is consistent with how a tag is normally thought of: a reference that
does not move once defined.  It also ensures a push will not
inadvertently clobber an already existing tag--something that can go
unnoticed if fast-forwarding is allowed.

Chris Rorvick (8):
  push: return reject reasons as a bitset
  push: add advice for rejected tag reference
  push: flag updates
  push: flag updates that require force
  push: require force for refs under refs/tags/
  push: require force for annotated tags
  push: clarify rejection of update to non-commit-ish
  push: cleanup push rules comment

 Documentation/git-push.txt |  9 ++---
 builtin/push.c             | 24 +++++++++-----
 builtin/send-pack.c        |  9 +++--
 cache.h                    |  7 +++-
 remote.c                   | 83 +++++++++++++++++++++++++++++++++++-----------
 send-pack.c                |  1 +
 t/t5516-fetch-push.sh      | 44 +++++++++++++++++++++++-
 transport-helper.c         |  6 ++++
 transport.c                | 25 ++++++++------
 transport.h                | 10 +++---
 10 files changed, 167 insertions(+), 51 deletions(-)

-- 
1.8.0.158.g0c4328c

^ permalink raw reply

* Re: [PATCH] cache-tree: invalidate i-t-a paths after writing trees
From: Nguyen Thai Ngoc Duy @ 2012-11-30  1:26 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git, Jeff King, Jonathon Mah
In-Reply-To: <7vhao8neck.fsf@alter.siamese.dyndns.org>

On Fri, Nov 30, 2012 at 7:06 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
>
>>> An alternative might be to add a "phoney" bit next to "used" in the
>>> cache_tree structure, mark the cache tree as phoney when we skip an
>>> entry marked as CE_REMOVE or CE_ITA, and make the postprocessing
>>> loop this patch adds aware of that bit, instead of iterating over
>>> the index entries; instead, it would recurse the resulting cache
>>> tree and invalidate parts of the tree that have subtrees with the
>>> "phoney" bit set, or something.
>>
>> Yeah, that sounds better.
>
> Did anything happen to this topic after this?

Not from my side because I forgot to mark this thread as a todo item
and unsurprisingly forgot about it.
-- 
Duy

^ permalink raw reply

* Re: [PATCH] gitweb: add readme to overview page
From: Xypron @ 2012-11-30  1:11 UTC (permalink / raw)
  To: git; +Cc: Junio C Hamano
In-Reply-To: <50B7E1FD.8060001@gmx.de>

The following setting provides the same feature

# html text to include at home page
$home_text = "indextext.html";

Sorry for the noise.

Best regards

Heinrich Schuchardt

On 29.11.2012 23:30, Xypron wrote:
> Hello Junio,
> 
> thank you for your comment in message
> <7vip9ak971.fsf@alter.siamese.dyndns.org>
> that message <1352652039-31453-1-git-send-email-xypron.glpk@gmx.de>
> lost the thread context.
> 
> As already described I would be happy if a README.html could be added to
> the overview page of gitweb.
> 
> Please, find below an updated patch. Compared to the first version of my
> patch it avoids a warning concerning doubled slashes in filenames and adds
> a subtitle "projects" between the README and the project list.
> 
> Best regards
> 
> Heinrich Schuchardt
> 
> Subject: [PATCH] gitweb: add readme to overview page
> 
> For repositories it is possible to maintain a README.html which will
> be shown on the summary page. This is not possible for the server
> root.
> 
> German law requires to provide contact data on the web server. This
> data could easily be entered in the overview page using a README.html.
> 
> Furthermore it is possible to put the repositories not directly into
> the root directory but into a subdirectory. Here also a README.html
> would be helpful to indicate what the subdirectory is about.
> 
> The patch introduces README.html functionality for the root directory
> and all subdirectories.
> 
> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
> ---
>  gitweb/gitweb.perl |   13 +++++++++++++
>  1 file changed, 13 insertions(+)
> 
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index e8812fa..618b0d8 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -6368,6 +6368,19 @@ sub git_project_list {
>  	}
>  
>  	git_project_search_form($searchtext, $search_use_regexp);
> +	# If XSS prevention is on, we don't include README.html.
> +	# TODO: Allow a readme in some safe format.
> +	my $path = "";
> +	if (defined $project_filter) {
> +		$path = "/$project_filter";
> +	}
> +	if (!$prevent_xss && -s "$projectroot$path/README.html") {
> +		print "<div class=\"title\">readme</div>\n" .
> +		"<div class=\"readme\">\n";
> +		insert_file("$projectroot$path/README.html");
> +		print "\n</div>\n"; # class="readme"
> +	}
> +	print "<div class=\"title\">projects</div>\n";
>  	git_project_list_body(\@list, $order);
>  	git_footer_html();
>  }

^ permalink raw reply

* Re: [PATCH v5 0/2] submodule update: add --remote for submodule's upstream changes
From: Phil Hord @ 2012-11-30  1:11 UTC (permalink / raw)
  To: W. Trevor King
  Cc: Git, Junio C Hamano, Heiko Voigt, Jeff King, Shawn Pearce,
	Jens Lehmann, Nahor
In-Reply-To: <20121129191326.GC27409@odin.tremily.us>

On Thu, Nov 29, 2012 at 2:13 PM, W. Trevor King <wking@tremily.us> wrote:
>
> On Thu, Nov 29, 2012 at 01:29:12PM -0500, Phil Hord wrote:
>> On Fri, Nov 23, 2012 at 12:54 PM, W. Trevor King <wking@tremily.us> wrote:
>> > [snip initial thoughts leading to the update --remote v5]
>>
>> I was thinking the same thing, but reading this whole thread a couple of
>> weeks late.  Thanks for noticing.
>>
>> Moreover, I think that 'git submodule update --pull' is also the wrong way
>> to spell this action.   Maybe you are misled from the outset by your
>> current workflow:
>
> Did you see my v5 (add --remote) series?

Eventually, I did.  Sorry for the out-of-order replies.


>> For that reason, I don't like the --pull switch since it implies a
>> fetch, but I will not always want to do a fetch.
>
>   $ git submodule update --remote --no-fetch
>
> will not fetch the submodule remotes.

This seems precisely backwards to me. Why not use

  $ git submodule update --remote --fetch

to do your "default" behavior instead?   I suppose I am arguing
against the tide of the dominant workflow, but the fetch-by-default
idea needlessly conflates two primitive operations:  "float" and
"fetch".

>> I don't know which remote I should be tracking, though.  I suppose
>> it is 'origin' for now, but maybe it is just whatever
>> $superproject's HEAD's remote-tracking branch indicates.
>
> With the --remote series, I always use "origin" because that's what
> `submodule add` should be setting up.  If people want to change that
> up by hand, we may need a submodule.<name>.remote configuration
> option.

I've always felt that the "origin" defaults are broken and are simply
being ignored because most users do not trip over them.  But ISTR that
submodule commands use the remote indicated by the superproject's
current remote-tracking configuration, with a fallback to 'origin' if
there is none.  Sort of a "best effort" algorithm, I think.  Am I
remembering that wrong?


>> I am not sure I want the gitlinks in superproject to update automatically
>> in the index, but I definitely do not want to automatically create a commit
>> for them.
>
> Commits are dissabled by default (see my recent --commit RFC for how
> they would be enabled).
>
>> But I really don't want to figure out how to handle submodule
>> collisions during a merge (or rebase!) of my superproject with changes that
>> someone else auto-committed in his local $superproject as he and I
>> arbitrarily floated up the upstream independently.  There is nothing but
>> loathing down that path.
>
> This is true.  I'm not sure how gitlink collisions are currently
> handled…


They've always been trouble for me.  But it may be that I am ignorant.

Phil

^ permalink raw reply

* Re: [PATCH] cache-tree: invalidate i-t-a paths after writing trees
From: Junio C Hamano @ 2012-11-30  0:06 UTC (permalink / raw)
  To: Nguyen Thai Ngoc Duy; +Cc: git, Jeff King, Jonathon Mah
In-Reply-To: <CACsJy8DEwpg0gY1o6gSB747W5fAYYxz97e-qnkQthSut3B7Eag@mail.gmail.com>

Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:

>> An alternative might be to add a "phoney" bit next to "used" in the
>> cache_tree structure, mark the cache tree as phoney when we skip an
>> entry marked as CE_REMOVE or CE_ITA, and make the postprocessing
>> loop this patch adds aware of that bit, instead of iterating over
>> the index entries; instead, it would recurse the resulting cache
>> tree and invalidate parts of the tree that have subtrees with the
>> "phoney" bit set, or something.
>
> Yeah, that sounds better.

Did anything happen to this topic after this?

^ permalink raw reply

* Re: [PATCH 6/8] imap-send: change msg_data from storing (char *, len) to storing strbuf
From: Jeff King @ 2012-11-29 23:43 UTC (permalink / raw)
  To: Michael Haggerty; +Cc: Junio C Hamano, git, Jeremy White, Johannes Schindelin
In-Reply-To: <7vboegp04x.fsf@alter.siamese.dyndns.org>

On Thu, Nov 29, 2012 at 01:30:54PM -0800, Junio C Hamano wrote:

> > For some reason, there is a bunch of infrastructure in this file for
> > dealing with IMAP flags, although there is nothing in the code that
> > actually allows any flags to be set.  If there is no plan to add
> > support for flags in the future, a bunch of code could be ripped out
> > and "struct msg_data" could be completely replaced with strbuf.
> 
> Yeah, after all these years we have kept the unused flags field
> there and nobody needed anything out of it.  I am OK with a removal
> if it is done at the very end of the series.

There's a bunch of unused junk in imap-send. The original implementation
copied a bunch of code from isync, a much more full-featured imap
client, and the result ended up way more complex than it needed to be. I
have ripped a few things out over the years when they cause a problem
(e.g., portability of /dev/urandom, conflict over the name "struct
string_list"), but have mostly let it be out of a vague sense that we
might one day want to pull bugfixes from isync upstream.

That has not happened once in the last six years, though, and I would
doubt that a straightforward merge would work after so many years. So
ripping out and refactoring the code in the name of maintainability is
probably a good thing at this point.

-Peff

^ permalink raw reply

* What's cooking in git.git (Nov 2012, #10; Thu, 29)
From: Junio C Hamano @ 2012-11-29 23:22 UTC (permalink / raw)
  To: git

What's cooking in git.git (Nov 2012, #10; Thu, 29)
--------------------------------------------------

Here are the topics that have been cooking.  Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.

Hopefully 1.8.1-rc0 preview will be tagged this weekend.  Many
topics are marked to be cooked in 'next' during the feature freeze,
but some topics in flight should be in 'master' before -rc1 happens.

You can find the changes described here in the integration branches of the
repositories listed at

    http://git-blame.blogspot.com/p/git-public-repositories.html

--------------------------------------------------
[New Topics]

* wk/submodule-update-remote (2012-11-28) 2 commits
 - submodule add: If --branch is given, record it in .gitmodules
 - submodule update: add --remote for submodule's upstream changes

 Still under active discussion.

--------------------------------------------------
[Graduated to "master"]

* er/doc-add-new-commands (2012-11-26) 1 commit
  (merged to 'next' on 2012-11-28 at 2daf755)
 + Documentation: how to add a new command


* fc/completion-test-simplification (2012-11-16) 6 commits
  (merged to 'next' on 2012-11-28 at b7b2f67)
 + completion: simplify __gitcomp() test helper
 + completion: refactor __gitcomp related tests
 + completion: consolidate test_completion*() tests
 + completion: simplify tests using test_completion_long()
 + completion: standardize final space marker in tests
 + completion: add comment for test_completion()

 Clean up completion tests.  Use of conslidated helper may make
 instrumenting one particular test during debugging of the test
 itself, but I think that issue should be addressed in some other
 way (e.g. making sure individual tests in 9902 can be skipped).


* fc/remote-hg (2012-11-27) 22 commits
  (merged to 'next' on 2012-11-28 at f805784)
 + remote-hg: fix for older versions of python
 + remote-hg: fix for files with spaces
  (merged to 'next' on 2012-11-18 at 4a4f2e4)
 + remote-hg: avoid bad refs
 + remote-hg: try the 'tip' if no checkout present
 + remote-hg: fix compatibility with older versions of hg
 + remote-hg: add missing config for basic tests
 + remote-hg: the author email can be null
 + remote-hg: add option to not track branches
 + remote-hg: add extra author test
 + remote-hg: add tests to compare with hg-git
 + remote-hg: add bidirectional tests
 + test-lib: avoid full path to store test results
 + remote-hg: add basic tests
 + remote-hg: fake bookmark when there's none
 + remote-hg: add compat for hg-git author fixes
 + remote-hg: add support for hg-git compat mode
 + remote-hg: match hg merge behavior
 + remote-hg: make sure the encoding is correct
 + remote-hg: add support to push URLs
 + remote-hg: add support for remote pushing
 + remote-hg: add support for pushing
 + Add new remote-hg transport helper

 New remote helper for hg.


* fc/send-email-no-sender-prompt (2012-11-26) 1 commit
  (merged to 'next' on 2012-11-28 at 690d525)
 + send-email: avoid questions when user has an ident
 (this branch is used by jk/send-email-sender-prompt.)

 In cases the sender ident is sufficiently specified, there is no
 need to prompt the user before sending the series out.


* fc/zsh-completion (2012-11-19) 2 commits
  (merged to 'next' on 2012-11-26 at 48ebdc9)
 + completion: start moving to the new zsh completion
 + completion: add new zsh completion

 Completion script revamped for zsh users.


* jc/doc-push-satellite (2012-11-27) 1 commit
  (merged to 'next' on 2012-11-28 at 7114637)
 + Documentation/git-push.txt: clarify the "push from satellite" workflow

 Clarify what the example that pushes branches into remote-tracking
 branches of another repository is trying to achieve (i.e. emulating
 a fetch in reverse).


* jk/pickaxe-textconv (2012-10-28) 2 commits
  (merged to 'next' on 2012-11-26 at 2c5b5c9)
 + pickaxe: use textconv for -S counting
 + pickaxe: hoist empty needle check

 Use textconv filters when searching with "log -S".


* jk/send-email-sender-prompt (2012-11-28) 7 commits
  (merged to 'next' on 2012-11-28 at a808921)
 + t9001: check send-email behavior with implicit sender
 + Merge branch 'fc/send-email-no-sender-prompt' into jk/send-email-sender-prompt
 + t: add tests for "git var"
 + ident: keep separate "explicit" flags for author and committer
 + ident: make user_ident_explicitly_given static
 + t7502: factor out autoident prerequisite
 + test-lib: allow negation of prerequisites
 (this branch uses fc/send-email-no-sender-prompt.)

 General clean-ups in various areas, originally written to support a
 patch that later turned out to be unneeded.


* jl/submodule-rm (2012-11-23) 1 commit
  (merged to 'next' on 2012-11-28 at 0e4115f)
 + Teach rm to remove submodules when given with a trailing '/'

 Finishing touches to "git rm $submodule" that removes the working
 tree of a submodule.


* km/send-email-remove-cruft-in-address (2012-11-26) 5 commits
  (merged to 'next' on 2012-11-28 at 2688772)
 + git-send-email: allow edit invalid email address
 + git-send-email: ask what to do with an invalid email address
 + git-send-email: remove invalid addresses earlier
 + git-send-email: fix fallback code in extract_valid_address()
 + git-send-email: remove garbage after email address

 Garbage after e-mail address on Cc: in the patch breaks the
 transmission of it over send-email.


* lt/diff-stat-show-0-lines (2012-11-27) 6 commits
  (merged to 'next' on 2012-11-28 at de89eed)
 + diff --shortstat: do not count "unmerged" entries
 + diff --stat: do not count "unmerged" entries
 + diff --stat: move the "total count" logic to the last loop
 + diff --stat: use "file" temporary variable to refer to data->files[i]
 + diff --stat: status of unmodified pair in diff-q is not zero
 + test: add failing tests for "diff --stat" to t4049

 "git diff --stat" miscounted the total number of changed lines when
 binary files were involved and hidden beyond --stat-count.  It also
 miscounted the total number of changed files when there were
 unmerged paths.


* mk/complete-tcsh (2012-11-27) 1 commit
  (merged to 'next' on 2012-11-28 at 5528439)
 + Support for git aliasing for tcsh completion

 Completion script revamped for tcsh users.


* mm/status-push-pull-advise (2012-11-16) 1 commit
  (merged to 'next' on 2012-11-26 at ed40d5e)
 + status: add advice on how to push/pull to tracking branch

 When "git checkout" checks out a branch, it tells the user how far
 behind (or ahead) the new branch is relative to the remote tracking
 branch it builds upon.  The message now also advises how to sync
 them up by pushing or pulling.


* pp/gitweb-config-underscore (2012-11-21) 1 commit
  (merged to 'next' on 2012-11-28 at fc9bf5f)
 + gitweb: make remote_heads config setting work

 The key "gitweb.remote_heads" is not legal git config; this maps it to
 "gitweb.remoteheads".


* pw/p4-various-fixes (2012-11-26) 6 commits
  (merged to 'next' on 2012-11-28 at 1a6f9a9)
 + git p4: remove unneeded cmd initialization
 + git p4: fix labelDetails typo in exception
 + git p4 test: display unresolvable host error
 + git p4: catch p4 errors when streaming file contents
 + git p4: handle servers without move support
 + git p4: catch p4 describe errors

--------------------------------------------------
[Stalled]

* pf/editor-ignore-sigint (2012-11-11) 5 commits
 - launch_editor: propagate SIGINT from editor to git
 - run-command: do not warn about child death by SIGINT
 - run-command: drop silent_exec_failure arg from wait_or_whine
 - launch_editor: ignore SIGINT while the editor has control
 - launch_editor: refactor to use start/finish_command

 Avoid confusing cases where the user hits Ctrl-C while in the editor
 session, not realizing git will receive the signal. Since most editors
 will take over the terminal and will block SIGINT, this is not likely
 to confuse anyone.

 Some people raised issues with emacsclient, which are addressed by this
 re-roll. It should probably also handle SIGQUIT, and there were a
 handful of other review comments.

 Expecting a re-roll.


* mo/cvs-server-updates (2012-10-16) 10 commits
 - cvsserver Documentation: new cvs ... -r support
 - cvsserver: add t9402 to test branch and tag refs
 - cvsserver: support -r and sticky tags for most operations
 - cvsserver: Add version awareness to argsfromdir
 - cvsserver: generalize getmeta() to recognize commit refs
 - cvsserver: implement req_Sticky and related utilities
 - cvsserver: add misc commit lookup, file meta data, and file listing functions
 - cvsserver: define a tag name character escape mechanism
 - cvsserver: cleanup extra slashes in filename arguments
 - cvsserver: factor out git-log parsing logic

 Needs review by folks interested in cvsserver.


* as/check-ignore (2012-11-08) 14 commits
 - t0007: fix tests on Windows
 - Documentation/check-ignore: we show the deciding match, not the first
 - Add git-check-ignore sub-command
 - dir.c: provide free_directory() for reclaiming dir_struct memory
 - pathspec.c: move reusable code from builtin/add.c
 - dir.c: refactor treat_gitlinks()
 - dir.c: keep track of where patterns came from
 - dir.c: refactor is_path_excluded()
 - dir.c: refactor is_excluded()
 - dir.c: refactor is_excluded_from_list()
 - dir.c: rename excluded() to is_excluded()
 - dir.c: rename excluded_from_list() to is_excluded_from_list()
 - dir.c: rename path_excluded() to is_path_excluded()
 - dir.c: rename cryptic 'which' variable to more consistent name

 Duy helped to reroll this.

 Expecting a re-roll.


* aw/rebase-am-failure-detection (2012-10-11) 1 commit
 - rebase: Handle cases where format-patch fails

 I am unhappy a bit about the possible performance implications of
 having to store the output in a temporary file only for a rare case
 of format-patch aborting.


* jk/lua-hackery (2012-10-07) 6 commits
 - pretty: fix up one-off format_commit_message calls
 - Minimum compilation fixup
 - Makefile: make "lua" a bit more configurable
 - add a "lua" pretty format
 - add basic lua infrastructure
 - pretty: make some commit-parsing helpers more public

 Interesting exercise. When we do this for real, we probably would want
 to wrap a commit to make it more like an "object" with methods like
 "parents", etc.


* fc/remote-testgit-feature-done (2012-10-29) 1 commit
 - remote-testgit: properly check for errors

 Needs review and Ack (or Nack) from people involved in the remote
 helper interface for this to move forward.


* rc/maint-complete-git-p4 (2012-09-24) 1 commit
  (merged to 'next' on 2012-10-29 at af52cef)
 + Teach git-completion about git p4

 Comment from Pete will need to be addressed in a follow-up patch.


* as/test-tweaks (2012-09-20) 7 commits
 - tests: paint unexpectedly fixed known breakages in bold red
 - tests: test the test framework more thoroughly
 - [SQUASH] t/t0000-basic.sh: quoting of TEST_DIRECTORY is screwed up
 - tests: refactor mechanics of testing in a sub test-lib
 - tests: paint skipped tests in bold blue
 - tests: test number comes first in 'not ok $count - $message'
 - tests: paint known breakages in bold yellow

 Various minor tweaks to the test framework to paint its output
 lines in colors that match what they mean better.

 Has the "is this really blue?" issue Peff raised resolved???


* jc/maint-name-rev (2012-09-17) 7 commits
 - describe --contains: use "name-rev --algorithm=weight"
 - name-rev --algorithm=weight: tests and documentation
 - name-rev --algorithm=weight: cache the computed weight in notes
 - name-rev --algorithm=weight: trivial optimization
 - name-rev: --algorithm option
 - name_rev: clarify the logic to assign a new tip-name to a commit
 - name-rev: lose unnecessary typedef

 "git name-rev" names the given revision based on a ref that can be
 reached in the smallest number of steps from the rev, but that is
 not useful when the caller wants to know which tag is the oldest one
 that contains the rev.  This teaches a new mode to the command that
 uses the oldest ref among those which contain the rev.

 I am not sure if this is worth it; for one thing, even with the help
 from notes-cache, it seems to make the "describe --contains" even
 slower. Also the command will be unusably slow for a user who does
 not have a write access (hence unable to create or update the
 notes-cache).

 Stalled mostly due to lack of responses.


* jc/xprm-generation (2012-09-14) 1 commit
 - test-generation: compute generation numbers and clock skews

 A toy to analyze how bad the clock skews are in histories of real
 world projects.

 Stalled mostly due to lack of responses.


* jc/blame-no-follow (2012-09-21) 2 commits
 - blame: pay attention to --no-follow
 - diff: accept --no-follow option

 Teaches "--no-follow" option to "git blame" to disable its
 whole-file rename detection.

 Stalled mostly due to lack of responses.


* jc/doc-default-format (2012-11-26) 2 commits
 - [SQAUSH] allow "cd Doc* && make DEFAULT_DOC_TARGET=..."
 - Allow generating a non-default set of documentation

 Need to address the installation half if this is to be any useful.


* mk/maint-graph-infinity-loop (2012-09-25) 1 commit
 - graph.c: infinite loop in git whatchanged --graph -m

 The --graph code fell into infinite loop when asked to do what the
 code did not expect ;-)

 Anybody who worked on "--graph" wants to comment?
 Stalled mostly due to lack of responses.


* jc/add-delete-default (2012-08-13) 1 commit
 - git add: notice removal of tracked paths by default

 "git add dir/" updated modified files and added new files, but does
 not notice removed files, which may be "Huh?" to some users.  They
 can of course use "git add -A dir/", but why should they?

 Resurrected from graveyard, as I thought it was a worthwhile thing
 to do in the longer term.

 Waiting for comments.


* mb/remote-default-nn-origin (2012-07-11) 6 commits
 - Teach get_default_remote to respect remote.default.
 - Test that plain "git fetch" uses remote.default when on a detached HEAD.
 - Teach clone to set remote.default.
 - Teach "git remote" about remote.default.
 - Teach remote.c about the remote.default configuration setting.
 - Rename remote.c's default_remote_name static variables.

 When the user does not specify what remote to interact with, we
 often attempt to use 'origin'.  This can now be customized via a
 configuration variable.

 Expecting a re-roll.

 "The first remote becomes the default" bit is better done as a
 separate step.

--------------------------------------------------
[Cooking]

* bc/append-signed-off-by (2012-11-26) 11 commits
 - Unify appending signoff in format-patch, commit and sequencer
 - format-patch: update append_signoff prototype
 - format-patch: stricter S-o-b detection
 - t4014: more tests about appending s-o-b lines
 - sequencer.c: teach append_signoff to avoid adding a duplicate newline
 - sequencer.c: teach append_signoff how to detect duplicate s-o-b
 - sequencer.c: always separate "(cherry picked from" from commit body
 - sequencer.c: recognize "(cherry picked from ..." as part of s-o-b footer
 - t/t3511: add some tests of 'cherry-pick -s' functionality
 - t/test-lib-functions.sh: allow to specify the tag name to test_commit
 - sequencer.c: remove broken support for rfc2822 continuation in footer

 Expecting a re-roll after a review.


* mh/unify-xml-in-imap-send-and-http-push (2012-11-29) 8 commits
 - wrap_in_html(): process message in bulk rather than line-by-line
 - wrap_in_html(): use strbuf_addstr_xml_quoted()
 - imap-send: change msg_data from storing (ptr, len) to storing strbuf
 - imap-send: correctly report errors reading from stdin
 - imap-send: store all_msgs as a strbuf
 - lf_to_crlf(): NUL-terminate msg_data::data
 - xml_entities(): use function strbuf_addstr_xml_quoted()
 - Add new function strbuf_add_xml_quoted()

 Will merge to 'next'.


* rr/t4041-cleanup (2012-11-27) 4 commits
 - t4041 (diff-submodule-option): modernize style
 - t4041 (diff-submodule-option): rewrite add_file() routine
 - t4041 (diff-submodule-option): parse digests sensibly
 - t4041 (diff-submodule-option): don't hardcode SHA-1 in expected outputs

 As a clean-up, it still misses some.
 Expecting a re-roll.


* jc/doc-maintainer (2012-11-27) 1 commit
 - update "howto maintain git"

 An early draft that is still incomplete.


* jk/fsck-dot-in-trees (2012-11-28) 2 commits
  (merged to 'next' on 2012-11-28 at 519dabc)
 + fsck: warn about ".git" in trees
 + fsck: warn about '.' and '..' in trees

 Will cook in 'next'.


* mh/doc-remote-helpers (2012-11-27) 6 commits
 - git-remote-helpers.txt: clarify options & ref list attributes
 - git-remote-helpers.txt: clarify command <-> capability correspondences
 - git-remote-helpers.txt: rearrange description of capabilities
 - git-remote-helpers.txt: minor grammar fix
 - git-remote-helpers.txt: document missing capabilities
 - git-remote-helpers.txt: document invocation before input format

 Need comment and Ack from people who have worked on remote-helpers
 before this goes forward.


* mh/pthreads-autoconf (2012-11-27) 1 commit
  (merged to 'next' on 2012-11-28 at 780600e)
 + configure.ac: fix pthreads detection on Mac OS X

 Will cook in 'next'.


* jn/warn-on-inaccessible-loosen (2012-10-14) 4 commits
  (merged to 'next' on 2012-11-28 at 43d51c2)
 + config: exit on error accessing any config file
 + doc: advertise GIT_CONFIG_NOSYSTEM
 + config: treat user and xdg config permission problems as errors
 + config, gitignore: failure to access with ENOTDIR is ok

 An RFC to deal with a situation where .config/git is a file and we
 notice .config/git/config is not readable due to ENOTDIR, not
 ENOENT.

 Will cook in 'next'.


* mh/ceiling (2012-10-29) 8 commits
  (merged to 'next' on 2012-11-26 at d1ce76a)
 + string_list_longest_prefix(): remove function
 + setup_git_directory_gently_1(): resolve symlinks in ceiling paths
 + longest_ancestor_length(): require prefix list entries to be normalized
 + longest_ancestor_length(): take a string_list argument for prefixes
 + longest_ancestor_length(): use string_list_split()
 + Introduce new function real_path_if_valid()
 + real_path_internal(): add comment explaining use of cwd
 + Introduce new static function real_path_internal()

 Elements of GIT_CEILING_DIRECTORIES list may not match the real
 pathname we obtain from getcwd(), leading the GIT_DIR discovery
 logic to escape the ceilings the user thought to have specified.

 Resurrected from Stalled; the earlier performance fear was
 unwarranted.

 Will cook in 'next'.


* fc/fast-export-fixes (2012-11-29) 15 commits
 - fast-export: make sure updated refs get updated
 - fast-export: don't handle uninteresting refs
 - fast-export: fix comparison in tests
 - fast-export: trivial cleanup
 - remote-testgit: implement the "done" feature manually
 - remote-testgit: report success after an import
 - remote-testgit: exercise more features
 - remote-testgit: cleanup tests
 - remote-testgit: remove irrelevant test
 - remote-testgit: remove non-local functionality
 - Add new simplified git-remote-testgit
 - Rename git-remote-testgit to git-remote-testpy
 - remote-helpers: fix failure message
 - remote-testgit: fix direction of marks
 - fast-export: avoid importing blob marks

 Will merge to (and cook in) 'next'.


* jc/apply-trailing-blank-removal (2012-10-12) 1 commit
  (merged to 'next' on 2012-11-26 at 3af69e7)
 + apply.c:update_pre_post_images(): the preimage can be truncated

 Fix to update_pre_post_images() that did not take into account the
 possibility that whitespace fix could shrink the preimage and
 change the number of lines in it.

 Will cook in 'next'.


* nd/pathspec-wildcard (2012-11-26) 4 commits
 - tree_entry_interesting: do basedir compare on wildcard patterns when possible
 - pathspec: apply "*.c" optimization from exclude
 - pathspec: do exact comparison on the leading non-wildcard part
 - pathspec: save the non-wildcard length part

 Will merge to 'next'.


* nd/wildmatch (2012-11-20) 14 commits
  (merged to 'next' on 2012-11-21 at 151288f)
 + test-wildmatch: avoid Windows path mangling
  (merged to 'next' on 2012-10-25 at 510e8df)
 + Support "**" wildcard in .gitignore and .gitattributes
 + wildmatch: make /**/ match zero or more directories
 + wildmatch: adjust "**" behavior
 + wildmatch: fix case-insensitive matching
 + wildmatch: remove static variable force_lower_case
 + wildmatch: make wildmatch's return value compatible with fnmatch
 + t3070: disable unreliable fnmatch tests
 + Integrate wildmatch to git
 + wildmatch: follow Git's coding convention
 + wildmatch: remove unnecessary functions
 + Import wildmatch from rsync
 + ctype: support iscntrl, ispunct, isxdigit and isprint
 + ctype: make sane_ctype[] const array

 Allows pathname patterns in .gitignore and .gitattributes files
 with double-asterisks "foo/**/bar" to match any number of directory
 hierarchies.

 I suspect that this needs to be plugged to pathspec matching code;
 otherwise "git log -- 'Docum*/**/*.txt'" would not show the log for
 commits that touch Documentation/git.txt, which would be confusing
 to the users.

 Will cook in 'next'.


* fc/remote-bzr (2012-11-28) 10 commits
 - (fixup) test-bzr.sh: fix multi-line string assignment
 - remote-bzr: detect local repositories
 - remote-bzr: add support for older versions of bzr
 - remote-bzr: add support to push special modes
 - remote-bzr: add support for fecthing special modes
 - remote-bzr: add simple tests
 - remote-bzr: update working tree
 - remote-bzr: add support for remote repositories
 - remote-bzr: add support for pushing
 - Add new remote-bzr transport helper

 New remote helper for bzr (v3).  With minor fixes, this may be ready
 for 'next'.


* cr/push-force-tag-update (2012-11-26) 7 commits
 - push: clarify rejection of update to non-commit-ish
 - push: require force for annotated tags
 - push: require force for refs under refs/tags/
 - push: flag updates that require force
 - push: keep track of "update" state separately
 - push: add advice for rejected tag reference
 - push: return reject reasons via a mask

 Require "-f" for push to update a tag, even if it is a fast-forward.

 With a minor tweak, I think this is getting ready for 'next'.
 Expecting a re-roll.

--------------------------------------------------
[Discarded]

* nd/unify-appending-of-s-o-b (2012-11-15) 1 commit
 . Unify appending signoff in format-patch, commit and sequencer

 I am not sure if the logic to refrain from adding a sign-off based
 on the existing run of sign-offs is done correctly in this change.

 Brandon's series attempts the same thing and seemed to be more
 cleanly done.


* nd/pretty-placeholder-with-color-option (2012-09-30) 9 commits
 . pretty: support %>> that steal trailing spaces
 . pretty: support truncating in %>, %< and %><
 . pretty: support padding placeholders, %< %> and %><
 . pretty: two phase conversion for non utf-8 commits
 . utf8.c: add utf8_strnwidth() with the ability to skip ansi sequences
 . utf8.c: move display_mode_esc_sequence_len() for use by other functions
 . pretty: support %C(auto[,N]) to turn on coloring on next placeholder(s)
 . pretty: split parsing %C into a separate function
 . pretty: share code between format_decoration and show_decorations

 This causes warnings with -Wuninitialized, so I've ejected it from pu
 for the time being.

^ permalink raw reply

* Re: [RFC/PATCH] l10n: de.po: translate 825 new messages
From: Thomas Rast @ 2012-11-29 23:02 UTC (permalink / raw)
  To: Ralf Thielow; +Cc: git, trast, jk, stimming
In-Reply-To: <1349200849-7436-1-git-send-email-ralf.thielow@gmail.com>

Hi Ralf

Here is the final third of my review.

>  #: builtin/prune-packed.c:7
>  msgid "git prune-packed [-n|--dry-run] [-q|--quiet]"
> -msgstr ""
> +msgstr "git prune-packed [-n|--dry-run] [-q|--quite]"
                                                 ^^^^^
typo at the far end

>  #: builtin/prune.c:133
> -#, fuzzy
>  msgid "report pruned objects"
> -msgstr "kann Objekt %s nicht lesen"
> +msgstr "meldet entfernte Objekte"

If you translate "pruned" as "gelöscht" or some such, that avoids the
ambiguity with "remote".

>  #: builtin/prune.c:136
>  msgid "expire objects older than <time>"
> -msgstr ""
> +msgstr "lässt Objekte älter als <Zeit> verfallen"

"verfallen" is nice!

>  #: builtin/push.c:391
>  msgid "check"
> -msgstr ""
> +msgstr "Überprüfung"

I think the original string should not be translatable to begin with.
The manpage says

  --recurse-submodules=check|on-demand
      Make sure all submodule commits used by the revisions to be pushed
      are available on a remote tracking branch. If *check* is used git
      will verify that all submodule commits that changed in the
      revisions to be pushed are available on at least one remote of the
      submodule. If any commits are missing the push will be aborted and
      exit with non-zero status. If *on-demand* is used all submodules
      that changed in the revisions to be pushed will be pushed. If
      on-demand was not able to push all necessary revisions it will
      also be aborted and exit with non-zero status.

So 'check' is not translatable.

>  #: builtin/push.c:395 builtin/push.c:396
>  msgid "receive pack program"
> -msgstr ""
> +msgstr "Programm zum Empfangen von Paketen"

Or perhaps "'receive-pack' Programm".

>  #: builtin/read-tree.c:111
> -#, fuzzy
>  msgid "only empty the index"
> -msgstr "Konnte die Bereitstellung nicht lesen"
> +msgstr "leert nur die Bereitstellung"

"Only" here means it doesn't read-a-tree, but empty the index.  So
dropping the "nur" would probably be better.

  #: builtin/remote.c:11
>  msgid "git remote [-v | --verbose]"
> -msgstr ""
> +msgstr "git remove [-v | --verbose]"
                  ^^^
typo

>  #: builtin/remote.c:173
>  msgid "set up remote as a mirror to push to or fetch from"
>  msgstr ""
> +"Aufsetzen der Fernarchivs als Spiegelarchiv zum Versenden und Anfordern"
              ^^^
des?

>  "Run \"git rev-parse --parseopt -h\" for more information on the first usage."
>  msgstr ""
> +"git rev-parse --parseopt [Optionen] -- [<Argumente>...]\n"
> +"   or: git rev-parse --sq-quote [<Argumente>...]\n"
> +"   or: git rev-parse [Optionen] [<Argumente>...]\n"
> +"\n"
> +"Führe \"git rev-parse --parseopt -h\" für weitere Informationen bei erster "
> +"Verwendung aus."

Should use 'oder:' in the case split, shouldn't it?

>  #: builtin/rm.c:134
> -#, fuzzy
>  msgid "do not list removed files"
> -msgstr "Kann geänderte Dateien nicht aus der Bereitstellung herausnehmen"
> +msgstr "listet keine entfernten Dateien auf"

Again removed->gelöscht or some such avoids an ambiguity.

>  #: builtin/show-branch.c:651
> -#, fuzzy
>  msgid "show remote-tracking and local branches"
> -msgstr "Kein externer Übernahmezweig für %s von %s"
> +msgstr "zeigt externer Übernahmezweige und lokale Zweige an"
                      ^^^
[...]
>  #: builtin/show-branch.c:653
> -#, fuzzy
>  msgid "show remote-tracking branches"
> -msgstr "Kein externer Übernahmezweig für %s von %s"
> +msgstr "zeigt externer Übernahmezweige an"
                      ^^^

extern*e*

>  #: builtin/tag.c:464
> -#, fuzzy
>  msgid "use another key to sign the tag"
> -msgstr "konnte Markierung nicht signieren"
> +msgstr "benutzt einen Schlüssel um die Markierung zu signieren"

The original says *another* -- maybe

  benutzt einen anderen Schlüssel um die Markierung zu signieren

>  #: builtin/update-index.c:750
>  msgid "mark files as \"not changing\""
> -msgstr ""
> +msgstr "markiert Dateien als \"not changing\""

Neither original nor translation are very helpful.  Maybe

  Always assume this file to be unchanged
  Betrachte diese Datei immer als unverändert

>  #: builtin/update-index.c:756
>  msgid "mark files as \"index-only\""
> -msgstr ""
> +msgstr "markiert Dateien als \"index-only\""

Likewise, but here I don't even understand what the manpage is trying to
tell me, in particular I don't see how it would be different from
assume-unchanged.  Maybe "see manpage" would be the best documentation.

>  #: builtin/update-index.c:776
>  msgid "repopulate stages #2 and #3 for the listed paths"
>  msgstr ""
> +"wiederholte Ausführung der Phasen #2 und #3 für die aufgelisteten Pfade"

ISTR we settled on something for 'stage', but it's not in the glossary.
Either way I don't think this is it.  "Ausführung der Phasen" would mean
that it's some part of a process, whereas the stages are a state.


Yay, that's it.  Even in three parts it was tedious, and I cannot begin
to imagine what *writing* 825 new translations must have felt like.
Thanks for your work!

- Thomas

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

^ permalink raw reply

* Re: [PATCH] gitweb: add readme to overview page
From: Xypron @ 2012-11-29 22:30 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git
In-Reply-To: <1352647962-21910-1-git-send-email-xypron.glpk@gmx.de>

Hello Junio,

thank you for your comment in message
<7vip9ak971.fsf@alter.siamese.dyndns.org>
that message <1352652039-31453-1-git-send-email-xypron.glpk@gmx.de>
lost the thread context.

As already described I would be happy if a README.html could be added to
the overview page of gitweb.

Please, find below an updated patch. Compared to the first version of my
patch it avoids a warning concerning doubled slashes in filenames and adds
a subtitle "projects" between the README and the project list.

Best regards

Heinrich Schuchardt

Subject: [PATCH] gitweb: add readme to overview page

For repositories it is possible to maintain a README.html which will
be shown on the summary page. This is not possible for the server
root.

German law requires to provide contact data on the web server. This
data could easily be entered in the overview page using a README.html.

Furthermore it is possible to put the repositories not directly into
the root directory but into a subdirectory. Here also a README.html
would be helpful to indicate what the subdirectory is about.

The patch introduces README.html functionality for the root directory
and all subdirectories.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
---
 gitweb/gitweb.perl |   13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index e8812fa..618b0d8 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -6368,6 +6368,19 @@ sub git_project_list {
 	}
 
 	git_project_search_form($searchtext, $search_use_regexp);
+	# If XSS prevention is on, we don't include README.html.
+	# TODO: Allow a readme in some safe format.
+	my $path = "";
+	if (defined $project_filter) {
+		$path = "/$project_filter";
+	}
+	if (!$prevent_xss && -s "$projectroot$path/README.html") {
+		print "<div class=\"title\">readme</div>\n" .
+		"<div class=\"readme\">\n";
+		insert_file("$projectroot$path/README.html");
+		print "\n</div>\n"; # class="readme"
+	}
+	print "<div class=\"title\">projects</div>\n";
 	git_project_list_body(\@list, $order);
 	git_footer_html();
 }
-- 
1.7.10.4

^ permalink raw reply related

* Re: [RFC/PATCH 1/2] reset: learn to reset to tree
From: Martin von Zweigbergk @ 2012-11-29 22:00 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzk20p6ik.fsf@alter.siamese.dyndns.org>

On Thu, Nov 29, 2012 at 11:13 AM, Junio C Hamano <gitster@pobox.com> wrote:
> [...]These
> two commands, "reset" and "checkout", share that the source we grab
> the blobs out of only need to be a tree and does not have to be a
> commit, and the only difference between them is where the blobs we
> grabbed out of that tree go, either only to the index or to both the
> index and the working tree.

Slightly off topic, but another difference (or somehow another aspect
of the same difference?) that has tripped me up a few times is that
"git checkout $rev ." only affects added and modified files (in $rev
compared to HEAD), but "git reset $rev ." would also delete deleted
files from the index. I suppose this is also a partial answer to your
question in another message:

> What does it even mean, even when you are on an existing commit, to
> hard reset partially?
>
> Perhaps you looking for "git checkout $tree -- $path"?

A more direct answer would be that I would expect "git reset --hard
$rev -- ." to behave like "git reset --hard $rev", except that it
wouldn't update HEAD. It seems to me that that would be similar to how
"git reset $rev -- ." behaves like "git reset $rev", except that it
doesn't update HEAD. But reset and checkout with and without paths
still confuse me after years of using git, so I wouldn't be surprised
if I'm not making any sense.

^ permalink raw reply

* Re: [PATCH 0/8] Add function strbuf_addstr_xml_quoted() and more
From: Junio C Hamano @ 2012-11-29 21:41 UTC (permalink / raw)
  To: Michael Haggerty; +Cc: git, Jeremy White, Johannes Schindelin
In-Reply-To: <1353841721-16269-1-git-send-email-mhagger@alum.mit.edu>

Michael Haggerty <mhagger@alum.mit.edu> writes:

> There were two functions doing almost the same XML quoting of
> character entities, so implement a library function
> strbuf_addstr_xml_quoted() and use that in both places.
>
> Along the way, do a lot of simplification within imap-send.c, which
> was doing a lot of its own string management instead of using strbuf.

Overall the series looked good to me.  Thanks; will queue.

^ permalink raw reply

* Re: [PATCH 6/8] imap-send: change msg_data from storing (char *, len) to storing strbuf
From: Junio C Hamano @ 2012-11-29 21:30 UTC (permalink / raw)
  To: Michael Haggerty; +Cc: git, Jeremy White, Johannes Schindelin
In-Reply-To: <1353841721-16269-7-git-send-email-mhagger@alum.mit.edu>

Michael Haggerty <mhagger@alum.mit.edu> writes:

> struct msg_data stored (char *, len) of the data to be included in a

That (<type>, <varname>) is a bit funny notation, even though it is
understandable.

> message, kept the character data NUL-terminated, etc., much like a
> strbuf would do.  So change it to use a struct strbuf.  This makes the
> code clearer and reduces copying a little bit.
>
> A side effect of this change is that the memory for each message is
> freed after it is used rather than leaked, though that detail is
> unimportant given that imap-send is a top-level command.
>
> --

?

> For some reason, there is a bunch of infrastructure in this file for
> dealing with IMAP flags, although there is nothing in the code that
> actually allows any flags to be set.  If there is no plan to add
> support for flags in the future, a bunch of code could be ripped out
> and "struct msg_data" could be completely replaced with strbuf.

Yeah, after all these years we have kept the unused flags field
there and nobody needed anything out of it.  I am OK with a removal
if it is done at the very end of the series.

Thanks.

^ permalink raw reply

* Re: [PATCH] gitweb: git_summary - show $project in title
From: Xypron @ 2012-11-29 21:07 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7v625agwiv.fsf@alter.siamese.dyndns.org>

Thank you for your comments. In the appended version of the patch
the project title is escaped:

Subject: [PATCH] gitweb: git_summary - show $project in title

Gitweb pages are structured by divs of class title with grey background.
The shortlog, and the log page show the project name as the first title.
Page summary only shows an empty grey box above the project details.
This provides an inconsistent user experience.

Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
---
 gitweb/gitweb.perl |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index e8812fa..be94b0b 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -6450,7 +6450,7 @@ sub git_summary {
 	git_header_html();
 	git_print_page_nav('summary','', $head);
 
-	print "<div class=\"title\">&nbsp;</div>\n";
+	print "<div class=\"title\">" . esc_html($project) . "</div>\n";
 	print "<table class=\"projects_list\">\n" .
 		"<tr id=\"metadata_desc\"><td>description</td><td>" . esc_html($descr) . "</td></tr>\n";
         unless ($omit_owner) {
-- 
1.7.10.4


On 13.11.2012 01:46, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
>> On Sun, Nov 11, 2012 at 06:20:58AM +0100, Henrich Schuchardt wrote:
>>
>>> Gitweb pages are structured by divs of class title with grey background.
>>> The shortlog, and the log page show the project name as the first title.
>>> Page summary only shows an empty grey box above the project details.
>>> This provides an inconstent user experience.
>>>
>>> This patch adds the missing project title.
>>>
>>> Signed-off-by: Henrich Schuchardt <xypron.glpk@gmx.de>
>>> ---
>>>  gitweb/gitweb.perl |    2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
>>> index 10ed9e5..3e1c452 100755
>>> --- a/gitweb/gitweb.perl
>>> +++ b/gitweb/gitweb.perl
>>> @@ -6451,7 +6451,7 @@ sub git_summary {
>>>  	git_header_html();
>>>  	git_print_page_nav('summary','', $head);
>>>  
>>> -	print "<div class=\"title\">&nbsp;</div>\n";
>>> +	print "<div class=\"title\">$project</div>\n";
>> I do not have any opinion on whether the intent of the change is good or
>> not, but shouldn't $project be run through esc_html() here?
> I think the answer is yes.  And if $project needs to be escaped, the
> git_feed function you fixed today has another codepath that needs to
> be fixed.  When git_get_project_description($project) returns undef,
> the description is taken from $project without any escaping.
>
>
>

^ permalink raw reply related

* Re: [PATCH] t4049: avoid test failures on filemode challenged file systems (Windows)
From: Junio C Hamano @ 2012-11-29 20:48 UTC (permalink / raw)
  To: Johannes Sixt; +Cc: git, Antoine Pelisse
In-Reply-To: <7vfw3sqoup.fsf@alter.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:

> Junio C Hamano <gitster@pobox.com> writes:
>> ...
>> The hunks in the patch look fine.  The last one that tests unmerged
>> entries do not have to have "chmod" if it gives you trouble (you
>> would need to reduce number of files from 4 to 3 if you go that
>> route, I think).
>
> That is, something like this.

I've tested this with the testpen set on vfat mounted on my Linux
box, i.e.

    $ cd t
    $ sh t4049-diff-stat-count.sh --root=/media/5599-553B/test -v
        
and it seems to work OK, so I'll be merging the topic with this
patch to 'master' later today.

Thanks for noticing.

> -- >8 --
> Subject: [PATCH] t4049: refocus tests
>
> The primary thing Linus's patch wanted to change was to make sure
> that 0-line change appears for a mode-only change.  Update the
> first test to chmod a file that we can see in the output (limited
> by --stat-count) to demonstrate it.  Also make sure to use test_chmod
> and compare the index and the tree, so that we can run this test
> even on a filesystem without permission bits.
>
> Later two tests are about fixes to separate issues that were
> introduced and/or uncovered by Linus's patch as a side effect, but
> the issues are not related to mode-only changes.  Remove chmod from
> the tests.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
>  t/t4049-diff-stat-count.sh | 20 +++++++++-----------
>  1 file changed, 9 insertions(+), 11 deletions(-)
>
> diff --git a/t/t4049-diff-stat-count.sh b/t/t4049-diff-stat-count.sh
> index 37f50cd..5b594e8 100755
> --- a/t/t4049-diff-stat-count.sh
> +++ b/t/t4049-diff-stat-count.sh
> @@ -13,32 +13,31 @@ test_expect_success 'setup' '
>  	git commit -m initial
>  '
>  
> -test_expect_success 'limit output to 2 (simple)' '
> +test_expect_success 'mode-only change show as a 0-line change' '
>  	git reset --hard &&
> -	chmod +x c d &&
> +	test_chmod +x b d &&
>  	echo a >a &&
> -	echo b >b &&
> +	echo c >c &&
>  	cat >expect <<-\EOF
>  	 a | 1 +
> -	 b | 1 +
> +	 b | 0
>  	 ...
>  	 4 files changed, 2 insertions(+)
>  	EOF
> -	git diff --stat --stat-count=2 >actual &&
> +	git diff --stat --stat-count=2 HEAD >actual &&
>  	test_i18ncmp expect actual
>  '
>  
>  test_expect_success 'binary changes do not count in lines' '
>  	git reset --hard &&
> -	chmod +x c d &&
>  	echo a >a &&
> -	echo b >b &&
> +	echo c >c &&
>  	cat "$TEST_DIRECTORY"/test-binary-1.png >d &&
>  	cat >expect <<-\EOF
>  	 a | 1 +
> -	 b | 1 +
> +	 c | 1 +
>  	 ...
> -	 4 files changed, 2 insertions(+)
> +	 3 files changed, 2 insertions(+)
>  	EOF
>  	git diff --stat --stat-count=2 >actual &&
>  	test_i18ncmp expect actual
> @@ -56,12 +55,11 @@ test_expect_success 'exclude unmerged entries from total file count' '
>  	done |
>  	git update-index --index-info &&
>  	echo d >d &&
> -	chmod +x c d &&
>  	cat >expect <<-\EOF
>  	 a | 1 +
>  	 b | 1 +
>  	 ...
> -	 4 files changed, 3 insertions(+)
> +	 3 files changed, 3 insertions(+)
>  	EOF
>  	git diff --stat --stat-count=2 >actual &&
>  	test_i18ncmp expect actual

^ permalink raw reply

* Re: Millisecond precision in timestamps?
From: Jeff King @ 2012-11-29 20:01 UTC (permalink / raw)
  To: Phil Hord
  Cc: Junio C Hamano, Shawn Pearce, Felipe Contreras, Eric Raymond, git
In-Reply-To: <CABURp0pnGYykud1xDn5T+eszQGTrzKLTp6J_O7ZrWwVd-zKpkg@mail.gmail.com>

On Thu, Nov 29, 2012 at 02:14:40PM -0500, Phil Hord wrote:

> > And if we were to add "committer-timestamp" and friends to support
> > negative timestamps anyway (because older tools will not support
> > them), supporting sub-second part might be something we want to
> > think about at the same time.
> 
> Posix-time is signed, but I suppose the git tools do not expect/allow
> a '-' character in the stream.  Has git considered the year-2038
> problem?

Yes. The timestamp is in base-10 ASCII, so there is no Y2038 problem in
the data format (it is up to the implementation to read it into a
sufficiently large time_t internally, of course[1]).

But negative timestamps are a different story. We use "unsigned long"
internally for timestamps, and fsck will complain about it.

-Peff

[1] We use "unsigned long", which means we are Y2038-fine on I32/LP64
    systems, but not on 32-bit or IL32/LLP64 systems. I do not use
    Windows, but my understanding is that LLP64 is the norm there, so it
    would eventually be a problem. But since we are unsigned, it is
    actually a Y2106 problem.

^ permalink raw reply

* Re: [PATCH 1/2 v3] git-fast-import.txt: improve documentation for quoted paths
From: Jeff King @ 2012-11-29 19:46 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Matthieu Moy, git
In-Reply-To: <7vr4ncp5kw.fsf@alter.siamese.dyndns.org>

On Thu, Nov 29, 2012 at 11:33:19AM -0800, Junio C Hamano wrote:

> > diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt
> > index 959e4d3..d1844ea 100644
> > --- a/Documentation/git-fast-import.txt
> > +++ b/Documentation/git-fast-import.txt
> > @@ -562,8 +562,12 @@ A `<path>` string must use UNIX-style directory separators (forward
> >  slash `/`), may contain any byte other than `LF`, and must not
> >  start with double quote (`"`).
> >  
> > -If an `LF` or double quote must be encoded into `<path>` shell-style
> > -quoting should be used, e.g. `"path/with\n and \" in it"`.
> > +A path can use C-style string quoting; this is accepted in all cases
> > +and mandatory if the filename starts with double quote or contains
> > +`LF`.
> 
> ... or backslash?

No, that was what we discussed elsewhere in the thread. It is OK to say:

  M 100644 :1 file \with \backslashes

as de-quoting is triggered by the first character being double-quote.

-Peff

^ permalink raw reply

* Re: [RFC/PATCH 1/2] reset: learn to reset to tree
From: Junio C Hamano @ 2012-11-29 19:36 UTC (permalink / raw)
  To: Martin von Zweigbergk; +Cc: git
In-Reply-To: <CANiSa6j2sriXaGr0yH9kMrxDEvKHsjNPX_Exbc2_6ecnPYdroQ@mail.gmail.com>

Martin von Zweigbergk <martinvonz@gmail.com> writes:

> Would the correct fix be to
> first make "git reset --hard -- $path" work (*sigh*)? I have never
> understood why that doesn't (shouldn't) work.

What does it even mean, even when you are on an existing commit, to
hard reset partially?

Perhaps you looking for "git checkout $tree -- $path"?

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox