git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
* [RFC PATCH] sequencer: do_commit: print the change summary ala git-am
@ 2020-04-16 12:39 Leah Neukirchen
  2020-04-16 15:02 ` Phillip Wood
  0 siblings, 1 reply; 2+ messages in thread
From: Leah Neukirchen @ 2020-04-16 12:39 UTC (permalink / raw)
  To: git


This makes the output of "git pull --rebase" look as if using the
apply backend.

Signed-off-by: Leah Neukirchen <leah@vuxu.org>
---
I noticed that the new "merge" rebase backend does not print lines ala
"Applying: reticulate the splines" anymore.  I found these useful when
using "git pull --rebase", as one easily saw which unpushed patches
were in the tree.  (Also, eliminated patches were not printed anymore,
but that is a special thing about our workflow, where many committers
can do exactly the same trivial patches often.)

I found do_commit to be the best place to put this, but I'm not
super familiar with the Git code base; perhaps this also prints
in other invocations where it rather shouldn't.

linelen is taken from builtin/am.c.

 sequencer.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/sequencer.c b/sequencer.c
index 6fd2674632..5e315eda1c 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -1442,6 +1442,14 @@ static int write_rebase_head(struct object_id *oid)
 	return 0;
 }
 
+/**
+ * Returns the length of the first line of msg.
+ */
+static int linelen(const char *msg)
+{
+        return strchrnul(msg, '\n') - msg;
+}
+
 static int do_commit(struct repository *r,
 		     const char *msg_file, const char *author,
 		     struct replay_opts *opts, unsigned int flags,
@@ -1458,6 +1466,10 @@ static int do_commit(struct repository *r,
 					     "from '%s'"),
 					   msg_file);
 
+		if (!opts->quiet)
+			fprintf_ln(stdout, _("Applying: %.*s"),
+				linelen(sb.buf), sb.buf);
+
 		res = try_to_commit(r, msg_file ? &sb : NULL,
 				    author, opts, flags, &oid);
 		strbuf_release(&sb);
-- 
2.26.1

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [RFC PATCH] sequencer: do_commit: print the change summary ala git-am
  2020-04-16 12:39 [RFC PATCH] sequencer: do_commit: print the change summary ala git-am Leah Neukirchen
@ 2020-04-16 15:02 ` Phillip Wood
  0 siblings, 0 replies; 2+ messages in thread
From: Phillip Wood @ 2020-04-16 15:02 UTC (permalink / raw)
  To: Leah Neukirchen, git; +Cc: Elijah Newren, Johannes Schindelin

Hi Leah

Thanks for the patch

On 16/04/2020 13:39, Leah Neukirchen wrote:
> 
> This makes the output of "git pull --rebase" look as if using the
> apply backend.
>
> Signed-off-by: Leah Neukirchen <leah@vuxu.org>
> ---
> I noticed that the new "merge" rebase backend does not print lines ala
> "Applying: reticulate the splines" anymore.  I found these useful when
> using "git pull --rebase", as one easily saw which unpushed patches
> were in the tree.  (Also, eliminated patches were not printed anymore,
> but that is a special thing about our workflow, where many committers
> can do exactly the same trivial patches often.)
> 
> I found do_commit to be the best place to put this, but I'm not
> super familiar with the Git code base; perhaps this also prints
> in other invocations where it rather shouldn't.

I think it also changes the output of rebase -i/-r, cherry-pick and 
revert. Fixing the latter two is easy, it will be trickier to fix the 
former. Rebase -i/-r/-m already print 'Rebasing (n/m)' as they apply 
each patch and reuses the same line if --verbose is not given to save 
terminal space where they are picking a large number of commits.

I can see why you want this output when rebasing after pulling, I'm not 
sure we necessarily want to change the output of rebase -i/-m/-r though. 
Maybe we can add a member to struct replay_opts that is set by pull and 
rebase --apply or maybe we should print the commit subject when 
--verbose is set. I'm not really sure at the moment - I've cc'd Elijah 
and dscho to see if they have any thoughts

> linelen is taken from builtin/am.c.

A minor point - the sequencer uses the subject as given by 'log 
--pretty=%s' when creating the todo list and I think that is probably 
what we should be printing (both here and for am). This is subtly 
different from using linelen() as --pretty=%s unwraps all the lines 
before the first empty line of the commit message so

   line one
   line two

   commit message body

would appear as 'line one line two' whereas linelen() just gives 'line one'

Best Wishes

Phillip


>   sequencer.c | 12 ++++++++++++
>   1 file changed, 12 insertions(+)
> 
> diff --git a/sequencer.c b/sequencer.c
> index 6fd2674632..5e315eda1c 100644
> --- a/sequencer.c
> +++ b/sequencer.c
> @@ -1442,6 +1442,14 @@ static int write_rebase_head(struct object_id *oid)
>   	return 0;
>   }
>   
> +/**
> + * Returns the length of the first line of msg.
> + */
> +static int linelen(const char *msg)
> +{
> +        return strchrnul(msg, '\n') - msg;
> +}
> +
>   static int do_commit(struct repository *r,
>   		     const char *msg_file, const char *author,
>   		     struct replay_opts *opts, unsigned int flags,
> @@ -1458,6 +1466,10 @@ static int do_commit(struct repository *r,
>   					     "from '%s'"),
>   					   msg_file);
>   
> +		if (!opts->quiet)
> +			fprintf_ln(stdout, _("Applying: %.*s"),
> +				linelen(sb.buf), sb.buf);
> +
>   		res = try_to_commit(r, msg_file ? &sb : NULL,
>   				    author, opts, flags, &oid);
>   		strbuf_release(&sb);
> 

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2020-04-16 15:02 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-04-16 12:39 [RFC PATCH] sequencer: do_commit: print the change summary ala git-am Leah Neukirchen
2020-04-16 15:02 ` Phillip Wood

Code repositories for project(s) associated with this inbox:

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).