On Thu, Feb 7, 2019 at 8:14 PM Junio C Hamano <gits...@pobox.com> wrote:
>
> Elijah Newren <new...@gmail.com> writes:
>
> > + for (i = 0; i < num_parent; i++) {
> > + switch (elem->parent[i].status) {
> > + case DIFF_STATUS_COPIED:
> > + dump_quoted_path("copy from ", "",
> > + elem->parent[i].path.buf,
> > + line_prefix, c_meta, c_reset);
> > + break;
> > + case DIFF_STATUS_RENAMED:
> > + dump_quoted_path("rename from ", "",
> > + elem->parent[i].path.buf,
> > + line_prefix, c_meta, c_reset);
> > + break;
> > + }
> > + }
>
> The explanation for this addition was that it is hard to tell from
> which side a rename happened in the three-dash lines alone:
>
> --- a/packages/search/ete/src/test/resources/test-suite.yml
> --- a/packages/search/src/geb/resources/test-suite.yml
> +++ b/packages/search/ete/src/test/resources/test-suite.yml
>
> and your hope was that adding:
>
> rename from packages/search/src/geb/resources/test-suite.yml
>
> would help especially when the path is overly long.
>
> But I am not sure if that single "rename from" is all that helpful.
> You cannot tell relative to which parent the rename happened without
> going back to the three-dash lines. A loop that iterates over all
> parents but shows only a line for a parent that actually had copy or
> rename loses "the line is talking about the change from this parent"
> which is a fairly important piece of information, doesn't it?
>
> If we attempt to clarify it by adding some more information on the
> line, e.g.
>
> rename relative to parent #1 from packages/search/src/geb/...
>
> the line gets even longer, and going back to look at
>
> --- a/packages/search/src/geb/resources/test-suite.yml
>
> may turn out to be an easier way to learn that information.
> So,... I dunno.
Yeah, fair enough. I'll drop the patch.
