threads / patch / 10839

patchAdd a test checking if send-pack updated local tracking branches correctly

Subject: [PATCH] Add a test checking if send-pack updated local tracking branches correctly

## tl;dr

22 messages between Nov 12, 2007 and Nov 15, 2007. Diffs are folded; open one to read it.

replies: 21people: 4as markdown or json

Alex Riesen· Nov 12, 2007, 21:38 UTC · lore
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
 t/t5404-tracking-branches.sh |   40 ++++++++++++++++++++++++++++++++++++++++
 1 files changed, 40 insertions(+), 0 deletions(-)
 create mode 100755 t/t5404-tracking-branches.sh
Show changes to t/t5404-tracking-branches.sh +40 −0
diff --git a/t/t5404-tracking-branches.sh b/t/t5404-tracking-branches.sh
new file mode 100755
index 0000000..20718d4
--- /dev/null
+++ b/t/t5404-tracking-branches.sh
@@ -0,0 +1,40 @@
+#!/bin/sh
+
+test_description='tracking branch update checks for git push'
+
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+	echo 1 >file &&
+	git add file &&
+	git commit -m 1 &&
+	git branch b1 &&
+	git branch b2 &&
+	git clone . aa &&
+	git checkout b1 &&
+	echo b1 >>file &&
+	git commit -a -m b1 &&
+	git checkout b2 &&
+	echo b2 >>file &&
+	git commit -a -m b2
+'
+
+test_expect_success 'check tracking branches updated correctly after push' '
+	cd aa &&
+	b1=$(git rev-parse origin/b1) &&
+	b2=$(git rev-parse origin/b2) &&
+	git checkout -b b1 origin/b1 &&
+	echo aa-b1 >>file &&
+	git commit -a -m aa-b1 &&
+	git checkout -b b2 origin/b2 &&
+	echo aa-b2 >>file &&
+	git commit -a -m aa-b2 &&
+	git checkout master &&
+	echo aa-master >>file &&
+	git commit -a -m aa-master &&
+	git push &&
+	test "$(git rev-parse origin/b1)" = "$b1" &&
+	test "$(git rev-parse origin/b2)" = "$b2"
+'
+
+test_done
-- 
1.5.3.5.648.g1e92c
Alex Riesen· Nov 12, 2007, 21:39 UTC · re: Alex Riesen · lore

[PATCH] Update the tracking references only if they were succesfully updated on remote

It fixes the bug where local tracing branches were filled with zeroed SHA-1 if the remote branch was not updated because, for instance, it was not an ancestor of the local (i.e. had other changes).

Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---

Jeff, I think your change (334f4831e5a77) was either not complete or got broken some time later.

 send-pack.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)
Show changes to send-pack.c +2 −1
diff --git a/send-pack.c b/send-pack.c
index b74fd45..d56d980 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -349,7 +349,8 @@ static int send_pack(int in, int out, struct remote *remote, int nr_refspec, cha
 
 	if (!dry_run && remote && ret == 0) {
 		for (ref = remote_refs; ref; ref = ref->next)
-			update_tracking_ref(remote, ref);
+			if (!is_null_sha1(ref->new_sha1))
+				update_tracking_ref(remote, ref);
 	}
 
 	if (!new_refs && ret == 0)
-- 
1.5.3.5.648.g1e92c
Jeff King· Nov 13, 2007, 07:52 UTC · re: Alex Riesen · lore

Re: [PATCH] Update the tracking references only if they were succesfully updated on remote

On Mon, Nov 12, 2007 at 10:39:38PM +0100, Alex Riesen wrote:
Show 9 quoted lines
> It fixes the bug where local tracing branches were filled with zeroed SHA-1
> if the remote branch was not updated because, for instance, it was not
> an ancestor of the local (i.e. had other changes).
> 
> Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
> ---
> 
> Jeff, I think your change (334f4831e5a77) was either not complete or
> got broken some time later.

Yes, some of the error information placed in 'ret' was getting lost. Daniel and I discussed some fixes, but haven't done a final patch yet. Your patch doesn't work because the assumption that is_null_sha1(refs->new_sha1) signals error is not correct. This is also the case for deleted refs, which means that we are failing to update tracking branches for successfully deleted refs.

I'd like to have a patch that accurately tracks per-ref errors, including ones from the remote. That not only will give us more accurate status reporting, but fixes like this will be much easier. Let me see if I can put something together.

-Peff
Alex Riesen· Nov 13, 2007, 19:47 UTC · re: Jeff King · lore

Re: [PATCH] Update the tracking references only if they were succesfully updated on remote

Jeff King, Tue, Nov 13, 2007 08:52:40 +0100:
Show 18 quoted lines
> On Mon, Nov 12, 2007 at 10:39:38PM +0100, Alex Riesen wrote:
> 
> > It fixes the bug where local tracing branches were filled with zeroed SHA-1
> > if the remote branch was not updated because, for instance, it was not
> > an ancestor of the local (i.e. had other changes).
> > 
> > Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
> > ---
> > 
> > Jeff, I think your change (334f4831e5a77) was either not complete or
> > got broken some time later.
> 
> Yes, some of the error information placed in 'ret' was getting lost.
> Daniel and I discussed some fixes, but haven't done a final patch yet.
> Your patch doesn't work because the assumption that
> is_null_sha1(refs->new_sha1) signals error is not correct. This is also
> the case for deleted refs, which means that we are failing to update
> tracking branches for successfully deleted refs.

Yep. I extended the test with this case, checking for deletion of the remote reference and its tracking reference. Will send it separetely. The mainline fails the second test, my patch the third (first being the test setup).

> I'd like to have a patch that accurately tracks per-ref errors,
> including ones from the remote. That not only will give us more accurate
> status reporting, but fixes like this will be much easier. Let me see if
> I can put something together.

I actually started almost like that: by placing an error bit in struct ref. But than it looked like new_sha1 was just not updated for not sent references, and the deleted ref are checked if their peer_ref->new_sha1 is null_sha1.

Date: Mon, 12 Nov 2007 17:09:24 +0100
Subject: [PATCH] Do not update the tracking references if they could not be updated on remote
---
 cache.h     |    5 +++--
 send-pack.c |   20 +++++++++++++-------
 2 files changed, 16 insertions(+), 9 deletions(-)
Show changes to 2 files +16 −9

cache.h, send-pack.c

diff --git a/cache.h b/cache.h
index f0a25c7..081b697 100644
--- a/cache.h
+++ b/cache.h
@@ -493,8 +493,9 @@ struct ref {
 	struct ref *next;
 	unsigned char old_sha1[20];
 	unsigned char new_sha1[20];
-	unsigned char force;
-	unsigned char merge;
+	unsigned char force:1;
+	unsigned char merge:1;
+	unsigned char failed:1;
 	struct ref *peer_ref; /* when renaming */
 	char name[FLEX_ARRAY]; /* more */
 };
diff --git a/send-pack.c b/send-pack.c
index b74fd45..c7a4c0e 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -196,8 +196,8 @@ static void update_tracking_ref(struct remote *remote, struct ref *ref)
 		return;
 
 	if (!remote_find_tracking(remote, &rs)) {
-		fprintf(stderr, "updating local tracking ref '%s'\n", rs.dst);
-		if (is_null_sha1(ref->peer_ref->new_sha1)) {
+		fprintf(stderr, "updating local tracking ref '%s' with %s\n", rs.dst, sha1_to_hex(ref->new_sha1));
+		if (is_null_sha1(ref->new_sha1)) {
 			if (delete_ref(rs.dst, NULL))
 				error("Failed to delete");
 		} else
@@ -211,6 +211,7 @@ static int send_pack(int in, int out, struct remote *remote, int nr_refspec, cha
 {
 	struct ref *ref;
 	int new_refs;
+#define REF_NOT_UPTODATE (-3)
 	int ret = 0;
 	int ask_for_status_report = 0;
 	int allow_deleting_refs = 0;
@@ -246,6 +247,7 @@ static int send_pack(int in, int out, struct remote *remote, int nr_refspec, cha
 	for (ref = remote_refs; ref; ref = ref->next) {
 		char old_hex[60], *new_hex;
 		int will_delete_ref;
+		ref->failed = 0;
 
 		if (!ref->peer_ref)
 			continue;
@@ -253,6 +255,7 @@ static int send_pack(int in, int out, struct remote *remote, int nr_refspec, cha
 
 		will_delete_ref = is_null_sha1(ref->peer_ref->new_sha1);
 		if (will_delete_ref && !allow_deleting_refs) {
+			ref->failed = 1;
 			error("remote does not support deleting refs");
 			ret = -2;
 			continue;
@@ -297,13 +300,12 @@ static int send_pack(int in, int out, struct remote *remote, int nr_refspec, cha
 				 * commits at the remote end and likely
 				 * we were not up to date to begin with.
 				 */
+				ref->failed = 1;
 				error("remote '%s' is not an ancestor of\n"
-				      " local  '%s'.\n"
-				      " Maybe you are not up-to-date and "
-				      "need to pull first?",
+				      " local  '%s'",
 				      ref->name,
 				      ref->peer_ref->name);
-				ret = -2;
+				ret = REF_NOT_UPTODATE;
 				continue;
 			}
 		}
@@ -337,6 +339,9 @@ static int send_pack(int in, int out, struct remote *remote, int nr_refspec, cha
 		}
 	}
 
+	if (ret == REF_NOT_UPTODATE)
+		fprintf(stderr, "\nMaybe you are not up-to-date and need to pull first?\n\n");
+
 	packet_flush(out);
 	if (new_refs && !dry_run)
 		ret = pack_objects(out, remote_refs);
@@ -349,7 +354,8 @@ static int send_pack(int in, int out, struct remote *remote, int nr_refspec, cha
 
 	if (!dry_run && remote && ret == 0) {
 		for (ref = remote_refs; ref; ref = ref->next)
-			update_tracking_ref(remote, ref);
+			if (!ref->failed)
+				update_tracking_ref(remote, ref);
 	}
 
 	if (!new_refs && ret == 0)
-- 
1.5.3.5.668.g22088
Alex Riesen· Nov 13, 2007, 19:49 UTC · re: Alex Riesen · lore

[PATCH] Add a test for deleting remote branches

Check if the tracking and the remote branches are both actually deleted.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
As promised.
 t/t5404-tracking-branches.sh |   16 ++++++++++++++++
 1 files changed, 16 insertions(+), 0 deletions(-)
Show changes to t/t5404-tracking-branches.sh +16 −0
diff --git a/t/t5404-tracking-branches.sh b/t/t5404-tracking-branches.sh
index 20718d4..f55143a 100755
--- a/t/t5404-tracking-branches.sh
+++ b/t/t5404-tracking-branches.sh
@@ -10,6 +10,7 @@ test_expect_success 'setup' '
 	git commit -m 1 &&
 	git branch b1 &&
 	git branch b2 &&
+	git branch b3 &&
 	git clone . aa &&
 	git checkout b1 &&
 	echo b1 >>file &&
@@ -19,6 +20,8 @@ test_expect_success 'setup' '
 	git commit -a -m b2
 '
 
+start_dir="$(pwd)"
+
 test_expect_success 'check tracking branches updated correctly after push' '
 	cd aa &&
 	b1=$(git rev-parse origin/b1) &&
@@ -37,4 +40,17 @@ test_expect_success 'check tracking branches updated correctly after push' '
 	test "$(git rev-parse origin/b2)" = "$b2"
 '
 
+test_expect_success 'delete remote branch' '
+	git push origin :refs/heads/b3 &&
+	{
+		git rev-parse origin/b3 --
+		test $? != 0
+        } &&
+	cd "$start_dir" &&
+	{
+		git rev-parse refs/heads/b3 --
+		test $? != 0
+        }
+'
+
 test_done
-- 
1.5.3.5.668.g22088
Alex Riesen· Nov 13, 2007, 23:02 UTC · re: Alex Riesen · lore

[PATCH] Improved and extended t5404

Ignore exit code of git push in t5404, as it is not relevant for the test: it already checks whether the references updated correctly.

Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---

This one is on top of what is in next. It also include the check for deleting remote braches I sent before. Regarding this one: if a remote branch is deleted, shouldn't the matching tracking branch be removed as well? The code in master seem to do that.

 t/t5404-tracking-branches.sh |   29 ++++++++++++++++++++++++++---
 1 files changed, 26 insertions(+), 3 deletions(-)
Show changes to t/t5404-tracking-branches.sh +26 −3
diff --git a/t/t5404-tracking-branches.sh b/t/t5404-tracking-branches.sh
index 20718d4..a51bbdc 100755
--- a/t/t5404-tracking-branches.sh
+++ b/t/t5404-tracking-branches.sh
@@ -10,6 +10,7 @@ test_expect_success 'setup' '
 	git commit -m 1 &&
 	git branch b1 &&
 	git branch b2 &&
+	git branch b3 &&
 	git clone . aa &&
 	git checkout b1 &&
 	echo b1 >>file &&
@@ -19,10 +20,13 @@ test_expect_success 'setup' '
 	git commit -a -m b2
 '
 
+start_dir="$(pwd)"
+
 test_expect_success 'check tracking branches updated correctly after push' '
 	cd aa &&
 	b1=$(git rev-parse origin/b1) &&
 	b2=$(git rev-parse origin/b2) &&
+	b3=$(git rev-parse origin/b3) &&
 	git checkout -b b1 origin/b1 &&
 	echo aa-b1 >>file &&
 	git commit -a -m aa-b1 &&
@@ -32,9 +36,28 @@ test_expect_success 'check tracking branches updated correctly after push' '
 	git checkout master &&
 	echo aa-master >>file &&
 	git commit -a -m aa-master &&
-	git push &&
-	test "$(git rev-parse origin/b1)" = "$b1" &&
-	test "$(git rev-parse origin/b2)" = "$b2"
+	{
+		git push
+		test "$(git rev-parse origin/b1)" = "$b1" &&
+		test "$(git rev-parse origin/b2)" = "$b2" &&
+		test "$(git rev-parse origin/b3)" = "$b3" &&
+		test "$(git rev-parse origin/master)" = \
+		"$(git rev-parse master)"
+	}
+'
+
+test_expect_success 'delete remote branch' '
+	git push origin :refs/heads/b3
+	{
+		git rev-parse origin/b3
+		test $? != 0 || \
+		say "Hmm... Maybe tracking ref should be deleted?"
+        } &&
+	cd "$start_dir" &&
+	{
+		git rev-parse refs/heads/b3
+		test $? != 0
+        }
 '
 
 test_done
Jeff King· Nov 13, 2007, 23:10 UTC · re: Alex Riesen · lore

Re: [PATCH] Improved and extended t5404

On Wed, Nov 14, 2007 at 12:02:34AM +0100, Alex Riesen wrote:
> This one is on top of what is in next. It also include the check for
> deleting remote braches I sent before. Regarding this one: if a remote
> branch is deleted, shouldn't the matching tracking branch be removed
> as well? The code in master seem to do that.

Yes, it should (the code in update_tracking_ref seems to handle that case, but I haven't tested, so I may have bungled something). I am literally walking out the door, now, though, so I will be out of touch for at least a day.

-Peff
Jeff King· Nov 15, 2007, 04:26 UTC · re: Jeff King · lore

Re: [PATCH] Improved and extended t5404

On Tue, Nov 13, 2007 at 06:10:48PM -0500, Jeff King wrote:
Show 9 quoted lines
> > This one is on top of what is in next. It also include the check for
> > deleting remote braches I sent before. Regarding this one: if a remote
> > branch is deleted, shouldn't the matching tracking branch be removed
> > as well? The code in master seem to do that.
> 
> Yes, it should (the code in update_tracking_ref seems to handle that
> case, but I haven't tested, so I may have bungled something). I am
> literally walking out the door, now, though, so I will be out of touch
> for at least a day.

After I became disconnected, I looked at my 'next', and the reason for the failure to delete the ref seems to be your is_null_sha1 error-checking patch, which Junio put in next. But maybe you have figured that out in the intervening time. :)

-Peff
Alex Riesen· Nov 15, 2007, 20:46 UTC · re: Jeff King · lore

[PATCH] Add test that checks diverse aspects of updating remote and tracking branches

Because we haven't settled on what the exit status from "git push" command itself should be in such a partial failure case, do not check the exit status from it for now.

Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
Jeff King, Thu, Nov 15, 2007 05:26:26 +0100:
Show 16 quoted lines
> On Tue, Nov 13, 2007 at 06:10:48PM -0500, Jeff King wrote:
> 
> > > This one is on top of what is in next. It also include the check for
> > > deleting remote braches I sent before. Regarding this one: if a remote
> > > branch is deleted, shouldn't the matching tracking branch be removed
> > > as well? The code in master seem to do that.
> > 
> > Yes, it should (the code in update_tracking_ref seems to handle that
> > case, but I haven't tested, so I may have bungled something). I am
> > literally walking out the door, now, though, so I will be out of touch
> > for at least a day.
> 
> After I became disconnected, I looked at my 'next', and the reason for
> the failure to delete the ref seems to be your is_null_sha1
> error-checking patch, which Junio put in next. But maybe you have
> figured that out in the intervening time. :)

I didn't. But Junio already has all your patches in pu, so I activated the deletion test and rebased it on top of your patches in his tree (jk/send-pack, according to merge commit). Tried: works.

 t/t5404-tracking-branches.sh |   28 +++++++++++++++++++++++++---
 1 files changed, 25 insertions(+), 3 deletions(-)
Show changes to t/t5404-tracking-branches.sh +25 −3
diff --git a/t/t5404-tracking-branches.sh b/t/t5404-tracking-branches.sh
index 20718d4..a6f60ac 100755
--- a/t/t5404-tracking-branches.sh
+++ b/t/t5404-tracking-branches.sh
@@ -10,6 +10,7 @@ test_expect_success 'setup' '
 	git commit -m 1 &&
 	git branch b1 &&
 	git branch b2 &&
+	git branch b3 &&
 	git clone . aa &&
 	git checkout b1 &&
 	echo b1 >>file &&
@@ -19,10 +20,13 @@ test_expect_success 'setup' '
 	git commit -a -m b2
 '
 
+start_dir="$(pwd)"
+
 test_expect_success 'check tracking branches updated correctly after push' '
 	cd aa &&
 	b1=$(git rev-parse origin/b1) &&
 	b2=$(git rev-parse origin/b2) &&
+	b3=$(git rev-parse origin/b3) &&
 	git checkout -b b1 origin/b1 &&
 	echo aa-b1 >>file &&
 	git commit -a -m aa-b1 &&
@@ -32,9 +36,27 @@ test_expect_success 'check tracking branches updated correctly after push' '
 	git checkout master &&
 	echo aa-master >>file &&
 	git commit -a -m aa-master &&
-	git push &&
-	test "$(git rev-parse origin/b1)" = "$b1" &&
-	test "$(git rev-parse origin/b2)" = "$b2"
+	{
+		git push
+		test "$(git rev-parse origin/b1)" = "$b1" &&
+		test "$(git rev-parse origin/b2)" = "$b2" &&
+		test "$(git rev-parse origin/b3)" = "$b3" &&
+		test "$(git rev-parse origin/master)" = \
+		"$(git rev-parse master)"
+	}
+'
+
+test_expect_success 'delete remote branch' '
+	git push origin :refs/heads/b3
+	{
+		git rev-parse --verify origin/b3
+		test $? != 0
+        } &&
+	cd "$start_dir" &&
+	{
+		git rev-parse refs/heads/b3
+		test $? != 0
+        }
 '
 
 test_done
-- 
1.5.3.5.692.ge1737
Junio C Hamano· Nov 14, 2007, 00:02 UTC · re: Alex Riesen · lore

Re: [PATCH] Improved and extended t5404

Alex Riesen <raa.lkml@gmail.com> writes:
> Ignore exit code of git push in t5404, as it is not relevant for the
> test

This proposed log message solicits a "Huh? -- Since when ignoring exit code is an improvement?" reaction. If this push is expected to error out, then wouldn't you want to make sure it errors out as expected? If the problem is that the exit status is unreliable, maybe we need to make it reliable instead?

Alex Riesen· Nov 14, 2007, 07:19 UTC · re: Junio C Hamano · lore

Re: [PATCH] Improved and extended t5404

Junio C Hamano, Wed, Nov 14, 2007 01:02:20 +0100:
Show 10 quoted lines
> Alex Riesen <raa.lkml@gmail.com> writes:
> 
> > Ignore exit code of git push in t5404, as it is not relevant for the
> > test
> 
> This proposed log message solicits a "Huh? -- Since when
> ignoring exit code is an improvement?" reaction.  If this push
> is expected to error out, then wouldn't you want to make sure it
> errors out as expected?  If the problem is that the exit status
> is unreliable, maybe we need to make it reliable instead?

Well, it is kind of undefined. git push just updated some remote references and failed on the others. It has had some failures, so it returns non-0. And as I said, it really is not about the operation, but about if the tracking and remote branches are set as we want them.

Junio C Hamano· Nov 14, 2007, 08:47 UTC · re: Alex Riesen · lore

Re: [PATCH] Improved and extended t5404

Alex Riesen <raa.lkml@gmail.com> writes:
Show 16 quoted lines
> Junio C Hamano, Wed, Nov 14, 2007 01:02:20 +0100:
>> Alex Riesen <raa.lkml@gmail.com> writes:
>> 
>> > Ignore exit code of git push in t5404, as it is not relevant for the
>> > test
>> 
>> This proposed log message solicits a "Huh? -- Since when
>> ignoring exit code is an improvement?" reaction.  If this push
>> is expected to error out, then wouldn't you want to make sure it
>> errors out as expected?  If the problem is that the exit status
>> is unreliable, maybe we need to make it reliable instead?
>
> Well, it is kind of undefined. git push just updated some remote
> references and failed on the others. It has had some failures, so it
> returns non-0. And as I said, it really is not about the operation,
> but about if the tracking and remote branches are set as we want them.

Ok, I guess the proposed log message was not clear enough, at least for me.

Will apply.
Johannes Schindelin· Nov 14, 2007, 17:10 UTC · re: Alex Riesen · lore

Re: [PATCH] Improved and extended t5404

Hi,
On Wed, 14 Nov 2007, Alex Riesen wrote:
Show 16 quoted lines
> Junio C Hamano, Wed, Nov 14, 2007 01:02:20 +0100:
> > Alex Riesen <raa.lkml@gmail.com> writes:
> > 
> > > Ignore exit code of git push in t5404, as it is not relevant for the 
> > > test
> > 
> > This proposed log message solicits a "Huh? -- Since when ignoring exit 
> > code is an improvement?" reaction.  If this push is expected to error 
> > out, then wouldn't you want to make sure it errors out as expected?  
> > If the problem is that the exit status is unreliable, maybe we need to 
> > make it reliable instead?
> 
> Well, it is kind of undefined. git push just updated some remote 
> references and failed on the others. It has had some failures, so it 
> returns non-0. And as I said, it really is not about the operation, but 
> about if the tracking and remote branches are set as we want them.

If you know it should fail, why not make the test dependent on that failure? I mean, should git-push have a bug and not fail, it would be nice to catch this early...

Ciao, Dscho

Alex Riesen· Nov 14, 2007, 19:45 UTC · re: Johannes Schindelin · lore

Re: [PATCH] Improved and extended t5404

Johannes Schindelin, Wed, Nov 14, 2007 18:10:25 +0100:
Show 22 quoted lines
> On Wed, 14 Nov 2007, Alex Riesen wrote:
> > Junio C Hamano, Wed, Nov 14, 2007 01:02:20 +0100:
> > > Alex Riesen <raa.lkml@gmail.com> writes:
> > > 
> > > > Ignore exit code of git push in t5404, as it is not relevant for the 
> > > > test
> > > 
> > > This proposed log message solicits a "Huh? -- Since when ignoring exit 
> > > code is an improvement?" reaction.  If this push is expected to error 
> > > out, then wouldn't you want to make sure it errors out as expected?  
> > > If the problem is that the exit status is unreliable, maybe we need to 
> > > make it reliable instead?
> > 
> > Well, it is kind of undefined. git push just updated some remote 
> > references and failed on the others. It has had some failures, so it 
> > returns non-0. And as I said, it really is not about the operation, but 
> > about if the tracking and remote branches are set as we want them.
> 
> If you know it should fail, why not make the test dependent on that 
> failure?  I mean, should git-push have a bug and not fail, it would be 
> nice to catch this early...
> 

Well, I do not know it _should_ fail. Personally, I would not even care: I see no way to cover with just one exit code multiple failures. Some references were updated and I don't even know which. So I'd better check whatever exit code.

Alex Riesen· Nov 14, 2007, 20:34 UTC · re: Alex Riesen · lore

Re: [PATCH] Improved and extended t5404

Alex Riesen, Wed, Nov 14, 2007 20:45:22 +0100:
Show 28 quoted lines
> Johannes Schindelin, Wed, Nov 14, 2007 18:10:25 +0100:
> > On Wed, 14 Nov 2007, Alex Riesen wrote:
> > > Junio C Hamano, Wed, Nov 14, 2007 01:02:20 +0100:
> > > > Alex Riesen <raa.lkml@gmail.com> writes:
> > > > 
> > > > > Ignore exit code of git push in t5404, as it is not relevant for the 
> > > > > test
> > > > 
> > > > This proposed log message solicits a "Huh? -- Since when ignoring exit 
> > > > code is an improvement?" reaction.  If this push is expected to error 
> > > > out, then wouldn't you want to make sure it errors out as expected?  
> > > > If the problem is that the exit status is unreliable, maybe we need to 
> > > > make it reliable instead?
> > > 
> > > Well, it is kind of undefined. git push just updated some remote 
> > > references and failed on the others. It has had some failures, so it 
> > > returns non-0. And as I said, it really is not about the operation, but 
> > > about if the tracking and remote branches are set as we want them.
> > 
> > If you know it should fail, why not make the test dependent on that 
> > failure?  I mean, should git-push have a bug and not fail, it would be 
> > nice to catch this early...
> > 
> 
> Well, I do not know it _should_ fail. Personally, I would not even
> care: I see no way to cover with just one exit code multiple
> failures. Some references were updated and I don't even know which.
> So I'd better check whatever exit code.
"I'd better check whatever was updated and damn the exit code"
Johannes Schindelin· Nov 14, 2007, 22:01 UTC · re: Alex Riesen · lore

Re: [PATCH] Improved and extended t5404

Hi,
On Wed, 14 Nov 2007, Alex Riesen wrote:
Show 8 quoted lines
> Alex Riesen, Wed, Nov 14, 2007 20:45:22 +0100:
>
> > Well, I do not know it _should_ fail. Personally, I would not even 
> > care: I see no way to cover with just one exit code multiple failures. 
> > Some references were updated and I don't even know which. So I'd 
> > better check whatever exit code.
> 
> "I'd better check whatever was updated and damn the exit code"

My point was: why not check both? I mean, you know if it fails in your case. Better to test for this behaviour, than to have it succeed here, but fail there.

It's really easy, too: if it does not succeed, it fails. Just test for it.

Ciao, Dscho "consistency is good"

Jeff King· Nov 15, 2007, 04:18 UTC · re: Alex Riesen · lore

Re: [PATCH] Improved and extended t5404

On Wed, Nov 14, 2007 at 08:19:29AM +0100, Alex Riesen wrote:
> Well, it is kind of undefined. git push just updated some remote
> references and failed on the others. It has had some failures, so it
> returns non-0. And as I said, it really is not about the operation,
> but about if the tracking and remote branches are set as we want them.

My goal with the recent patches is that _any_ failure will cause a non-0 exit code (but you have to read the stderr output to find out which, if any, refs were successful).

-Peff
Jeff King· Nov 15, 2007, 04:35 UTC · re: Jeff King · lore

Re: [PATCH] Improved and extended t5404

On Wed, Nov 14, 2007 at 11:18:01PM -0500, Jeff King wrote:
> My goal with the recent patches is that _any_ failure will cause a non-0
> exit code (but you have to read the stderr output to find out which, if
> any, refs were successful).

BTW, since there seems to be some debate on how this _should_ work, I think the "signal failure if anything failed" approach is the better.

Why?

Because either way you do it, there is an ambiguity, and I would rather that ambiguity lie with the "failure" case. If I see exit code '0', I _know_ that all of my refs were updated. If I see exit code '1', then there was some failure detected, but my refs might or might not have been updated. But that ambiguity _already_ exists. Consider the case where we send refs, but the connection dies in the middle. We have to signal error, then, but for all we know the other side was about to "successfully updated all refs". So you can only ever _know_ success, and with failure, you simply guess (and presumably retry).

-Peff
Junio C Hamano· Nov 15, 2007, 05:55 UTC · re: Jeff King · lore

Re: [PATCH] Improved and extended t5404

Jeff King <peff@peff.net> writes:
> ... So you can only ever _know_ success,
> and with failure, you simply guess (and presumably retry).
Good thinking.  I agree.
Junio C Hamano· Nov 14, 2007, 21:52 UTC · re: Alex Riesen · lore

Re: [PATCH] Improved and extended t5404

Alex Riesen <raa.lkml@gmail.com> writes:
> Ignore exit code of git push in t5404, as it is not relevant for the
> test: it already checks whether the references updated correctly.
I think the Subject: goes a lot better with a description like this:
	Add test that checks the case where X does Y and make
	sure Z happens.
	Because we haven't settled on what the exit status from
	"git push" command itself should be in such a partial
	failure case, do not check the exit status from it for
	now.
Show 12 quoted lines
> diff --git a/t/t5404-tracking-branches.sh b/t/t5404-tracking-branches.sh
> index 20718d4..a51bbdc 100755
> --- a/t/t5404-tracking-branches.sh
> +++ b/t/t5404-tracking-branches.sh
> @@ -10,6 +10,7 @@ test_expect_success 'setup' '
>  	git commit -m 1 &&
>  	git branch b1 &&
>  	git branch b2 &&
> +	git branch b3 &&
>  	git clone . aa &&
>  	git checkout b1 &&
> ...
So it makes another ref "b3" point at the initial commit,... 
Show 9 quoted lines
> ...
>  test_expect_success 'check tracking branches updated correctly after push' '
>  	cd aa &&
>  	b1=$(git rev-parse origin/b1) &&
>  	b2=$(git rev-parse origin/b2) &&
> +	b3=$(git rev-parse origin/b3) &&
>  	git checkout -b b1 origin/b1 &&
>  	echo aa-b1 >>file &&
>  	git commit -a -m aa-b1 &&
... then records what was cloned,...
Show 13 quoted lines
> @@ -32,9 +36,28 @@ test_expect_success 'check tracking branches updated correctly after push' '
>  	git checkout master &&
>  	echo aa-master >>file &&
>  	git commit -a -m aa-master &&
> +	{
> +		git push
> +		test "$(git rev-parse origin/b1)" = "$b1" &&
> +		test "$(git rev-parse origin/b2)" = "$b2" &&
> +		test "$(git rev-parse origin/b3)" = "$b3" &&
> +		test "$(git rev-parse origin/master)" = \
> +		"$(git rev-parse master)"
> +	}
> +'

... and checks that untouched "b3" stays the same (iow, tests up-to-date case).

Show 8 quoted lines
> +
> +test_expect_success 'delete remote branch' '
> +	git push origin :refs/heads/b3
> +	{
> +		git rev-parse origin/b3
> +		test $? != 0 || \
> +		say "Hmm... Maybe tracking ref should be deleted?"
> +        } &&

Ah, you meant that tracking should be deleted so this should be fixed in the code but the test is disabled for now. Let's be a bit more explicit about such a temporary disabled test, like this:

	git push origin :refs/heads/b3
	# The remote-tracking branch origin/b3 should be deleted;
        # we need to update the code and enable this test.
        : git rev-parse --verify origin/b3 &&
Show 6 quoted lines
> +	cd "$start_dir" &&
> +	{
> +		git rev-parse refs/heads/b3
> +		test $? != 0
> +        }
>  '
Alex Riesen· Nov 14, 2007, 22:49 UTC · re: Junio C Hamano · lore

[PATCH] Add test that checks diverse aspects of updating remote and tracking branches

Because we haven't settled on what the exit status from "git push" command itself should be in such a partial failure case, do not check the exit status from it for now.

Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
Junio C Hamano, Wed, Nov 14, 2007 22:52:19 +0100:
Show 9 quoted lines
> Alex Riesen <raa.lkml@gmail.com> writes:
> 
> > Ignore exit code of git push in t5404, as it is not relevant for the
> > test: it already checks whether the references updated correctly.
> 
> I think the Subject: goes a lot better with a description like this:
> 
> 	Add test that checks the case where X does Y and make
> 	sure Z happens.

Add test that checks diverse aspects of updating remote and tracking branches.

> 	Because we haven't settled on what the exit status from
> 	"git push" command itself should be in such a partial
> 	failure case, do not check the exit status from it for
> 	now.
This I'll leave as is.
> > +	git branch b3 &&
> 
> So it makes another ref "b3" point at the initial commit,... 
Right
> > +	b3=$(git rev-parse origin/b3) &&
> 
> ... then records what was cloned,...
Precisely
> > +		test "$(git rev-parse origin/b3)" = "$b3" &&
> 
> ... and checks that untouched "b3" stays the same (iow, tests
> up-to-date case).
Yep.
Show 19 quoted lines
> > +
> > +test_expect_success 'delete remote branch' '
> > +	git push origin :refs/heads/b3
> > +	{
> > +		git rev-parse origin/b3
> > +		test $? != 0 || \
> > +		say "Hmm... Maybe tracking ref should be deleted?"
> > +        } &&
> 
> Ah, you meant that tracking should be deleted so this should be
> fixed in the code but the test is disabled for now.  Let's be a
> bit more explicit about such a temporary disabled test, like
> this:
> 
> 	git push origin :refs/heads/b3
> 
> 	# The remote-tracking branch origin/b3 should be deleted;
>         # we need to update the code and enable this test.
>         : git rev-parse --verify origin/b3 &&

Nice, will take this. Except we have to check for absence of the tracking branch. git-rev-parse must fail.

 t/t5404-tracking-branches.sh |   64 ++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 64 insertions(+), 0 deletions(-)
 create mode 100755 t/t5404-tracking-branches.sh
Show changes to t/t5404-tracking-branches.sh +64 −0
diff --git a/t/t5404-tracking-branches.sh b/t/t5404-tracking-branches.sh
new file mode 100755
index 0000000..d861a14
--- /dev/null
+++ b/t/t5404-tracking-branches.sh
@@ -0,0 +1,64 @@
+#!/bin/sh
+
+test_description='tracking branch update checks for git push'
+
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+	echo 1 >file &&
+	git add file &&
+	git commit -m 1 &&
+	git branch b1 &&
+	git branch b2 &&
+	git branch b3 &&
+	git clone . aa &&
+	git checkout b1 &&
+	echo b1 >>file &&
+	git commit -a -m b1 &&
+	git checkout b2 &&
+	echo b2 >>file &&
+	git commit -a -m b2
+'
+
+start_dir="$(pwd)"
+
+test_expect_success 'check tracking branches updated correctly after push' '
+	cd aa &&
+	b1=$(git rev-parse origin/b1) &&
+	b2=$(git rev-parse origin/b2) &&
+	b3=$(git rev-parse origin/b3) &&
+	git checkout -b b1 origin/b1 &&
+	echo aa-b1 >>file &&
+	git commit -a -m aa-b1 &&
+	git checkout -b b2 origin/b2 &&
+	echo aa-b2 >>file &&
+	git commit -a -m aa-b2 &&
+	git checkout master &&
+	echo aa-master >>file &&
+	git commit -a -m aa-master &&
+	{
+		git push
+		test "$(git rev-parse origin/b1)" = "$b1" &&
+		test "$(git rev-parse origin/b2)" = "$b2" &&
+		test "$(git rev-parse origin/b3)" = "$b3" &&
+		test "$(git rev-parse origin/master)" = \
+		"$(git rev-parse master)"
+	}
+'
+
+test_expect_success 'delete remote branch' '
+	git push origin :refs/heads/b3
+	{
+	# The remote-tracking branch origin/b3 should be deleted;
+	# we need to update the code and enable this test.
+		: git rev-parse --verify origin/b3
+		: test $? != 0
+        } &&
+	cd "$start_dir" &&
+	{
+		git rev-parse refs/heads/b3
+		test $? != 0
+        }
+'
+
+test_done
-- 
1.5.3.5.692.ge1737
Junio C Hamano· Nov 14, 2007, 21:52 UTC · re: Alex Riesen · lore

Re: [PATCH] Improved and extended t5404

Alex Riesen <raa.lkml@gmail.com> writes:
> Ignore exit code of git push in t5404, as it is not relevant for the
> test: it already checks whether the references updated correctly.
I think the Subject: goes a lot better with a description like this:
	Enhance the test to check the case where X does Y and to
	make sure Z happens.
	Because we haven't settled on what the exit status from
	"git push" command itself should be in such a partial
	failure case, do not check the exit status from it for
	now.
Show 12 quoted lines
> diff --git a/t/t5404-tracking-branches.sh b/t/t5404-tracking-branches.sh
> index 20718d4..a51bbdc 100755
> --- a/t/t5404-tracking-branches.sh
> +++ b/t/t5404-tracking-branches.sh
> @@ -10,6 +10,7 @@ test_expect_success 'setup' '
>  	git commit -m 1 &&
>  	git branch b1 &&
>  	git branch b2 &&
> +	git branch b3 &&
>  	git clone . aa &&
>  	git checkout b1 &&
> ...
So it makes another ref "b3" point at the initial commit,... 
Show 9 quoted lines
> ...
>  test_expect_success 'check tracking branches updated correctly after push' '
>  	cd aa &&
>  	b1=$(git rev-parse origin/b1) &&
>  	b2=$(git rev-parse origin/b2) &&
> +	b3=$(git rev-parse origin/b3) &&
>  	git checkout -b b1 origin/b1 &&
>  	echo aa-b1 >>file &&
>  	git commit -a -m aa-b1 &&
... then records what was cloned,...
Show 13 quoted lines
> @@ -32,9 +36,28 @@ test_expect_success 'check tracking branches updated correctly after push' '
>  	git checkout master &&
>  	echo aa-master >>file &&
>  	git commit -a -m aa-master &&
> +	{
> +		git push
> +		test "$(git rev-parse origin/b1)" = "$b1" &&
> +		test "$(git rev-parse origin/b2)" = "$b2" &&
> +		test "$(git rev-parse origin/b3)" = "$b3" &&
> +		test "$(git rev-parse origin/master)" = \
> +		"$(git rev-parse master)"
> +	}
> +'

... and checks that untouched "b3" stays the same (iow, tests up-to-date case).

Show 8 quoted lines
> +
> +test_expect_success 'delete remote branch' '
> +	git push origin :refs/heads/b3
> +	{
> +		git rev-parse origin/b3
> +		test $? != 0 || \
> +		say "Hmm... Maybe tracking ref should be deleted?"
> +        } &&

Ah, you meant that tracking should be deleted so this should be fixed in the code but the test is disabled for now. Let's be a bit more explicit about such a temporary disabled test, like this:

	git push origin :refs/heads/b3
	# The remote-tracking branch origin/b3 should be deleted;
        # we need to update the code and enable this test.
        : git rev-parse --verify origin/b3 &&
Show 6 quoted lines
> +	cd "$start_dir" &&
> +	{
> +		git rev-parse refs/heads/b3
> +		test $? != 0
> +        }
>  '

← back to recent threads