Yoshioka Tsuneo writes:
> And, it might be a bit nicer for me if the patch can be
> rejected(or ignored as other patches) from the beginning if the
> concept does not fit anyway.
Yes, but...
> # Though I know we can know more after seeing the implementation, anyway :-)
... you are very correct
Hello Junio
Thank you for your comment.
> but this patch will show the
> source and the destination paths, both of which are truncated even
> more severely, because it always has to spend display columns for an
> extra "..." (to show truncation of the source side), " => " (to show
> that it is a
Yoshioka Tsuneo writes:
> Also, I guess Junio might be suspicious to the idea to keep arrow("=>")
> itself, maybe ?
I think there is no single "right" solution to this issue, and it
has to boils down to the taste.
When you are viewing "diff --stat -M" output in wide-enough medium,
you are seei
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, 's basename part is tried to kept. On v7, whole part is tried
to kept.
For example, in case below:
parent_path{sourceDirectory =>
DestinationDirectory}path
Yoshioka Tsuneo 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 filen
"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 to
6 matches
Mail list logo