Hello Thomas

> Can you briefly describe what you changed in v7 and v8, both compared to
> earlier versions and between v7 and v8?
On v7, <sfx>'s basename part is tried to kept. On v7, whole <sfx> part is tried 
to kept.
For example, in case below:
   parent_path{sourceDirectory => 
 On v7, this can be like:
   …{...ceDirectory => …onDirectory}.../longlongFilename.txt
On v8, it will be like:
   …{...irectory => …irectory}path1/path2/longlongFilename.txt

This change is based on the review from Junio below.
(I myself is not sure what is the better way.)
On Oct 17, 2013, at 10:29 PM, Junio C Hamano <gits...@pobox.com> wrote:
> 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.

On Oct 18, 2013, at 1:38 AM, Junio C Hamano <gits...@pobox.com> wrote:
> Yoshioka Tsuneo <yoshiokatsu...@gmail.com> writes:
>> In the "[PATCH v7]", I changed to keep filename part of suffix to handle
>> above case, but not always keep directory part because I feel totally
>> keeping all part of long suffix including directory name may cause output 
>> like:
>>    …{… => …}…ongPath1/LongPath2/nameOfTheFileThatWasMoved 
>> And, above may be worse than:
>>   ...{...ceDirectory => …ionDirectory}.../nameOfTheFileThatWasMoved
>> I think.
> I am not sure if I agree.
> Losing LongPath2 part may be more significant data loss than losing
> a single bit that says the change is a rename, as the latter may not
> quite tell us what these two directories were anyway.

Also, I guess Junio might be suspicious to the idea to keep arrow("=>") itself, 
maybe ?
(From What's cooking in git.git (Oct 2013, #04; Fri, 18))
- diff.c: keep arrow(=>) on show_stats()'s shortened filename part to make 
rename visible

Attempts to give more weight on the fact that a filepair represents
a rename than showing substring of the actual path when diffstat
lines are not wide enough.

I am not sure if that is solving a right problem, though.


Tsuneo Yoshioka (吉岡 恒夫)

On Oct 19, 2013, at 9:24 AM, Thomas Rast <t...@thomasrast.ch> wrote:

> Yoshioka Tsuneo <yoshiokatsu...@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> trying to have the same
>> maximum length.
>> If it is not enough yet, omit <sfx>.
>> Signed-off-by: Tsuneo Yoshioka <yoshiokatsu...@gmail.com>
>> Test-added-by: Thomas Rast <tr...@inf.ethz.ch>
>> ---
> Can you briefly describe what you changed in v7 and v8, both compared to
> earlier versions and between v7 and v8?
> It would be very nice if you could always include such a "patch
> changelog" after the "---" above.  git-am will ignore the text between
> "---" and the diff, so you can write comments for the reviewers there
> without creating noise in the commit message.
> Also, please keep reviewers in the Cc list for future discussion/patches
> so that they will see them.
> -- 
> Thomas Rast
> t...@thomasrast.ch

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to