{"thread":{"id":"864","subject":"[RFC] rename/rename conflicts: do they matter?","startedAt":"2005-06-08T17:21:43Z","lastAt":"2005-06-09T00:34:15Z","messageCount":2,"participants":["Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"4708","messageId":"7vll5k69y0.fsf@assigned-by-dhcp.cox.net","threadId":"864","inReplyTo":null,"subject":"[RFC] rename/rename conflicts: do they matter?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-06-08T17:21:43Z","receivedAt":"2005-06-08T17:21:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"I was reviewing git-merge-one-file-script, and started\nthinking...\n\nIt currently has a logic that says if both branches deleted the\nsame file, instead of taking that as a concensus to remove it,\nit refuses to merge the path.  The error message states \"This is a\npotential rename conflict.\" as the rationale for doing so.  It\nis trying to be careful about one branch renaming the file to\nsomething while the other renaming it to something else.\n\nHowever, it happily deletes \"deleted in one and unchanged in the\nother\".  If we are so careful about \"rename/rename conflicts\", I\nwould think it would make more sense to be careful to consider\nthe possibility that one branch renamed this file, thereby\ncreating a copy at another path, while the other branch kept it\nintact (the other side of this operation is \"added in one\"), but\nwe do not seem to bother worrying about it.  If we try to be\nanal about this, then even a simple \"added in one\" case could\ntrigger \"copy/copy\" conflict.\n\nMy current thinking is that the current logic for \"both delete\"\nis too anal, and we should treat this case just like other\n\"concensus\" cases; simply removing the path in this case would\nbe better.\n\n"},{"id":"4737","messageId":"7v4qc81i7s.fsf@assigned-by-dhcp.cox.net","threadId":"864","inReplyTo":"7vll5k69y0.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC] rename/rename conflicts: do they matter?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-06-09T00:34:15Z","receivedAt":"2005-06-09T00:34:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"JCH\" == Junio C Hamano <junkio@cox.net> writes:\n\nJCH> I was reviewing git-merge-one-file-script, and started\nJCH> thinking...\n\nBut somehow I got underwhelming responses.\n\nI further think the \"WARNING: \" below is needlessly eating one\nextra line of screen real estate without any additional value.\n\nIf one tree renamed a file (and creating the same or similar\nfile in another location) while the other tree kept the file\nintact, then we would see \"Removing $4\" from the \"deleted in one\nand unchanged in the other\" (and corresponding \"Adding $4 with\nperm $mode\" for the rename destination).  If the user wants to\nbe careful about renames then all \"Removing ...\" need to be\nexamined _anyway_.  I would think it would be saner to collapse\nthese two case arms to catch \"$1..\" | \"$1.$1\" | \"$1$1.\"  pattern\nand just say \"Removing $4\".\n\n    case \"${1:-.}${2:-.}${3:-.}\" in\n    #\n    # Deleted in both.\n    #\n    \"$1..\")\n            echo \"WARNING: $4 is removed in both branches.\"\n            echo \"WARNING: This is a potential rename conflict.\"\n            rm -f -- \"$4\" &&\n                    exec git-update-cache --remove -- \"$4\"\n            ;;\n\n    #\n    # Deleted in one and unchanged in the other.\n    #\n    \"$1.$1\" | \"$1$1.\")\n            echo \"Removing $4\"\n            exec rm -f -- \"$4\" &&\n                    git-update-cache --remove -- \"$4\"\n            ;;\n\n\n"}]}