On 05/27/14 15:00, Gabriel L. Somlo wrote: > On Mon, May 26, 2014 at 08:30:48AM +0200, Markus Armbruster wrote: >>> >>> So I was about to send a patch with acpi-test.c renamed to >>> bios-tables-test.c, but the patch is basically removing all of >>> acpi-test.c, and creating a new file bios-tables-test.c. >> >> Err, isn't that what a rename does? > > Being somewhere in the middle of the Git learning curve, to me a > rename mostly means editing a string in a filesystem directory entry, > without touching the actual content :) > >>> Do you have a better way to rename the file first, and then I can >>> send a patch against it ? Or should we give up on renaming it >>> altogether ? Or should I just bite the bullet and cut'n'paste your >>> test harness into a new file specific to smbios ? >>> >>> It's not particularly important to me which way we go -- I want to do >>> the right thing, whatever you decide that is :) >> >> Did you rename with git-mv? Did you diff with rename detection on? See >> diff.renames in git-config(1). > > Aaaah, that's what I was missing! This makes for a much more > "articulate" looking patch (which I'll be sending out shortly) :)
(Side note: do this for projects that use git "natively"; don't do it for projects that will want to apply the patch in SVN too (or even primarily), eg. edk2. SVN chokes on git rename directives. Side note #2: ratcheting up the "diff.renameLimit" setting will make your cherry-picks and rebases take much more CPU hungry (potentially), but they will also recognize renames over much longer histories, and save you many manual conflict resolutions. See <https://blogs.atlassian.com/2011/10/confluence_git_rename_merge_oh_my/>.) Thanks Laszlo
