From: Junio C Hamano <gitster@pobox.com>
To: Yoshioka Tsuneo <yoshiokatsuneo@gmail.com>
Cc: "git\@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: [PATCH v6] diff.c: keep arrow(=>) on show_stats()'s shortened filename part to make rename visible.
Date: Thu, 17 Oct 2013 12:29:26 -0700 [thread overview]
Message-ID: <xmqqmwm71ysp.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <89A4E8C6-C233-49E2-8141-837ABDBBC976@gmail.com> (Yoshioka Tsuneo's message of "Wed, 16 Oct 2013 12:53:44 +0300")
Yoshioka Tsuneo <yoshiokatsuneo@gmail.com> writes:
> "git diff -M --stat" can detect rename and show renamed file name like
> "foofoofoo => barbarbar".
> Before this commit, this output is shortened always by omitting left most
> part like "...foo => barbarbar". So, if the destination filename is too long,
> source filename putting left or arrow can be totally omitted like
> "...barbarbar", without including any of "foofoofoo =>".
> In such a case where arrow symbol is omitted, there is no way to know
> whether the file is renamed or existed in the original.
> Make sure there is always an arrow, like "...foo => ...bar".
> The output can contain curly braces('{','}') for grouping.
> So, in general, the output format is "<pfx>{<mid_a> => <mid_b>}<sfx>"
> To keep arrow("=>"), try to omit <pfx> as long as possible at first
> because later part or changing part will be the more important part.
> If it is not enough, shorten <mid_a>, <mid_b>, and <sfx> trying to
> have the maximum length the same because those will be equally important.
I somehow find this solid wall of text extremely hard to
read. Adding a blank line as a paragraph break may make it easier to
read, perhaps.
Also it is customary in our history to omit the full-stop from the
patch title on the Subject: line.
> + name_len = pfx->len + a_mid->len + b_mid->len + sfx->len + strlen(arrow)
> + + (use_curly_braces ? 2 : 0);
> +
> + if (name_len <= name_width) {
> + /* Everthing fits in name_width */
> + return;
> + }
Logic up to this point seems good; drop {} around a single statement
"return;", i.e.
if (name_len <= name_width)
return; /* everything fits */
> + } else {
> + if (pfx->len > strlen(dots)) {
> + /*
> + * Just omitting left of '{' is not enough
> + * name will be "...{SOMETHING}SOMETHING"
> + */
> + strbuf_reset(pfx);
> + strbuf_addstr(pfx, dots);
> + }
(mental note) ... otherwise, i.e. with a short common prefix, the
final result will be "ab{SOMETHING}SOMETHING", which is also fine
for the purpose of the remainder of this function.
> + }
> + }
> +
> + /* available length for a_mid, b_mid and sfx */
> + len = name_width - strlen(arrow) - (use_curly_braces ? 2 : 0);
> +
> + /* a_mid, b_mid, sfx will be have the same max, including ellipsis("..."). */
> + part_length[0] = a_mid->len;
> + part_length[1] = b_mid->len;
> + part_length[2] = sfx->len;
> +
> + qsort(part_length, sizeof(part_length)/sizeof(part_length[0]), sizeof(part_length[0])
> + , compare_size_t_descending_order);
In our code, comma does not come at the beginning of continued
line.
> + if (part_length[1] + part_length[1] + part_length[2] <= len) {
> + /*
> + * "{...foofoo => barbar}file"
> + * There is only one omitted part.
> + */
> + max_part_len = len - part_length[1] - part_length[2];
It would be clearer to explicitly set remainder to zero here, and
omit the initialization of the variable. That would make what the
three parts of if/elseif/else do more consistent.
> + } else if (part_length[2] + part_length[2] + part_length[2] <= len) {
> + /*
> + * "{...foofoo => ...barbar}file"
> + * There are 2 omitted parts.
> + */
> + max_part_len = (len - part_length[2]) / 2;
> + remainder_part_len = (len - part_length[2]) - max_part_len * 2;
> + } else {
> + /*
> + * "{...ofoo => ...rbar}...file"
> + * There are 3 omitted parts.
> + */
> + max_part_len = len / 3;
> + remainder_part_len = len - (max_part_len) * 3;
> + }
I am not sure if distributing the burden of truncation equally to
three parts so that the resulting pieces are of similar lengths is
really a good idea. Between these two
{...SourceDirectory => ...nationDirectory}...ileThatWasMoved
{...ceDirectory => ...ionDirectory}nameOfTheFileThatWasMoved
that attempt to show that the file nameOfTheFileThatWasMoved was
moved from the longSourceDirectory to the DestinationDirectory, the
latter is much more informative, I would think.
> diff --git a/t/t4001-diff-rename.sh b/t/t4001-diff-rename.sh
> index 2f327b7..03d6371 100755
> --- a/t/t4001-diff-rename.sh
> +++ b/t/t4001-diff-rename.sh
> @@ -156,4 +156,16 @@ test_expect_success 'rename pretty print common prefix and suffix overlap' '
> test_i18ngrep " d/f/{ => f}/e " output
> '
>
> +test_expect_success 'rename of very long path shows =>' '
> + mkdir long_dirname_that_does_not_fit_in_a_single_line &&
> + mkdir another_extremely_long_path_but_not_the_same_as_the_first &&
> + cp path1 long_dirname*/ &&
> + git add long_dirname*/path1 &&
> + test_commit add_long_pathname &&
> + git mv long_dirname*/path1 another_extremely_*/ &&
> + test_commit move_long_pathname &&
> + git diff -M --stat HEAD^ HEAD >output &&
> + test_i18ngrep "=>.*path1" output
Does this have to be i18ngrep? I had a feeling that we would not
want this part of the output localized, in which case "grep" may be
more appropriate.
> +'
> +
> test_done
next prev parent reply other threads:[~2013-10-17 19:29 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-11 11:24 [PATCH] diff.c: keep arrow(=>) on show_stats()'s shortened filename part to make rename visible Yoshioka Tsuneo
2013-10-11 13:07 ` [PATCH v2] " Yoshioka Tsuneo
2013-10-11 18:19 ` [spf:guess,mismatch] " Sam Vilain
2013-10-12 5:35 ` Keshav Kini
2013-10-12 20:52 ` Yoshioka Tsuneo
2013-10-12 20:48 ` [PATCH v3] " Yoshioka Tsuneo
2013-10-13 20:29 ` Thomas Rast
2013-10-15 9:46 ` Yoshioka Tsuneo
2013-10-14 19:04 ` Duy Nguyen
2013-10-15 9:46 ` Yoshioka Tsuneo
2013-10-15 9:45 ` [PATCH v4] " Yoshioka Tsuneo
2013-10-15 10:07 ` Felipe Contreras
2013-10-15 10:24 ` Yoshioka Tsuneo
2013-10-15 10:24 ` [PATCH v5] " Yoshioka Tsuneo
2013-10-15 22:54 ` Junio C Hamano
2013-10-15 22:58 ` Keshav Kini
2013-10-16 9:53 ` Yoshioka Tsuneo
2013-10-16 9:53 ` [PATCH v6] " Yoshioka Tsuneo
2013-10-17 19:29 ` Junio C Hamano [this message]
2013-10-17 22:08 ` Yoshioka Tsuneo
2013-10-17 22:38 ` Junio C Hamano
2013-10-18 9:35 ` Yoshioka Tsuneo
2013-10-17 19:53 ` Junio C Hamano
2013-10-17 22:08 ` [PATCH v7] " Yoshioka Tsuneo
2013-10-18 9:35 ` [PATCH v8] " Yoshioka Tsuneo
2013-10-19 6:24 ` Thomas Rast
2013-10-20 1:49 ` Yoshioka Tsuneo
2013-10-22 18:09 ` Junio C Hamano
2013-10-22 20:14 ` Yoshioka Tsuneo
2013-10-22 20:26 ` Junio C Hamano
2013-10-12 20:48 ` [PATCH v3] " Yoshioka Tsuneo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqmwm71ysp.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=yoshiokatsuneo@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.