Re: [PATCH 3/7] diff: add --rename-file

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Nguyễn Thái Ngọc Duy  <pclouds@xxxxxxxxx> writes:

> Git's heuristics to detect renames or copies works most of the time.
> This option can be used to correct the result when it goes wrong.
> Matching pairs get max rename score and override even exact rename
> detection.
>
> Note that --rename-file does not try to break existing diff pairs. So
> if you have "abc => def" in your file, but they are already paired up
> (e.g. "abc => abc" and "def => def") and not broken down by -B, then
> nothing happens.
>
> An assumption is made in this patch, that the rename file only contains
> a couple rename pairs, not thousands of them. Looping through all
> rename source and destination for each rename line will not affect
> performance and we can keep the code simple.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx>
> ---

> +--rename-file=<path>::
> +	The given file contains explicit rename pairs that override
> +	automatic detected renames. Each line contains a rename pair
> +	in the following format:
> ++
> +<source path> <space> "=>" <space> <destination path>
> +

Obviously this needs path-quoting support before it can get anywhere
near 'next', but I found the basic idea outlined in the change in
diffcore-rename.c in this patch OK.  The manual one comes even
before the "look for identical ones" step, which is logically the
right thing to do.

One small nit is that using MAX_SCORE may have unintended fallouts.
The manually specified one is chosen among rename candidates not
because it has the highest similarity score---it in fact may not
have a good similarity score at all, but we pair the paths because
the user tells us to (and the user knows better than we do).

I am just wondering if it is easy to make the similarity score shown
at the beginning of diff displayed differently.  For manually paired
paths, we can and should keep "rename from OLDPATH" and "rename to
NEWPATH" entries, but I think "similarity index 100%" should ideally
be not shown for them, and if we have to have the line (e.g. perhaps
existing tools expect a line that begins with "similarity index" to
exist), show something like "similarity index N/A" that is clearly
different from "100%".

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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]