The message length depends on the length of the branch name.  In my case,
the branch name "origin/add-chickens2" put the first line of the "your
branch has diverged" message over 80 characters, which triggered "less -FS"
to not exit automatically as expected.

This patch puts the newlines in slightly different places to reduce the
probability of this happening.  Now you'd need a significantly longer
branch name to trigger the problem.

Signed-off-by: Avery Pennarun <apenwarr@gmail.com>
---
 remote.c |   10 +++++-----
 1 files changed, 5 insertions(+), 5 deletions(-)
 
I suppose a full-on automatic wordwrapper would be nicer :)
 

diff --git a/remote.c b/remote.c
index df8bd72..4f32032 100644
--- a/remote.c
+++ b/remote.c
@@ -1321,19 +1321,19 @@ int format_tracking_info(struct branch *branch, struct strbuf *sb)
 		remote_msg = "";
 	}
 	if (!num_theirs)
-		strbuf_addf(sb, "Your branch is ahead of the tracked%s branch '%s' "
+		strbuf_addf(sb, "Your branch is ahead of the tracked%s branch '%s'\n"
 			    "by %d commit%s.\n",
 			    remote_msg, base,
 			    num_ours, (num_ours == 1) ? "" : "s");
 	else if (!num_ours)
-		strbuf_addf(sb, "Your branch is behind the tracked%s branch '%s' "
-			    "by %d commit%s,\n"
+		strbuf_addf(sb, "Your branch is behind the tracked%s branch '%s'\n"
+			    "by %d commit%s, "
 			    "and can be fast-forwarded.\n",
 			    remote_msg, base,
 			    num_theirs, (num_theirs == 1) ? "" : "s");
 	else
-		strbuf_addf(sb, "Your branch and the tracked%s branch '%s' "
-			    "have diverged,\nand respectively "
+		strbuf_addf(sb, "Your branch and the tracked%s branch '%s'\n"
+			    "have diverged, and respectively "
 			    "have %d and %d different commit(s) each.\n",
 			    remote_msg, base,
 			    num_ours, num_theirs);
-- 
1.5.6.3.385.g94745

--

[ message continues ]

I wonder if a simple "s/of the tracked%s branch //" is better for this
kind of thing.  If the message says 'origin/master', you know it is a
tracked remote branch anyway, don't you?

Too wide is bad, but too tall is worse.  Some of us still work in 80x24
;-) and I prefer to make the message succinct when possible, rather than

This does not make the message taller, but if we were to make the "only
one side advanced" cases shorter, we would need to reword this to be
consistent.  Perhaps something like this would be just as easy to read and
more compact?

	Your branch is ahead of 'origin/add-chickens2' by 21 commits.

        Your branch is behind 'origin/add-chickens2' by 1 commit.

        Your branch and 'origin/add-chickens2' have diverged, and have
        21 and 1 different commit(s) each, respectively.

I moved "respectively" so that the variable parts will come close to the
beginning of physical line.
--

[ message continues ]

Personally, I would be fine with shorter messages; this doesn't seem
the best time to
report the name of the tracked branch anyhow.  I use 80x24 terminals
too most of the time.

However, I didn't write the original patch either, and I recall that
this feature was so popular that it actually resulted in a list thread

Well, the fact that the number of commits is "variable" isn't so
important, unless you start diverging by 1e9 commits or something :)
It might be nice to minimize the amount of static text on the line
containing the branch name, though.  Your rephrasing would allow us to
go as far as:

    Your branch and 'origin/add-chickens2'
    have diverged, and have 21 and 1 different commit(s) each, respectively.

Which looks a little imbalanced, but works with long branch names.

Alternatively, your rephrasing above made me think of the idea of just
printing *both* of the first two messages in the "diverging" case.
Depending how you think of it, that would be either more clear or less
clear.  It's actually easier to parse the two short sentences than the
long one.

Please let me know if you want me to resubmit the patch with your
suggestions or whether you'll handle it.  I'm still a little vague on
the exact patch approval process.

Have fun,

Avery
--

[ message continues ]

No, no, no.  The point is not about keeping it on screen when "less -S"
chops at the right end.  The point is to limit eye-movement of the user;
i.e. presenting important information consistently at around the same
column, closer to the left edge.  Probably the line break should be before

I do not think it is such a good idea --- we invite silly comments like

It is very much more "consensus building" than "approval", and at this
point we wait for a day or two to see if