{"thread":{"id":"51581","subject":"Re: [patch 16/17] memremap: move from kernel/ to mm/","startedAt":"2019-08-03T18:22:23Z","lastAt":"2019-08-03T18:22:23Z","messageCount":1,"participants":["Linus Torvalds"],"isPatch":true,"patchVersion":1,"patchTotal":17},"messages":[{"id":"379882","messageId":"CAHk-=whUHq7NGM6e7pCkMOaqKhzv9mqE8+JGJPbY=PPATV9mbA@mail.gmail.com","threadId":"51581","inReplyTo":"20190803102425.49d5810179e06590ab14c748@linux-foundation.org","subject":"Re: [patch 16/17] memremap: move from kernel/ to mm/","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2019-08-03T18:21:59Z","receivedAt":"2019-08-03T18:22:23Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"[ Adding git people due to\n\nOn Sat, Aug 3, 2019 at 10:24 AM Andrew Morton <akpm@linux-foundation.org> wrote:\n>\n> Aside.  I guess renames are just a wee bit dangerous.  There's no\n> guarantee that the file which you rename is exactly the same as the one\n> which I renamed, which could result in breakage.  Such as, ummm, if\n> some intervening patch had added a #include \"foo.h\".  Maybe the rename\n> instructions should include a hash.\n\nIt turns out that renames that have changes _do_ include the object ID\nfor both sides, but exact renames do not. I guess that's technically a\ndeficiency in git.\n\nA pure rename with no changes looks like this:\n\n  diff --git a/kernel/memremap.c b/mm/memremap.c\n  similarity index 100%\n  rename from kernel/memremap.c\n  rename to mm/memremap.c\n\nso you see that it's a rename, but there's no way to actually see what\nthe *contents* at the point of the rename were.\n\nIn contrast, a rename with changes might look like this:\n\n  diff --git a/.../intel,ixp4xx-queue-manager.yaml\nb/.../intel,ixp4xx-ahb-queue-manager.yaml\n  similarity index 95%\n  rename from .../intel,ixp4xx-queue-manager.yaml\n  rename to .../intel,ixp4xx-ahb-queue-manager.yaml\n  index d2313b1d9405..0ea21a6f70b4 100644\n  --- a/.../intel,ixp4xx-queue-manager.yaml\n  +++ b/.../intel,ixp4xx-ahb-queue-manager.yaml\n  @@ -2,7 +2,7 @@\n   # Copyright 2019 Linaro Ltd.\n   %YAML 1.2\n   ---\n  -$id: \"http://devicetree.org/schemas/misc/intel-ixp4xx-ahb-queue-manager.yaml#\"\n  +$id: \"http://devicetree.org/schemas/misc/intel,ixp4xx-ahb-queue-manager.yaml#\"\n   $schema: \"http://devicetree.org/meta-schemas/core.yaml#\"\n\n   title: Intel IXP4xx AHB Queue Manager\n\nso when the rename wasn't exact, we do show the index line so that you\ncan verify the exact content of the file as it was renamed.\n\nOf course, I doubt your quilt scripts look at the index anyway, and\nthis is (I think) the first time this has come up as a potential\nissue.\n\nBut you are correct that it would probably be a good idea to have an\nindex line for the identical file case too.\n\nAdding Junio and the git list to the cc, in case anybody has ideas and\ncares.. I don't think this is a big issue, this is more of a \"let's cc\npeople so that they know it got mentioned\".\n\n>     But I can see that the present\n> \"rename it while ignoring other stuff which happened\" is kinda neat.\n\nIt's very convenient indeed. That said, in an all-git environment, a\nrename is basically never really treated as a patch, so when you do\n*merges* with renames, it does take changes into account and give you\na \"conflict\".\n\nAlthough generally it will then resolve those conflicts for you\nautomatically (and if the renaming side made no changes that will be\nvisible as the same object ID, the end result of the automatic merge\nresolution is that the rename is just done with the change from the\nother side in place).\n\nHonestly, I very seldom see any issues with pure renames. The issues\nwe _do_ see is when somebody renames a file and then does a lot of\nchanges (often because they also then rename the variables in the file\nbecause the rename was some bigger \"coneptual\" rename) and then any\nconflicts with other changes can be very nasty indeed to sort out.\n\nPlain \"just move a file\" situations tend to be very simple. Yes, it\n_can_ cause subtle issues, but in practice it never really does. No\nmore than any other \"two people change a file differently\", at least.\n\nThe big advantage of renames in diffs is that it makes it _so_ much\neasier for humans to see what is going on. It's almost impossible for\na human to see that it's a pure rename when you see multiple hundreds\nof lines being deleted and added, while a rename patch is really easy\nfor humans to understand when they look at a patch like this.\n\n             Linus\n"}]}