threads / patch / 24375

patch, 2 partsrevert: refactor code that prints success or failure message

Subject: [PATCH 1/2] revert: refactor code that prints success or failure message

## tl;dr

7 messages between Jul 12, 2010 and Jul 15, 2010. Diffs are folded; open one to read it.

replies: 6people: 3as markdown or json

Christian Couder· Jul 12, 2010, 11:54 UTC · lore

This patch refactors the code that prints a message like "Automatic cherry-pick failed. <help message>". This code was duplicated in both do_recursive_merge() and do_pick_commit().

To do that, now do_recursive_merge() returns an int to signal success or failure. And in case of failure we just return 1 from do_pick_commit() instead of doing "exit(1)" from either do_recursive_merge() or do_pick_commit().

In case of successful merge, do_recursive_merge() used to print something like "Finished one cherry-pick." but nothing was printed in case a special strategy like "resolve" was used. Now in this case a message like "Finished one cherry-pick with strategy resolve." is printed.

So the command behavior should be more consistent wether we are using a special strategy or not.

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
	I also wonder why messages like "Finished one cherry-pick."
	are printed on stderr instead of stdout.
	Maybe this could be changed in this patch or in
	another one.
	And while at making a backward incompatible change, maybe
	we could change the message to something like:
	"Finished cherry-pick <sha1>"
 builtin/revert.c                    |   51 ++++++++++++++++++++---------------
 t/t3508-cherry-pick-many-commits.sh |   26 +++++++++++++++++-
 2 files changed, 54 insertions(+), 23 deletions(-)
Show changes to 2 files +54 −23

builtin/revert.c, t/t3508-cherry-pick-many-commits.sh

diff --git a/builtin/revert.c b/builtin/revert.c
index 8b9d829..b082bb4 100644
--- a/builtin/revert.c
+++ b/builtin/revert.c
@@ -311,10 +311,9 @@ static int fast_forward_to(const unsigned char *to, const unsigned char *from)
 	return write_ref_sha1(ref_lock, to, "cherry-pick");
 }
 
-static void do_recursive_merge(struct commit *base, struct commit *next,
-			       const char *base_label, const char *next_label,
-			       unsigned char *head, struct strbuf *msgbuf,
-			       char *defmsg)
+static int do_recursive_merge(struct commit *base, struct commit *next,
+			      const char *base_label, const char *next_label,
+			      unsigned char *head, struct strbuf *msgbuf)
 {
 	struct merge_options o;
 	struct tree *result, *next_tree, *base_tree, *head_tree;
@@ -357,14 +356,9 @@ static void do_recursive_merge(struct commit *base, struct commit *next,
 					i++;
 			}
 		}
-		write_message(msgbuf, defmsg);
-		fprintf(stderr, "Automatic %s failed.%s\n",
-			me, help_msg());
-		rerere(allow_rerere_auto);
-		exit(1);
 	}
-	write_message(msgbuf, defmsg);
-	fprintf(stderr, "Finished one %s.\n", me);
+
+	return !clean;
 }
 
 static int do_pick_commit(void)
@@ -375,6 +369,8 @@ static int do_pick_commit(void)
 	struct commit_message msg = { NULL, NULL, NULL, NULL, NULL };
 	char *defmsg = NULL;
 	struct strbuf msgbuf = STRBUF_INIT;
