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

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

[Christian Couder]

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(-)

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

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

[Jonathan Nieder]

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...

> 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.

> +++ 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)
[...]
> +	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.

>  '
>  
>  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.

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

[Christian Couder]

On Monday 12 July 2010 18:30:43 Jonathan Nieder wrote:
> 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.
 
> > 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.

> > 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.

> > 	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.

> > 	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.

> > +++ 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.

> > @@ -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.

> [...]
> 
> > --- 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

> 	...
> 	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.

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

[Jonathan Nieder]

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.

>> 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.

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);
 	}
-- 

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

[Christian Couder]

Hi,

On Wednesday 14 July 2010 00:16:20 Jonathan Nieder wrote:
> 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.

> >> 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.

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

[Ramkumar Ramachandra]

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

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

[Christian Couder]

Hi Ram,

On Monday 12 July 2010 20:27:33 Ramkumar Ramachandra wrote:
> 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.