On Fri, May 20, 2016 at 01:39:06PM -0700, Junio C Hamano wrote:
> > +{
> > + size_t i;
> > + struct strbuf out = STRBUF_INIT;
> > + unsigned int width = 80;
>
> In a few places Git limits the width of the output, like using function
> name in hunk header lines and drawing diffstat in "diff --stat", we
> do default to limit the total width to 80 display columns.
>
> Given that this routine prefixes each and every line with a short
> heading like "=> Send header: " that costs at around 15-20 columns,
> and the loop we see below only counts the true payload without
> counting the heading, you would probably want to reduce this
> somewhat so that the whole thing would fit within 80 columns.
I think that may be a losing battle. Remember that we are getting the
usual trace header on top of this, which I think leaves only about 20
characters for actual data on each line.
I kind of doubt people will manually read the body data. In my
experience, debugging git-over-http you want either:
1. Just the request/response headers to see what was said.
2. A complete dump of each body with no other formatting (e.g., so you
can replay it with curl).
This trace output gives you (1). You can in theory generate (2) from it
with a perl snippet, but the non-printing characters have been
irreversibly transformed.
So I dunno. I do not mind having the body stuff there for completeness,
but I doubt I'd use it myself. And I don't care much either way about
how long its lines are.
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html