Re: Git: new feature suggestion

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

 



On Wed, Jan 18, 2017 at 2:40 AM, Joao Pinto <Joao.Pinto@xxxxxxxxxxxx> wrote:
> Hello,
>
> My name is Joao Pinto, I work at Synopsys and I am a frequent Linux Kernel
> contributor.
>
> Let me start by congratulate you for the fantastic work you have been doing with
> Git which is an excellent tool.
>
> The Linux Kernel as all systems needs to be improved and re-organized to be
> better prepared for future development and sometimes we need to change
> folder/files names or even move things around.
> I have seen a lot of Linux developers avoid this re-organization operations
> because they would lose the renamed file history, because a new log is created
> for the new file, even if it is a renamed version of itself.

Well there are a couple of things to help with digging in the logs.

git log:
       --follow
           Continue listing the history of a file beyond renames (works only
           for a single file).

        -M[<n>], --find-renames[=<n>]
           If generating diffs, detect and report renames for each commit. For
           following files across renames while traversing history, see
           --follow. If n is specified, it is a threshold on the similarity
           index (i.e. amount of addition/deletions compared to the file’s
           size). For example, -M90% means Git should consider a delete/add
           pair to be a rename if more than 90% of the file hasn’t changed.
           Without a % sign, the number is to be read as a fraction, with a
           decimal point before it. I.e., -M5 becomes 0.5, and is thus the
           same as -M50%. Similarly, -M05 is the same as -M5%. To limit
           detection to exact renames, use -M100%. The default similarity
           index is 50%.

       -C[<n>], --find-copies[=<n>]
           Detect copies as well as renames. See also --find-copies-harder. If
           n is specified, it has the same meaning as for -M<n>.



> I am sending you this e-mail to suggest the creation of a new feature in Git:
> when renamed, a file or folder should inherit his parent’s log and a “rename: …”
> would be automatically created or have some kind of pointer to its “old” form to
> make history analysis easier.

How do you currently analyse history, which detailed feature is missing?

Mind that in the Git data model we deliberately do not record the rename
at commit time, but rather want to identify the renames at log time.
This is because
in the meantime between commit and log viewing someone could have written
a better rename detection, whereas at commit time we'd be stuck with ancient
cruft forever. ;)

>
> I volunteer to help in the new feature if you find it useful. I think it would
> improve log history analysis and would enable developers to better organize old
> code.

IMHO complete renames (i.e. git mv path/a/file.c path/b/thing.c) are already
covered quite well. Partial rename (e.g. moving code from one file into two
separate files or vice versa) is still a bit hard.

I started such a new feature, see
https://public-inbox.org/git/20160903033120.20511-1-sbeller@xxxxxxxxxx/
latest code is at https://github.com/stefanbeller/git/commits/colored_diff12,
but the latest two commits are bogus and need rewriting.

I think this feature is not 100% what you are aiming at, but is very close.

Thanks,
Stefan




[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]