Hi Stefan, Às 6:50 PM de 1/18/2017, Stefan Beller escreveu: > 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://urldefense.proofpoint.com/v2/url?u=https-3A__public-2Dinbox.org_git_20160903033120.20511-2D1-2Dsbeller-40google.com_&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0&m=BseICq5hy9UHxmX2XP8oPYLbn-HoEUlEuVUzqPHkX58&s=PybtKK0ELH3Nld_CQSYZnLqCQOWvnU4Fjj5iV_7EKqE&e= > latest code is at https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_stefanbeller_git_commits_colored-5Fdiff12&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=s2fO0hii0OGNOv9qQy_HRXy-xAJUD1NNoEcc3io_kx0&m=BseICq5hy9UHxmX2XP8oPYLbn-HoEUlEuVUzqPHkX58&s=pkTehcEmeHVLHdcNbUiU03meyH10cgUbGqLgOqXcL6w&e= , > 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 > Great info, helps a lot! I am going to analyse and get back to you ASAP. Thanks