From: Thomas Rast <tr@thomasrast•ch>
To: Yoshioka Tsuneo <yoshiokatsuneo@gmail•com>
Cc: "git\@vger.kernel.org" <git@vger•kernel.org>
Subject: Re: [PATCH v3] diff.c: keep arrow(=>) on show_stats()'s shortened filename part to make rename visible.
Date: Sun, 13 Oct 2013 22:29:29 +0200 [thread overview]
Message-ID: <877gdg7w46.fsf@linux-k42r.v.cablecom.net> (raw)
In-Reply-To: <660A536D-9993-4B81-B6FF-A113F9111570@gmail.com> (Yoshioka Tsuneo's message of "Sat, 12 Oct 2013 23:48:16 +0300")
Hi,
Yoshioka Tsuneo <yoshiokatsuneo@gmail•com> writes:
> "git diff -M --stat" can detect rename and show renamed file name like
> "foofoofoo => barbarbar", but if destination filename is long the line
> is shortened like "...barbarbar" so there is no way to know whether the
> file is renamed or existed in the source commit.
Thanks for your patch! I think this is indeed something that should be
fixed.
Can you explain the algorithm chosen in the commit message or a block
comment in the code? I find it much easier to follow large code blocks
(like the one you added) with a prior notion of what it tries to do.
[As an aside, Documentation/SubmittingPatches says
The body should provide a meaningful commit message, which:
. explains the problem the change tries to solve, iow, what is wrong
with the current code without the change.
. justifies the way the change solves the problem, iow, why the
result with the change is better.
. alternate solutions considered but discarded, if any.
Observe that you explained the first item very well, but not the
others.]
> This commit makes it visible like "...foo => ...bar".
Also, you should rewrite this to be in the imperative mood:
Make sure there is always an arrow, e.g., "...foo => ...bar".
or some such.
[Again from SubmittingPatches:
Describe your changes in imperative mood, e.g. "make xyzzy do frotz"
instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy
to do frotz", as if you are giving orders to the codebase to change
its behaviour.]
> Signed-off-by: Tsuneo Yoshioka <yoshiokatsuneo@gmail•com>
> ---
> diff.c | 58 +++++++++++++++++++++++++++++++++++++++++++++++++++-------
> 1 file changed, 51 insertions(+), 7 deletions(-)
Can you add a test? Perhaps like the one below. (You can squash it
into your commit if you like it.)
Note that in the test, the generated line looks like this:
{..._does_not_fit_in_a_single_line => .../path1 | 0
I don't want to go all bikesheddey, but I think it's somewhat
unfortunate that the elided parts do not correspond to each other. In
particular, I think the closing brace should not be omitted. Perhaps
something like this would be ideal (making it up on the spot, don't
count characters):
{...a_single_line => ..._as_the_first}/path1 | 0
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
+'
+
test_done
--
Thomas Rast
tr@thomasrast•ch
next prev parent reply other threads:[~2013-10-13 20: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 [this message]
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
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=877gdg7w46.fsf@linux-k42r.v.cablecom.net \
--to=tr@thomasrast$(echo .)ch \
--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