+	struct strbuf mebuf = STRBUF_INIT;
+	int res;
 
 	if (no_commit) {
 		/*
@@ -470,30 +466,41 @@ static int do_pick_commit(void)
 		}
 	}
 
-	if (!strategy || !strcmp(strategy, "recursive") || action == REVERT)
-		do_recursive_merge(base, next, base_label, next_label,
-				   head, &msgbuf, defmsg);
-	else {
-		int res;
+	strbuf_addstr(&mebuf, me);
+
+	if (!strategy || !strcmp(strategy, "recursive") || action == REVERT) {
+		res = do_recursive_merge(base, next, base_label, next_label,
+					 head, &msgbuf);
+		write_message(&msgbuf, defmsg);
+	} else {
 		struct commit_list *common = NULL;
 		struct commit_list *remotes = NULL;
+
+		strbuf_addf(&mebuf, " with strategy %s", strategy);
 		write_message(&msgbuf, defmsg);
+
 		commit_list_insert(base, &common);
 		commit_list_insert(next, &remotes);
 		res = try_merge_command(strategy, common,
 					sha1_to_hex(head), remotes);
 		free_commit_list(common);
 		free_commit_list(remotes);
-		if (res) {
-			fprintf(stderr, "Automatic %s with strategy %s failed.%s\n",
-				me, strategy, help_msg());
-			rerere(allow_rerere_auto);
-			exit(1);
-		}
 	}
 
+	if (res) {
+		fprintf(stderr, "Automatic %s failed.%s\n",
+			mebuf.buf, help_msg());
+		rerere(allow_rerere_auto);
+	} else {
+		fprintf(stderr, "Finished one %s.\n", mebuf.buf);
+	}
+
+	strbuf_release(&mebuf);
 	free_message(&msg);
 
+	if (res)
+		return 1;
+
 	/*
 	 *
 	 * If we are cherry-pick, and if the merge did not result in
diff --git a/t/t3508-cherry-pick-many-commits.sh b/t/t3508-cherry-pick-many-commits.sh
index f90ed3d..6555f92 100755
--- a/t/t3508-cherry-pick-many-commits.sh
+++ b/t/t3508-cherry-pick-many-commits.sh
@@ -23,12 +23,36 @@ test_expect_success setup '
 '
 
 test_expect_success 'cherry-pick first..fourth works' '
+	cat <<-EOF > expected &&
+	Finished one cherry-pick.
+	Finished one cherry-pick.
+	Finished one cherry-pick.
+	EOF
+
+	git checkout -f master &&
+	git reset --hard first &&
+	test_tick &&
+	git cherry-pick first..fourth 2>actual &&
+	git diff --quiet other &&
+	git diff --quiet HEAD other &&
+	test_cmp expected actual &&
+	test "$(git rev-parse --verify HEAD)" != "$(git rev-parse --verify fourth)"
+'
+
+test_expect_success 'cherry-pick --strategy resolve first..fourth works' '
+	cat <<-EOF > expected &&
+	Finished one cherry-pick with strategy resolve.
+	Finished one cherry-pick with strategy resolve.
+	Finished one cherry-pick with strategy resolve.
+	EOF
+
 	git checkout -f master &&
 	git reset --hard first &&
 	test_tick &&
-	git cherry-pick first..fourth &&
+	git cherry-pick --strategy resolve first..fourth 2>actual &&
 	git diff --quiet other &&
 	git diff --quiet HEAD other &&
+	test_cmp expected actual &&
 	test "$(git rev-parse --verify HEAD)" != "$(git rev-parse --verify fourth)"
 '
 
-- 
1.7.2.rc1.213.gf3fb81
Jonathan Nieder· Jul 12, 2010, 16:30 UTC · re: Christian Couder · lore

Re: [PATCH 1/2] revert: refactor code that prints success or failure message

Hi,
Christian Couder wrote:
> This patch refactors the code that prints a message like
> "Automatic cherry-pick failed. <help message>".

From the point of view of refactoring, it does not seem so promising: the patch adds more code than it removes.

 $ git diff --numstat HEAD^
 29	22	builtin/revert.c
 25	 1	t/t3508-cherry-pick-many-commits.sh
So I am hoping there is some other reason.
> To do that, now do_recursive_merge() returns an int to signal
> success or failure. And in case of failure we just return 1
> from do_pick_commit() instead of doing "exit(1)" from either
> do_recursive_merge() or do_pick_commit().
This part sounds like libification...
Show 8 quoted lines
> In case of successful merge, do_recursive_merge() used to print
> something like "Finished one cherry-pick." but nothing was
> printed in case a special strategy like "resolve" was used.
> Now in this case a message like "Finished one cherry-pick with
> strategy resolve." is printed.
>
> So the command behavior should be more consistent wether we are
> using a special strategy or not.

This part sounds like improving output in the cherry-pick --strategy success case.

> 	I also wonder why messages like "Finished one cherry-pick."
> 	are printed on stderr instead of stdout.

Progress reports tend to go to stderr, since they are not what the user wanted to learn from the command but side-effects. In other words, I think the general principle is that

 $ git <foo> 2>/dev/null

should output whatever a traditional Unix command would (usually nothing).

> 	And while at making a backward incompatible change, maybe
> 	we could change the message to something like:
> 
> 	"Finished cherry-pick <sha1>"
Does <sha1> represent the old commit or the new one?

I can’t come up with a reason to worry about backward compatibility in this case. Messages to stderr from porcelain are not guaranteed to be stable.

Show 16 quoted lines
> +++ b/builtin/revert.c
> @@ -357,14 +356,9 @@ static void do_recursive_merge(struct commit *base, struct commit *next,
>  					i++;
>  			}
>  		}
> -		write_message(msgbuf, defmsg);
> -		fprintf(stderr, "Automatic %s failed.%s\n",
> -			me, help_msg());
> -		rerere(allow_rerere_auto);
> -		exit(1);
>  	}
> -	write_message(msgbuf, defmsg);
> -	fprintf(stderr, "Finished one %s.\n", me);
> +
> +	return !clean;
>  }

The return value is 1 if dirty, 0 if clean. In any other situation (e.g., the index locking or the merge machinery breaks) it will still die, so this is not about libification. Is it is for unification with the try_merge_command case?

> @@ -470,30 +466,41 @@ static int do_pick_commit(void)
[...]
Show 9 quoted lines
> +	if (res) {
> +		fprintf(stderr, "Automatic %s failed.%s\n",
> +			mebuf.buf, help_msg());
> +		rerere(allow_rerere_auto);
> +	} else {
> +		fprintf(stderr, "Finished one %s.\n", mebuf.buf);
> +	}
> +
> +	strbuf_release(&mebuf);
Yep, looks like it is.
[...]
> --- a/t/t3508-cherry-pick-many-commits.sh
> +++ b/t/t3508-cherry-pick-many-commits.sh
> @@ -23,12 +23,36 @@ test_expect_success setup '
New tests for the success output.
Show 16 quoted lines
>  '
>  
>  test_expect_success 'cherry-pick first..fourth works' '
> +	cat <<-EOF > expected &&
> +	Finished one cherry-pick.
> +	Finished one cherry-pick.
> +	Finished one cherry-pick.
> +	EOF
> +
> +	git checkout -f master &&
> +	git reset --hard first &&
> +	test_tick &&
> +	git cherry-pick first..fourth 2>actual &&
> +	git diff --quiet other &&
> +	git diff --quiet HEAD other &&
> +	test_cmp expected actual &&

This breaks test runs with sh -x or GIT_TRACE=1 (I am not sure whether we support them, but I think it is worth avoiding problems where possible). Maybe:

	...
	grep "Finished one cherry-pick\." actual >filtered &&
	n=$(wc -l <filtered) &&
	... &&
	test $n -eq 3
Summary: I was misled by the commit message.  Maybe something
like
	Subject: cherry-pick --strategy: report success
	"git cherry-pick foo" has always reported success
	with "Finished one cherry-pick" and cherry-pick
	--strategy is starting to feel left out.  Move the
	code to write that message from do_recursive_merge
	to do_cherry_pick so other strategies can share it.
would have set me straight.
Christian Couder· Jul 13, 2010, 21:02 UTC · re: Jonathan Nieder · lore

Re: [PATCH 1/2] revert: refactor code that prints success or failure message

On Monday 12 July 2010 18:30:43 Jonathan Nieder wrote:
Show 14 quoted lines
> Hi,
> 
> Christian Couder wrote:
> > This patch refactors the code that prints a message like
> > "Automatic cherry-pick failed. <help message>".
> 
> From the point of view of refactoring, it does not seem
> so promising: the patch adds more code than it removes.
> 
>  $ git diff --numstat HEAD^
>  29	22	builtin/revert.c
>  25	 1	t/t3508-cherry-pick-many-commits.sh
> 
> So I am hoping there is some other reason.
If it makes the code easier to maintain it's still a refactoring even if it 
adds some lines, but anyway as I say below I will improve the commit message.
 
Show 6 quoted lines
> > To do that, now do_recursive_merge() returns an int to signal
> > success or failure. And in case of failure we just return 1
> > from do_pick_commit() instead of doing "exit(1)" from either
> > do_recursive_merge() or do_pick_commit().
> 
> This part sounds like libification...
Yes, but it's just because it's needed for the refactoring.
Show 11 quoted lines
> > In case of successful merge, do_recursive_merge() used to print
> > something like "Finished one cherry-pick." but nothing was
> > printed in case a special strategy like "resolve" was used.
> > Now in this case a message like "Finished one cherry-pick with
> > strategy resolve." is printed.
> > 
> > So the command behavior should be more consistent wether we are
> > using a special strategy or not.
> 
> This part sounds like improving output in the cherry-pick --strategy
> success case.
Yes.
Show 11 quoted lines
> > 	I also wonder why messages like "Finished one cherry-pick."
> > 	are printed on stderr instead of stdout.
> 
> Progress reports tend to go to stderr, since they are not what the
> user wanted to learn from the command but side-effects.  In other
> words, I think the general principle is that
> 
>  $ git <foo> 2>/dev/null
> 
> should output whatever a traditional Unix command would (usually
> nothing).
Ok.
Show 6 quoted lines
> > 	And while at making a backward incompatible change, maybe
> > 	we could change the message to something like:
> > 	
> > 	"Finished cherry-pick <sha1>"
> 
> Does <sha1> represent the old commit or the new one?
The old one.
> I can’t come up with a reason to worry about backward compatibility in
> this case.  Messages to stderr from porcelain are not guaranteed to be
> stable.
Ok, so I think I will propose a patch to do that.
Show 29 quoted lines
> > +++ b/builtin/revert.c
> > @@ -357,14 +356,9 @@ static void do_recursive_merge(struct commit *base,
> > struct commit *next,
> > 
> >  					i++;
> >  			
> >  			}
> >  		
> >  		}
> > 
> > -		write_message(msgbuf, defmsg);
> > -		fprintf(stderr, "Automatic %s failed.%s\n",
> > -			me, help_msg());
> > -		rerere(allow_rerere_auto);
> > -		exit(1);
> > 
> >  	}
> > 
> > -	write_message(msgbuf, defmsg);
> > -	fprintf(stderr, "Finished one %s.\n", me);
> > +
> > +	return !clean;
> > 
> >  }
> 
> The return value is 1 if dirty, 0 if clean.  In any other
> situation (e.g., the index locking or the merge machinery breaks)
> it will still die, so this is not about libification.  Is it
> is for unification with the try_merge_command case?
Yes.
Show 15 quoted lines
> > @@ -470,30 +466,41 @@ static int do_pick_commit(void)
> 
> [...]
> 
> > +	if (res) {
> > +		fprintf(stderr, "Automatic %s failed.%s\n",
> > +			mebuf.buf, help_msg());
> > +		rerere(allow_rerere_auto);
> > +	} else {
> > +		fprintf(stderr, "Finished one %s.\n", mebuf.buf);
> > +	}
> > +
> > +	strbuf_release(&mebuf);
> 
> Yep, looks like it is.
Right.
Show 29 quoted lines
> [...]
> 
> > --- a/t/t3508-cherry-pick-many-commits.sh
> > +++ b/t/t3508-cherry-pick-many-commits.sh
> > @@ -23,12 +23,36 @@ test_expect_success setup '
> 
> New tests for the success output.
> 
> >  '
> >  
> >  test_expect_success 'cherry-pick first..fourth works' '
> > 
> > +	cat <<-EOF > expected &&
> > +	Finished one cherry-pick.
> > +	Finished one cherry-pick.
> > +	Finished one cherry-pick.
> > +	EOF
> > +
> > +	git checkout -f master &&
> > +	git reset --hard first &&
> > +	test_tick &&
> > +	git cherry-pick first..fourth 2>actual &&
> > +	git diff --quiet other &&
> > +	git diff --quiet HEAD other &&
> > +	test_cmp expected actual &&
> 
> This breaks test runs with sh -x or GIT_TRACE=1 (I am not sure
> whether we support them, but I think it is worth avoiding
> problems where possible).  Maybe:

I don't know about sh -x but there is this code in test-lib.sh to warn about GIT_TRACE use:

case $(echo $GIT_TRACE |tr "[A-Z]" "[a-z]") in
	1|2|true)
		echo "* warning: Some tests will not work if GIT_TRACE" \
			"is set as to trace on STDERR ! *"
		echo "* warning: Please set GIT_TRACE to something" \
			"other than 1, 2 or true ! *"
		;;
esac
Show 18 quoted lines
> 	...
> 	grep "Finished one cherry-pick\." actual >filtered &&
> 	n=$(wc -l <filtered) &&
> 	... &&
> 	test $n -eq 3
> 
> Summary: I was misled by the commit message.  Maybe something
> like
> 
> 	Subject: cherry-pick --strategy: report success
> 
> 	"git cherry-pick foo" has always reported success
> 	with "Finished one cherry-pick" and cherry-pick
> 	--strategy is starting to feel left out.  Move the
> 	code to write that message from do_recursive_merge
> 	to do_cherry_pick so other strategies can share it.
> 
> would have set me straight.
Ok, I will improve it.

Thanks, Christian.

Jonathan Nieder· Jul 13, 2010, 22:16 UTC · re: Christian Couder · lore

Re: [PATCH 1/2] revert: refactor code that prints success or failure message

Christian Couder wrote:
Show 11 quoted lines
> I don't know about sh -x but there is this code in test-lib.sh to warn about 
> GIT_TRACE use:
> 
> case $(echo $GIT_TRACE |tr "[A-Z]" "[a-z]") in
> 	1|2|true)
> 		echo "* warning: Some tests will not work if GIT_TRACE" \
> 			"is set as to trace on STDERR ! *"
> 		echo "* warning: Please set GIT_TRACE to something" \
> 			"other than 1, 2 or true ! *"
> 		;;
> esac
Oh!  I just remembered
  http://thread.gmane.org/gmane.comp.version-control.git/146767

I guess the answer is we half-support it. Maybe a test_cmp_err() helper to strip out xtrace[1] and GIT_TRACE[2] output is needed.

>> Summary: I was misled by the commit message.
[...]
> Ok, I will improve it.
Thanks, and sorry for the unfocused review.
Jonathan

[1] Sadly, it is not obvious to me that the format of output produced by set -x is portable. Any sufficiently unixy system (e.g., any system supporting the Posix User Portability Utilities option) will use $PS4 which defaults to ‘+ ’ at the beginning of trace lines, but even for Posix that is only optional.

[2] All trace output starts with ‘trace: ’, with one exception.
Show changes to exec_cmd.c +1 −1
diff --git a/exec_cmd.c b/exec_cmd.c
index bf22570..75d2930 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -28,7 +28,7 @@ const char *system_path(const char *path)
 	    !(prefix = strip_path_suffix(argv0_path, BINDIR)) &&
 	    !(prefix = strip_path_suffix(argv0_path, "git"))) {
 		prefix = PREFIX;
-		trace_printf("RUNTIME_PREFIX requested, "
+		trace_printf("trace: RUNTIME_PREFIX requested, "
 				"but prefix computation failed.  "
 				"Using static fallback '%s'.\n", prefix);
 	}
Christian Couder· Jul 15, 2010, 09:26 UTC · re: Jonathan Nieder · lore

Re: [PATCH 1/2] revert: refactor code that prints success or failure message

Hi,
On Wednesday 14 July 2010 00:16:20 Jonathan Nieder wrote:
Show 26 quoted lines
> Christian Couder wrote:
> > I don't know about sh -x but there is this code in test-lib.sh to warn
> > about GIT_TRACE use:
> > 
> > case $(echo $GIT_TRACE |tr "[A-Z]" "[a-z]") in
> > 
> > 	1|2|true)
> > 	
> > 		echo "* warning: Some tests will not work if GIT_TRACE" \
> > 		
> > 			"is set as to trace on STDERR ! *"
> > 		
> > 		echo "* warning: Please set GIT_TRACE to something" \
> > 		
> > 			"other than 1, 2 or true ! *"
> > 		
> > 		;;
> > 
> > esac
> 
> Oh!  I just remembered
> 
>   http://thread.gmane.org/gmane.comp.version-control.git/146767
> 
> I guess the answer is we half-support it.  Maybe a test_cmp_err()
> helper to strip out xtrace[1] and GIT_TRACE[2] output is needed.

I don't understand the result of the above thread but when I try "bash -x t3508-cherry-pick-many-commits.sh" it works on my machine. So I didn't change the tests.

Show 7 quoted lines
> >> Summary: I was misled by the commit message.
> 
> [...]
> 
> > Ok, I will improve it.
> 
> Thanks, and sorry for the unfocused review.
No problem it's still better than no review :-)

Thanks, Christian.

Ramkumar Ramachandra· Jul 12, 2010, 18:27 UTC · re: Christian Couder · lore

Re: [PATCH 1/2] revert: refactor code that prints success or failure message

Hi Christian,
Christian Couder writes:
> This patch refactors the code that prints a message like
> "Automatic cherry-pick failed. <help message>". This code was
[...]

This is good stuff. Can we expect the git-rebase--interactive.sh to be refactored to use the "cherry pick a range" feature in future?

-- Ram
Christian Couder· Jul 13, 2010, 21:16 UTC · re: Ramkumar Ramachandra · lore

Re: [PATCH 1/2] revert: refactor code that prints success or failure message

Hi Ram,
On Monday 12 July 2010 20:27:33 Ramkumar Ramachandra wrote:
Show 10 quoted lines
> Hi Christian,
> 
> Christian Couder writes:
> > This patch refactors the code that prints a message like
> > "Automatic cherry-pick failed. <help message>". This code was
> 
> [...]
> 
> This is good stuff. Can we expect the git-rebase--interactive.sh to be
> refactored to use the "cherry pick a range" feature in future?

I am trying to improve cherry-pick step by step so that hopefully in the end we have some sequencer like functionalities. So yes, I hope that it will be possible to refactor git-rebase--interactive.sh and perhaps other such shell scripts.

Thanks, Christian.

← back to recent threads