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$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=yoshiokatsuneo@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox