remove function magit-log-cutoff-length-arg
remove constant magit-log-format
magit-log-{one,long}line-re: re-indent
magit-log-{one,long}line-re: put "refs" pattern on single line

This results in a long line, which is okay because that will be
fixed in a subsequent commit.
magit-log-oneline-re: improve matching that extra space
magit-log-oneline-re: merge the optional shy groups

In `magit-log-oneline-re' merge the optional shy groups.  The parts they
match only appear in combination (on an actual log line) or none of them
do (on a graph-only line).
magit-log-{one,long}line-re: improve graph matching
magit-log-longline-re: make definition more compact

As of now it probably looks like this is *too* compact - but
it will get better.
magit-log-longline-re: deal with three kinds of lines

There are up to three kinds of "log lines" that the `magit-log-{*}-re'
functions have to match.

* "actual log"   appearing in   long, oneline, others
* "graph-only"   appearing in   long, oneline
* "details"      appearing in   long

That might not be such a good idea - it certainly complicates writing
the regexps.  For now just make the regexps fully aware of that fact.

For "long log" that means that a line either contains a hash (and
possibly refs) **or** it has "something else".  For other log types that
would be the "message", but for "long log" that does not make much sense
- it is better to think of it as "the rest" after the (optional) graph.

In order not to complicate things we keep pretending this is "the
message" but we adjust the regexp to reflect the distinction.  By doing
so we prepare it for future changes.
remove magit-{ref-nonslash-re,ref-nonchars,refname-re}

Remove the constant regexp variables `magit-ref-nonslash-re',
`magit-ref-nonchars', and `magit-refname-re'.  They were only used as
part of the constant values of the variables `magit-log-oneline-re' and
`magit-log-long-re' regexp constants.

The substrings these partial regexps were matched against either did not
exist at all, or they were guaranteed to contain only refs.  So there
really is no good reason to assert that the substrings consists of refs;
we know they always do.
reverse order in which log-washing functions are defined
magit-parse-log-line: stop misleading the reader

`magit-wash-log-line' is called repeatedly by `magit-wash-sequence'
until the latter returns nil or the end of the buffer or narrowed part
is reached.

`magit-wash-log-line' never returns nil, the explicit `t' at its end
makes sure of that.  And even without that it would never return nil.

So the reason `magit-wash-sequence' ever stops calling the washer is
that the end of the buffer or narrowed part is reached.  In practice
that means that all callers of `magit-wash-log' have to narrow to the
relevant portion before initiating the washing.

In other words `magit-parse-log-line' only ever gets to see lines that
are actual log lines.  It is therefor misleading that its body is
wrapped in a `when' form.
magit-wash-log-line: no need to assert line is non-nil

`magit-parse-log-line' always returns a `magit-log-line' struct - never
nil.  Therefor in `magit-wash-log-line' (its only caller) do not assert
this is indeed so - we know it is.  This change is about not misleading
the reader.
magit-wash-log-line: absorb magit-{parse,format}-log-line

Merge `magit-format-log-line' and `magit-parse-log-line' into
`magit-wash-log-line'.  `parse' was only used by `format', which in turn
was only used by `wash'.  Splitting the various subtasks into separate
functions did only complicate things.

In the process remove the `magit-log-line' struct which was only ever
used to pass an ordered collection of values from `parse' to `format'.
That was quite silly in itself, a simple would have been equally
powerful and much more compact.  This is just the tip of the iceberg.
magit-wash-log-line: rename internal variable from sha1 to hash
explicitly number submatches in log-line regexps

In `magit-log-{oneline,longline,unique,reflog}-re' number the submatches
explicitly.  The subexpressions/parts common to more styles get a lower
number than those only relevant to one or two styles.

Then take the dance bear out of `magit-wash-log-line'.
add macro magit-bind-match-strings

Why can't something like `bind-match-strings' just be part of Emacs?
Even just `match-strings' (plural) would be great.  Hell, even making
`match-limit' available in lisp would be of some help.  Instead we all
have to bang on `match-data' or manually construct `let's VARLIST by
hand.  Not anymore, at least not in Magit.
magit-log-{oneline,longline,cherry,reflog}-re: cosmetics
magit-wash-log-line: for longline, put hash behind graph

Function `magit-wash-log-line' used to put the commit hash before the
graph for all log styles.  In case of the "long" log this just wasted
space.  So now the graph comes first for that style.
magit-wash-log-line: for longline, show full hash, if there is room

When washing a "long" log `magit-wash-log-line' now inserts the full
hash, iff there is enough room, that is when there are no refs that
point to the commit.