Stefan Beller <sbeller@xxxxxxxxxx> writes:
> In a later patch, I want to propose an option to detect&color
> moved lines in a diff, which cannot be done in a one-pass over
> the diff. Instead we need to go over the whole diff twice,
> because we cannot detect the first line of the two corresponding
> lines (+ and -) that got moved.
>
> So to prepare the diff machinery for two pass algorithms
> (i.e. buffer it all up and then operate on the result),
> move all emissions to places, such that the only emitting
> function is emit_line_0.
>
> This prepares the code for submodules to go through the
> emit_line function.
>
> Signed-off-by: Stefan Beller <sbeller@xxxxxxxxxx>
> ---
> diff.c | 20 +++++++---------
> diff.h | 5 ++++
> submodule.c | 78 ++++++++++++++++++++++++++++++-------------------------------
> submodule.h | 9 +++----
> 4 files changed, 56 insertions(+), 56 deletions(-)
>
> diff --git a/diff.c b/diff.c
> index 690794aeb8..7c8d6a5d12 100644
> --- a/diff.c
> +++ b/diff.c
> @@ -516,8 +516,8 @@ static void check_blank_at_eof(mmfile_t *mf1, mmfile_t *mf2,
> ecbdata->blank_at_eof_in_postimage = (at - l2) + 1;
> }
>
> -static void emit_line(struct diff_options *o, const char *set, const char *reset,
> - int add_line_prefix, int sign, const char *line, int len)
> +void emit_line(struct diff_options *o, const char *set, const char *reset,
> + int add_line_prefix, int sign, const char *line, int len)
> {
> int has_trailing_newline, has_trailing_carriage_return;
> FILE *file = o->file;
> @@ -547,10 +547,10 @@ static void emit_line(struct diff_options *o, const char *set, const char *reset
> fputc('\n', file);
> }
>
> -static void emit_line_fmt(struct diff_options *o,
> - const char *set, const char *reset,
> - int add_line_prefix,
> - const char *fmt, ...)
> +void emit_line_fmt(struct diff_options *o,
> + const char *set, const char *reset,
> + int add_line_prefix,
> + const char *fmt, ...)
Interesting...
> -static void show_submodule_header(FILE *f, const char *path,
> - const char *line_prefix,
> +static void show_submodule_header(struct diff_options *o, const char *path,
> struct object_id *one, struct object_id *two,
> unsigned dirty_submodule, const char *meta,
> const char *reset,
Is this ONLY called when the caller wants its output inserted to the
"diff" (or "log -p") output? If so, I think it makes sense to pass
'o', but if the function is oblivious that it is driven to produce
part of a "diff", it feels wrong to pass 'o'. The original was
taking a "FILE *" and line_prefix, so it is rather clear that the
answer to the question is "yes, this is very closely tied to diff
output". Now you have access to 'o', so you do not need to pass
them separately. Good.
Each line in its output, when incorporated in "diff" or "log -p"
output, must be prefixed with the line-prefix to accomodate users of
"log --graph", so I guess it cannot be helped. Your calls to
emit_line_fmt() below seems to ask the line-prefix to be added,
which is good, too.
How does capturing these lines help moved line detection, by the
way? These must never be matched with any other added or removed
line in the real patch output.
> @@ -426,11 +419,11 @@ static void show_submodule_header(FILE *f, const char *path,
> int fast_forward = 0, fast_backward = 0;
>
> if (dirty_submodule & DIRTY_SUBMODULE_UNTRACKED)
> - fprintf(f, "%sSubmodule %s contains untracked content\n",
> - line_prefix, path);
> + emit_line_fmt(o, NULL, NULL, 1,
> + "Submodule %s contains untracked content\n", path);
> if (dirty_submodule & DIRTY_SUBMODULE_MODIFIED)
> - fprintf(f, "%sSubmodule %s contains modified content\n",
> - line_prefix, path);
> + emit_line_fmt(o, NULL, NULL, 1,
> + "Submodule %s contains modified content\n", path);
>
> if (is_null_oid(one))
> message = "(new submodule)";
emit_line() and emit_line_fmt() are both inappropriate names for a
global function. These are very closely tied to diff generation, so
we probably want to see some form of "diff" in their names.
The fact that it is clear because its first parameter is "struct
diff_options" is insufficient---"you cannot tell what context the
function is meant to be used by only looking at its name" is
certainly solved by its function signature, but the other issue with
an overly generic name is that other codepaths in different contexts
may want to use such a short and sweet name.
Thanks.