On Wed, Jan 18, 2017 at 2:40 AM, Joao Pinto <joao.pi...@synopsys.com> 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-sbel...@google.com/
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
