{"thread":{"id":"26985","subject":"p4Merge bundled command and the behaviour with files (same name) added on different branches.","startedAt":"2011-04-04T08:55:41Z","lastAt":"2011-04-07T09:48:55Z","messageCount":3,"participants":["Ciaran","David Aguilar"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"165097","messageId":"BANLkTimpsg=26C0mq=feVT7mt0nwZBoBUA@mail.gmail.com","threadId":"26985","inReplyTo":null,"subject":"p4Merge bundled command and the behaviour with files (same name) added on different branches.","fromName":"Ciaran","fromEmail":"ciaranj@gmail.com","sentAt":"2011-04-04T08:55:41Z","receivedAt":"2011-04-04T08:55:41Z","isPatch":false,"sender":{"key":"ciaranj@gmail.com","avatar":"https://avatars.githubusercontent.com/u/55368?v=4"},"body":"Hi All,\n\nHopefully a quick question.  Given the following scenario\n\nmkdir git_repo\ncd git_repo\ngit init\necho foo > foo.txt\ngit add foo.txt\ngit commit -m \"Initial commit\"\ngit checkout -b other\necho bar > bar.txt\ngit add bar.txt\ngit commit -m \"other commit\"\ngit checkout master\necho barbarella > bar.txt\ngit add bar.txt\ngit commit -m \"master commit\"\ngit merge other\n\nWe would expect a 'both added' merge conflict (both the other branch,\nand the master branch added the file named bar.txt, but with different\ncontent.)  This is all good and right.  So in a system configured to\nuse p4merge as the mergetool, one fires up with 'git mergetool'\n\nWhat happens now is p4merge starts and tells us:\n\nBase: bar.txt.LOCAL.<num1>.txt\nLeft: bar.txt.LOCAL.<num1>.txt Differences from base: 0\nRight: bar.txt.LOCAL.<num2>.txt Differences from base: 1\nMerge: bar.txt Conflicts:0\n\nPresenting the left + right options on top of each other in the result\nwindow (which may be correct) and leaving the save button disabled\n(grayed out)\n\nIf at this point one closes the window without editing the presented\n(apparently merged) file, then nothing will be saved to disk and we\nwill see:\n\nbar.txt seems unchanged.\nWas the merge successful? [y/n]\n\nIn the console.  Which Git wise is correct, that is exactly right, the\np4merge tool hasn't made any actual changes to the underlying file.\n\nThis behaviour seems confusing to me (the p4merge client behaviour,\n*not* Git's)   I believe it is because in the case where there is no\nlogical base between two files the local one is arbritrarily chosen,\nand p4merge *thinks* that this is equal to the merge result and has\nnothing to persist.\n\nI have attached a patch that resolves the issue for me (e.g.\nintroduces the behaviour I expect) by passing a reference to an empty\nfile in the case where there is no meaningful base.  Unfortunately I\ndon't understand enough to say whether this change is correct or not\nand would value feedback on it.\n\nMany thanks\n - Cj.\n\n\nFrom 8eb507ac86f952bf4700d94caa361b1632ab01a6 Mon Sep 17 00:00:00 2001\nFrom: ciaranj <ciaranj@gmail.com>\nDate: Mon, 4 Apr 2011 09:24:18 +0100\nSubject: [PATCH] Modified the p4merge client command to pass a reference to an empty file instead of the local file when no base revision available.\n\nIn the situation where a merge tries to add a file from one branch into a branch that already contains that file (by name), p4merge\ncurrently seems to have successfully automatically resolved the 'conflict' when it is opened (correctly if the files differed by\njust whitespace for example) but leaves the save button disabled. This means the user of the p4merge client cannot commit the resolved\nchanges back to disk and merely exits, leaving the original (merge-conflicted) file in-tact on the disk.\n\nIf the user is not paying attention this file can get committed :(\n\nWith this change, p4merge appears to behave far more as expected, for example leaving the save button enabled allowing one to save the\nresolved file to disk.\n---\n git-mergetool--lib.sh |    4 +++-\n 1 files changed, 3 insertions(+), 1 deletions(-)\n\ndiff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh\nindex fb3f52b..3e486dc 100644\n--- a/git-mergetool--lib.sh\n+++ b/git-mergetool--lib.sh\n@@ -262,7 +262,9 @@ run_merge_tool () {\n \t\t\tif $base_present; then\n \t\t\t\t\"$merge_tool_path\" \"$BASE\" \"$LOCAL\" \"$REMOTE\" \"$MERGED\"\n \t\t\telse\n-\t\t\t\t\"$merge_tool_path\" \"$LOCAL\" \"$LOCAL\" \"$REMOTE\" \"$MERGED\"\n+\t\t\t\ttouch \".empty\"\n+\t\t\t\t\"$merge_tool_path\" \".empty\" \"$LOCAL\" \"$REMOTE\" \"$MERGED\"\n+\t\t\t\trm \".empty\"\n \t\t\tfi\n \t\t\tcheck_unchanged\n \t\telse\n-- \n1.7.3.4\n\n"},{"id":"165345","messageId":"20110407094347.GB7593@gmail.com","threadId":"26985","inReplyTo":"BANLkTimpsg=26C0mq=feVT7mt0nwZBoBUA@mail.gmail.com","subject":"Re: p4Merge bundled command and the behaviour with files (same name) added on different branches.","fromName":"David Aguilar","fromEmail":"davvid@gmail.com","sentAt":"2011-04-07T09:43:49Z","receivedAt":"2011-04-07T09:43:49Z","isPatch":false,"sender":{"key":"davvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13196?v=4"},"body":"On Mon, Apr 04, 2011 at 09:55:41AM +0100, Ciaran wrote:\n> [...]\n> We would expect a 'both added' merge conflict (both the other branch,\n> and the master branch added the file named bar.txt, but with different\n> content.)  This is all good and right.  So in a system configured to\n> use p4merge as the mergetool, one fires up with 'git mergetool'\n> \n> What happens now is p4merge starts and tells us:\n> \n> Base: bar.txt.LOCAL.<num1>.txt\n> Left: bar.txt.LOCAL.<num1>.txt Differences from base: 0\n> Right: bar.txt.LOCAL.<num2>.txt Differences from base: 1\n> Merge: bar.txt Conflicts:0\n> \n> Presenting the left + right options on top of each other in the result\n> window (which may be correct) and leaving the save button disabled\n> (grayed out)\n> \n> If at this point one closes the window without editing the presented\n> (apparently merged) file, then nothing will be saved to disk and we\n> will see:\n> \n> bar.txt seems unchanged.\n> Was the merge successful? [y/n]\n> \n> In the console.  Which Git wise is correct, that is exactly right, the\n> p4merge tool hasn't made any actual changes to the underlying file.\n> \n> This behaviour seems confusing to me (the p4merge client behaviour,\n> *not* Git's)   I believe it is because in the case where there is no\n> logical base between two files the local one is arbritrarily chosen,\n> and p4merge *thinks* that this is equal to the merge result and has\n> nothing to persist.\n> \n> I have attached a patch that resolves the issue for me (e.g.\n> introduces the behaviour I expect) by passing a reference to an empty\n> file in the case where there is no meaningful base.  Unfortunately I\n> don't understand enough to say whether this change is correct or not\n> and would value feedback on it.\n> \n> Many thanks\n>  - Cj.\n\nThanks.  If this patch were for actual consideration you would\ninline the patch instead of sending an attachment as described\nin Documentation/SubmittingPatches.  Marking the subject line\nwith \"[RFC PATCH]\" lets us know that you're interested in\nfeedback.  I have a few questions below.\n\n> index fb3f52b..3e486dc 100644\n> --- a/git-mergetool--lib.sh\n> +++ b/git-mergetool--lib.sh\n> @@ -262,7 +262,9 @@ run_merge_tool () {\n>  \t\t\tif $base_present; then\n>  \t\t\t\t\"$merge_tool_path\" \"$BASE\" \"$LOCAL\" \"$REMOTE\" \"$MERGED\"\n>  \t\t\telse\n> -\t\t\t\t\"$merge_tool_path\" \"$LOCAL\" \"$LOCAL\" \"$REMOTE\" \"$MERGED\"\n> +\t\t\t\ttouch \".empty\"\n> +\t\t\t\t\"$merge_tool_path\" \".empty\" \"$LOCAL\" \"$REMOTE\" \"$MERGED\"\n> +\t\t\t\trm \".empty\"\n>  \t\t\tfi\n>  \t\t\tcheck_unchanged\n>  \t\telse\n> -- \n\nWhat if the user has a file called '.empty' in their repository?\n\nWhat if the user Ctrl-C's out of mergetool -- does a stale\n.empty file get left behind?\n\nDoes it work if we pass /dev/null instead?\nIs such a strategy portable to Windows?\n\nIf /dev/null doesn't work, would it be better if the\nempty file were given a different name?\nMaybe something like foo.EMPTY.<num>.txt?\n-- \n\t\tDavid\n"},{"id":"165346","messageId":"BANLkTik0HnV9+436dt=c0yKQb0KxpbgGGg@mail.gmail.com","threadId":"26985","inReplyTo":"20110407094347.GB7593@gmail.com","subject":"Re: p4Merge bundled command and the behaviour with files (same name) added on different branches.","fromName":"Ciaran","fromEmail":"ciaranj@gmail.com","sentAt":"2011-04-07T09:48:55Z","receivedAt":"2011-04-07T09:48:55Z","isPatch":false,"sender":{"key":"ciaranj@gmail.com","avatar":"https://avatars.githubusercontent.com/u/55368?v=4"},"body":"On Thu, Apr 7, 2011 at 10:43 AM, David Aguilar <davvid@gmail.com> wrote:\n> On Mon, Apr 04, 2011 at 09:55:41AM +0100, Ciaran wrote:\n>> [...]\n>> We would expect a 'both added' merge conflict (both the other branch,\n>> and the master branch added the file named bar.txt, but with different\n>> content.)  This is all good and right.  So in a system configured to\n>> use p4merge as the mergetool, one fires up with 'git mergetool'\n>>\n>> What happens now is p4merge starts and tells us:\n>>\n>> Base: bar.txt.LOCAL.<num1>.txt\n>> Left: bar.txt.LOCAL.<num1>.txt Differences from base: 0\n>> Right: bar.txt.LOCAL.<num2>.txt Differences from base: 1\n>> Merge: bar.txt Conflicts:0\n>>\n>> Presenting the left + right options on top of each other in the result\n>> window (which may be correct) and leaving the save button disabled\n>> (grayed out)\n>>\n>> If at this point one closes the window without editing the presented\n>> (apparently merged) file, then nothing will be saved to disk and we\n>> will see:\n>>\n>> bar.txt seems unchanged.\n>> Was the merge successful? [y/n]\n>>\n>> In the console.  Which Git wise is correct, that is exactly right, the\n>> p4merge tool hasn't made any actual changes to the underlying file.\n>>\n>> This behaviour seems confusing to me (the p4merge client behaviour,\n>> *not* Git's)   I believe it is because in the case where there is no\n>> logical base between two files the local one is arbritrarily chosen,\n>> and p4merge *thinks* that this is equal to the merge result and has\n>> nothing to persist.\n>>\n>> I have attached a patch that resolves the issue for me (e.g.\n>> introduces the behaviour I expect) by passing a reference to an empty\n>> file in the case where there is no meaningful base.  Unfortunately I\n>> don't understand enough to say whether this change is correct or not\n>> and would value feedback on it.\n>>\n>> Many thanks\n>>  - Cj.\n>\n> Thanks.  If this patch were for actual consideration you would\n> inline the patch instead of sending an attachment as described\n> in Documentation/SubmittingPatches.  Marking the subject line\n> with \"[RFC PATCH]\" lets us know that you're interested in\n> feedback.  I have a few questions below.\nThank you for respnding, I wasn't sure on the etiquette (and quite\nfrankly nervous as it was about posting to the list ;) ), so please\naccept my apologies.\n\n>\n>> index fb3f52b..3e486dc 100644\n>> --- a/git-mergetool--lib.sh\n>> +++ b/git-mergetool--lib.sh\n>> @@ -262,7 +262,9 @@ run_merge_tool () {\n>>                       if $base_present; then\n>>                               \"$merge_tool_path\" \"$BASE\" \"$LOCAL\" \"$REMOTE\" \"$MERGED\"\n>>                       else\n>> -                             \"$merge_tool_path\" \"$LOCAL\" \"$LOCAL\" \"$REMOTE\" \"$MERGED\"\n>> +                             touch \".empty\"\n>> +                             \"$merge_tool_path\" \".empty\" \"$LOCAL\" \"$REMOTE\" \"$MERGED\"\n>> +                             rm \".empty\"\n>>                       fi\n>>                       check_unchanged\n>>               else\n>> --\n>\n> What if the user has a file called '.empty' in their repository?\nThen it will get over-written ;)\n\n>\n> What if the user Ctrl-C's out of mergetool -- does a stale\n> .empty file get left behind?\nYup, I imagine so.\n\n>\n> Does it work if we pass /dev/null instead?\n> Is such a strategy portable to Windows?\nI don't think so, that was my first try (in Windows.)\n\n>\n> If /dev/null doesn't work, would it be better if the\n> empty file were given a different name?\n> Maybe something like foo.EMPTY.<num>.txt?\nI'm amenable to anything.   My patch was really an example, hoping to\nprompt a conversation with someone who actually knows the working of\ngit / mergetool-lib :)\n\nPresumably I can co-opt whatever logic drives the existing\nlocal/remote/merged temporary file names to create an 'empty' filename\nin the temporary folder, since this file will always be identical it\nshouldn't matter if it hangs around/gets updated con-currently etc. ?\n\nThanks\n- Cj.\n\n> --\n>                David\n>\n"}]}