Re: [PATCH v3] diff.c: keep arrow(=>) on show_stats()'s shortened filename part to make rename visible.
- From
Yoshioka Tsuneo <yoshiokatsuneo@gmail.com>
- Date
- Oct 15, 2013, 09:46 UTC
- Message-ID
- <E3435C7B-9673-40F5-96EA-AD59B20EBC4A@gmail.com>
- In-Reply-To
- <877gdg7w46.fsf@linux-k42r.v.cablecom.net>
Hello Thomas
Thank you very much for your kind review. Now, I just posted "PATCH v4" that will include your suggestion like keeping "{", "}" while omitting, improving commit message and comment, and test.
Thanks!
--- Tsuneo Yoshioka (吉岡 恒夫) yoshiokatsuneo@gmail.com
On Oct 13, 2013, at 11:29 PM, Thomas Rast <tr@thomasrast.ch> wrote:
Show 91 quoted lines
> 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