{"thread":{"id":"41282","subject":"[PATCH] mergetool: reorder vim/gvim buffers in three-way diffs","startedAt":"2016-01-29T02:18:14Z","lastAt":"2016-02-12T18:15:07Z","messageCount":12,"participants":["Dickson Wong","Junio C Hamano","Michael J Gruber","David Aguilar"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"277028","messageId":"1454033894-49954-1-git-send-email-dicksonwong@gmail.com","threadId":"41282","inReplyTo":null,"subject":"[PATCH] mergetool: reorder vim/gvim buffers in three-way diffs","fromName":"Dickson Wong","fromEmail":"dicksonwong@gmail.com","sentAt":"2016-01-29T02:18:14Z","receivedAt":"2016-01-29T02:18:14Z","isPatch":true,"sender":{"key":"dicksonwong@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5284055?v=4"},"body":"When invoking default (g)vimdiff three-way merge, the merged file is\nloaded as the first buffer but moved to the bottom as the fourth window.\nThis causes a disconnect between vim commands that operate on window\npositions (e.g. CTRL-W_w) and those that operate on buffer index (e.g.\ndo/dp).\n\nThis change reorders the buffers to have the same index as windows while\nkeeping the cursor default to the merged result as the bottom window.\n\nSigned-off-by: Dickson Wong \n---\n mergetools/vimdiff | 4 ++--\n 1 file changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/mergetools/vimdiff b/mergetools/vimdiff\nindex 1ddfbfc..74ea6d5 100644\n--- a/mergetools/vimdiff\n+++ b/mergetools/vimdiff\n@@ -2,22 +2,22 @@ diff_cmd () {\n \t\"$merge_tool_path\" -R -f -d \\\n \t\t-c 'wincmd l' -c 'cd $GIT_PREFIX' \"$LOCAL\" \"$REMOTE\"\n }\n \n merge_cmd () {\n \ttouch \"$BACKUP\"\n \tcase \"$1\" in\n \tgvimdiff|vimdiff)\n \t\tif $base_present\n \t\tthen\n-\t\t\t\"$merge_tool_path\" -f -d -c 'wincmd J' \\\n-\t\t\t\t\"$MERGED\" \"$LOCAL\" \"$BASE\" \"$REMOTE\"\n+\t\t\t\"$merge_tool_path\" -f -d -c '4wincmd w | wincmd J' \\\n+\t\t\t\t\"$LOCAL\" \"$BASE\" \"$REMOTE\" \"$MERGED\"\n \t\telse\n \t\t\t\"$merge_tool_path\" -f -d -c 'wincmd l' \\\n \t\t\t\t\"$LOCAL\" \"$MERGED\" \"$REMOTE\"\n \t\tfi\n \t\t;;\n \tgvimdiff2|vimdiff2)\n \t\t\"$merge_tool_path\" -f -d -c 'wincmd l' \\\n \t\t\t\"$LOCAL\" \"$MERGED\" \"$REMOTE\"\n \t\t;;\n \tgvimdiff3|vimdiff3)\n-- \n2.6.2\n"},{"id":"277057","messageId":"xmqq1t90jkcr.fsf@gitster.mtv.corp.google.com","threadId":"41282","inReplyTo":"1454033894-49954-1-git-send-email-dicksonwong@gmail.com","subject":"Re: [PATCH] mergetool: reorder vim/gvim buffers in three-way diffs","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-01-29T18:45:08Z","receivedAt":"2016-01-29T18:45:08Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Dickson Wong writes:\n\n> When invoking default (g)vimdiff three-way merge, the merged file is\n> loaded as the first buffer but moved to the bottom as the fourth window.\n> This causes a disconnect between vim commands that operate on window\n> positions (e.g. CTRL-W_w) and those that operate on buffer index (e.g.\n> do/dp).\n>\n> This change reorders the buffers to have the same index as windows while\n> keeping the cursor default to the merged result as the bottom window.\n>\n> Signed-off-by: Dickson Wong \n> ---\n\nDavid, I unfortunately do not use 'mergetools' myself and certainly\nnot vimdiff.\n\nOpinions?\n\n> mergetools/vimdiff | 4 ++--\n> 1 file changed, 2 insertions(+), 2 deletions(-)\n>\n> diff --git a/mergetools/vimdiff b/mergetools/vimdiff\n> index 1ddfbfc..74ea6d5 100644\n> --- a/mergetools/vimdiff\n> +++ b/mergetools/vimdiff\n> @@ -2,22 +2,22 @@ diff_cmd () {\n> \t\"$merge_tool_path\" -R -f -d \\\n> \t\t-c 'wincmd l' -c 'cd $GIT_PREFIX' \"$LOCAL\" \"$REMOTE\"\n> }\n> \n> merge_cmd () {\n> \ttouch \"$BACKUP\"\n> \tcase \"$1\" in\n> \tgvimdiff|vimdiff)\n> \t\tif $base_present\n> \t\tthen\n> -\t\t\t\"$merge_tool_path\" -f -d -c 'wincmd J' \\\n> -\t\t\t\t\"$MERGED\" \"$LOCAL\" \"$BASE\" \"$REMOTE\"\n> +\t\t\t\"$merge_tool_path\" -f -d -c '4wincmd w | wincmd J' \\\n> +\t\t\t\t\"$LOCAL\" \"$BASE\" \"$REMOTE\" \"$MERGED\"\n> \t\telse\n> \t\t\t\"$merge_tool_path\" -f -d -c 'wincmd l' \\\n> \t\t\t\t\"$LOCAL\" \"$MERGED\" \"$REMOTE\"\n> \t\tfi\n> \t\t;;\n> \tgvimdiff2|vimdiff2)\n> \t\t\"$merge_tool_path\" -f -d -c 'wincmd l' \\\n> \t\t\t\"$LOCAL\" \"$MERGED\" \"$REMOTE\"\n> \t\t;;\n> \tgvimdiff3|vimdiff3)\n"},{"id":"277840","messageId":"xmqqr3gl1pyw.fsf@gitster.mtv.corp.google.com","threadId":"41282","inReplyTo":"xmqq1t90jkcr.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH] mergetool: reorder vim/gvim buffers in three-way diffs","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-02-09T22:25:11Z","receivedAt":"2016-02-09T22:25:11Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Dickson Wong writes:\n>\n>> When invoking default (g)vimdiff three-way merge, the merged file is\n>> loaded as the first buffer but moved to the bottom as the fourth window.\n>> This causes a disconnect between vim commands that operate on window\n>> positions (e.g. CTRL-W_w) and those that operate on buffer index (e.g.\n>> do/dp).\n>>\n>> This change reorders the buffers to have the same index as windows while\n>> keeping the cursor default to the merged result as the bottom window.\n>>\n>> Signed-off-by: Dickson Wong \n>> ---\n>\n> David, I unfortunately do not use 'mergetools' myself and certainly\n> not vimdiff.\n>\n> Opinions?\n\nSecond call for help. Any comments on this from anybody other than\nthe author that I missed to support this change?\n\n>\n>> mergetools/vimdiff | 4 ++--\n>> 1 file changed, 2 insertions(+), 2 deletions(-)\n>>\n>> diff --git a/mergetools/vimdiff b/mergetools/vimdiff\n>> index 1ddfbfc..74ea6d5 100644\n>> --- a/mergetools/vimdiff\n>> +++ b/mergetools/vimdiff\n>> @@ -2,22 +2,22 @@ diff_cmd () {\n>> \t\"$merge_tool_path\" -R -f -d \\\n>> \t\t-c 'wincmd l' -c 'cd $GIT_PREFIX' \"$LOCAL\" \"$REMOTE\"\n>> }\n>> \n>> merge_cmd () {\n>> \ttouch \"$BACKUP\"\n>> \tcase \"$1\" in\n>> \tgvimdiff|vimdiff)\n>> \t\tif $base_present\n>> \t\tthen\n>> -\t\t\t\"$merge_tool_path\" -f -d -c 'wincmd J' \\\n>> -\t\t\t\t\"$MERGED\" \"$LOCAL\" \"$BASE\" \"$REMOTE\"\n>> +\t\t\t\"$merge_tool_path\" -f -d -c '4wincmd w | wincmd J' \\\n>> +\t\t\t\t\"$LOCAL\" \"$BASE\" \"$REMOTE\" \"$MERGED\"\n>> \t\telse\n>> \t\t\t\"$merge_tool_path\" -f -d -c 'wincmd l' \\\n>> \t\t\t\t\"$LOCAL\" \"$MERGED\" \"$REMOTE\"\n>> \t\tfi\n>> \t\t;;\n>> \tgvimdiff2|vimdiff2)\n>> \t\t\"$merge_tool_path\" -f -d -c 'wincmd l' \\\n>> \t\t\t\"$LOCAL\" \"$MERGED\" \"$REMOTE\"\n>> \t\t;;\n>> \tgvimdiff3|vimdiff3)\n"},{"id":"277863","messageId":"56BB4BDF.3010407@drmicha.warpmail.net","threadId":"41282","inReplyTo":"xmqqr3gl1pyw.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH] mergetool: reorder vim/gvim buffers in three-way diffs","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2016-02-10T14:40:31Z","receivedAt":"2016-02-10T14:40:31Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Junio C Hamano venit, vidit, dixit 09.02.2016 23:25:\n> Junio C Hamano writes:\n> \n>> Dickson Wong writes:\n>>\n>>> When invoking default (g)vimdiff three-way merge, the merged file is\n>>> loaded as the first buffer but moved to the bottom as the fourth window.\n>>> This causes a disconnect between vim commands that operate on window\n>>> positions (e.g. CTRL-W_w) and those that operate on buffer index (e.g.\n>>> do/dp).\n>>>\n>>> This change reorders the buffers to have the same index as windows while\n>>> keeping the cursor default to the merged result as the bottom window.\n>>>\n>>> Signed-off-by: Dickson Wong \n>>> ---\n>>\n>> David, I unfortunately do not use 'mergetools' myself and certainly\n>> not vimdiff.\n>>\n>> Opinions?\n> \n> Second call for help. Any comments on this from anybody other than\n> the author that I missed to support this change?\n> \n\nOK, applied it (on top of next), looks sane and improves the situation\nfor the majority of people who read left to right, then top down and\nassign buffers 1 2 3 4 \"mentally\" to local base remote merge windows\nbased on that. Their expectation is met now. Thanks!\n\n(Also, the other vim variants don't need a corresponding change.)\n\nMichael\n\n>>\n>>> mergetools/vimdiff | 4 ++--\n>>> 1 file changed, 2 insertions(+), 2 deletions(-)\n>>>\n>>> diff --git a/mergetools/vimdiff b/mergetools/vimdiff\n>>> index 1ddfbfc..74ea6d5 100644\n>>> --- a/mergetools/vimdiff\n>>> +++ b/mergetools/vimdiff\n>>> @@ -2,22 +2,22 @@ diff_cmd () {\n>>> \t\"$merge_tool_path\" -R -f -d \\\n>>> \t\t-c 'wincmd l' -c 'cd $GIT_PREFIX' \"$LOCAL\" \"$REMOTE\"\n>>> }\n>>> \n>>> merge_cmd () {\n>>> \ttouch \"$BACKUP\"\n>>> \tcase \"$1\" in\n>>> \tgvimdiff|vimdiff)\n>>> \t\tif $base_present\n>>> \t\tthen\n>>> -\t\t\t\"$merge_tool_path\" -f -d -c 'wincmd J' \\\n>>> -\t\t\t\t\"$MERGED\" \"$LOCAL\" \"$BASE\" \"$REMOTE\"\n>>> +\t\t\t\"$merge_tool_path\" -f -d -c '4wincmd w | wincmd J' \\\n>>> +\t\t\t\t\"$LOCAL\" \"$BASE\" \"$REMOTE\" \"$MERGED\"\n>>> \t\telse\n>>> \t\t\t\"$merge_tool_path\" -f -d -c 'wincmd l' \\\n>>> \t\t\t\t\"$LOCAL\" \"$MERGED\" \"$REMOTE\"\n>>> \t\tfi\n>>> \t\t;;\n>>> \tgvimdiff2|vimdiff2)\n>>> \t\t\"$merge_tool_path\" -f -d -c 'wincmd l' \\\n>>> \t\t\t\"$LOCAL\" \"$MERGED\" \"$REMOTE\"\n>>> \t\t;;\n>>> \tgvimdiff3|vimdiff3)\n"},{"id":"277880","messageId":"xmqqlh6szcfk.fsf@gitster.mtv.corp.google.com","threadId":"41282","inReplyTo":"56BB4BDF.3010407@drmicha.warpmail.net","subject":"Re: [PATCH] mergetool: reorder vim/gvim buffers in three-way diffs","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-02-10T17:45:51Z","receivedAt":"2016-02-10T17:45:51Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber writes:\n\n>> Second call for help. Any comments on this from anybody other than\n>> the author that I missed to support this change?\n>\n> OK, applied it (on top of next), looks sane and improves the situation\n> for the majority of people who read left to right, then top down and\n> assign buffers 1 2 3 4 \"mentally\" to local base remote merge windows\n> based on that. Their expectation is met now. Thanks!\n\nThanks.\n\nDoes this mean that I should warn in the release notes that some\nexisting users might get their expectation broken but we are going\nahead anyway because we think most people read left to right and\nthen top down? I am OK with saying that--I just wanted to make sure\nwe know that it is what we are doing.\n\n> (Also, the other vim variants don't need a corresponding change.)\n\nA stupid question while I am here. What are these different\nvariants? When reviewing this patch for the first time I tried to\nfind where they are documented, but didn't spot anything.\n\nI can see from the code that vimdiff2 variant does not do anything\nspecial when it is doing a 3-way merge, but vimdiff3 variant does\nbehave differently when it has $BASE. It does not need a change\nlike this because it already arranges and numbers the windows\nsensibly (in other words, we can label this patch as aligning the\nbehaviour of vimdiff to that of vimdiff3)?\n\nThanks.\n\n> Michael\n>\n>>>\n>>>> mergetools/vimdiff | 4 ++--\n>>>> 1 file changed, 2 insertions(+), 2 deletions(-)\n>>>>\n>>>> diff --git a/mergetools/vimdiff b/mergetools/vimdiff\n>>>> index 1ddfbfc..74ea6d5 100644\n>>>> --- a/mergetools/vimdiff\n>>>> +++ b/mergetools/vimdiff\n>>>> @@ -2,22 +2,22 @@ diff_cmd () {\n>>>> \t\"$merge_tool_path\" -R -f -d \\\n>>>> \t\t-c 'wincmd l' -c 'cd $GIT_PREFIX' \"$LOCAL\" \"$REMOTE\"\n>>>> }\n>>>> \n>>>> merge_cmd () {\n>>>> \ttouch \"$BACKUP\"\n>>>> \tcase \"$1\" in\n>>>> \tgvimdiff|vimdiff)\n>>>> \t\tif $base_present\n>>>> \t\tthen\n>>>> -\t\t\t\"$merge_tool_path\" -f -d -c 'wincmd J' \\\n>>>> -\t\t\t\t\"$MERGED\" \"$LOCAL\" \"$BASE\" \"$REMOTE\"\n>>>> +\t\t\t\"$merge_tool_path\" -f -d -c '4wincmd w | wincmd J' \\\n>>>> +\t\t\t\t\"$LOCAL\" \"$BASE\" \"$REMOTE\" \"$MERGED\"\n>>>> \t\telse\n>>>> \t\t\t\"$merge_tool_path\" -f -d -c 'wincmd l' \\\n>>>> \t\t\t\t\"$LOCAL\" \"$MERGED\" \"$REMOTE\"\n>>>> \t\tfi\n>>>> \t\t;;\n>>>> \tgvimdiff2|vimdiff2)\n>>>> \t\t\"$merge_tool_path\" -f -d -c 'wincmd l' \\\n>>>> \t\t\t\"$LOCAL\" \"$MERGED\" \"$REMOTE\"\n>>>> \t\t;;\n>>>> \tgvimdiff3|vimdiff3)\n"},{"id":"277941","messageId":"56BCAC69.8030909@drmicha.warpmail.net","threadId":"41282","inReplyTo":"xmqqlh6szcfk.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH] mergetool: reorder vim/gvim buffers in three-way diffs","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2016-02-11T15:44:41Z","receivedAt":"2016-02-11T15:44:41Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Junio C Hamano venit, vidit, dixit 10.02.2016 18:45:\n> Michael J Gruber writes:\n> \n>>> Second call for help. Any comments on this from anybody other than\n>>> the author that I missed to support this change?\n>>\n>> OK, applied it (on top of next), looks sane and improves the situation\n>> for the majority of people who read left to right, then top down and\n>> assign buffers 1 2 3 4 \"mentally\" to local base remote merge windows\n>> based on that. Their expectation is met now. Thanks!\n> \n> Thanks.\n> \n> Does this mean that I should warn in the release notes that some\n> existing users might get their expectation broken but we are going\n> ahead anyway because we think most people read left to right and\n> then top down? I am OK with saying that--I just wanted to make sure\n> we know that it is what we are doing.\n\nI would claim that anyone who notices the difference in buffer numbering\nwould be positively surprised.\n\n>> (Also, the other vim variants don't need a corresponding change.)\n> \n> A stupid question while I am here. What are these different\n> variants? When reviewing this patch for the first time I tried to\n> find where they are documented, but didn't spot anything.\n> \n> I can see from the code that vimdiff2 variant does not do anything\n> special when it is doing a 3-way merge,\n\nIt is \"vimdiff\" without the base window.\n\n> but vimdiff3 variant does\n> behave differently when it has $BASE. It does not need a change\n> like this because it already arranges and numbers the windows\n> sensibly (in other words, we can label this patch as aligning the\n> behaviour of vimdiff to that of vimdiff3)?\n\ngit log mergetools/vimdiff3\ncommit 7c147b77d34f072c40b912fafba499727921fa6e\nAuthor: Felipe Contreras \nDate: Sun Apr 20 19:24:20 2014 -0500\n\n mergetools: add vimdiff3 mode\n\n It's similar to the default, except that the other windows are hidden.\n This ensures that removed/added colors are still visible on the main\n merge window, but the other windows not visible.\n\n Specially useful with merge.conflictstyle=diff3.\n\n\nI have to say I'm still not sure what it is about (even after trying it\nout, even with the conflictstyle config)).\n\nIn any case, the buffer numbering is not the same (it is local remote\nbase merge) but it doesn't matter in this case because only one window\nis displayed, so there is no visual association.\n\nMichael\n"},{"id":"277942","messageId":"xmqqbn7nxmhe.fsf@gitster.mtv.corp.google.com","threadId":"41282","inReplyTo":"56BCAC69.8030909@drmicha.warpmail.net","subject":"Re: [PATCH] mergetool: reorder vim/gvim buffers in three-way diffs","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-02-11T16:03:57Z","receivedAt":"2016-02-11T16:03:57Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber writes:\n\n>> Does this mean that I should warn in the release notes that some\n>> existing users might get their expectation broken but we are going\n>> ahead anyway because we think most people read left to right and\n>> then top down? I am OK with saying that--I just wanted to make sure\n>> we know that it is what we are doing.\n>\n> I would claim that anyone who notices the difference in buffer numbering\n> would be positively surprised.\n\nThanks. I, being a non-user of vim, was wondering if people who had\ntheir own user-defined commands (macros? and possibly short-cut keys\nto invoke them) built around the old (and odd) numbering need to\nadjust--in which case we may need to forewarn.\n\n> In any case, the buffer numbering is not the same (it is local remote\n> base merge) but it doesn't matter in this case because only one window\n> is displayed, so there is no visual association.\n\nOK, thanks.\n"},{"id":"277950","messageId":"CAB8-syo8dCjDfCH3gAFvC1cnuB-wm9hxtmVb1OhZ7NT0Pw+EbQ@mail.gmail.com","threadId":"41282","inReplyTo":"xmqqbn7nxmhe.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH] mergetool: reorder vim/gvim buffers in three-way diffs","fromName":"Dickson Wong","fromEmail":"dicksonwong@gmail.com","sentAt":"2016-02-11T19:24:07Z","receivedAt":"2016-02-11T19:24:07Z","isPatch":true,"sender":{"key":"dicksonwong@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5284055?v=4"},"body":"Thanks for looking into the patch.\n\n> Thanks. I, being a non-user of vim, was wondering if people who had\n> their own user-defined commands (macros? and possibly short-cut keys\n> to invoke them) built around the old (and odd) numbering need to\n> adjust--in which case we may need to forewarn.\n>\n\nVim buffers are not reorderable and windows are always numbered from\ntop-left to bottom-right. However, I can see someone who is familiar with\nthe old behavior issue a \"CTRL-W_K\" command to move the merged window from\nthe bottom to the top, making the merged window the first window and\nconsistent with buffer indexes. If they use this command after the patch,\nthe indexes would no longer be consistent. The command would most likely be\nissued manually and not through a vim startup script.\n"},{"id":"277951","messageId":"xmqqtwlfvyau.fsf@gitster.mtv.corp.google.com","threadId":"41282","inReplyTo":"CAB8-syo8dCjDfCH3gAFvC1cnuB-wm9hxtmVb1OhZ7NT0Pw+EbQ@mail.gmail.com","subject":"Re: [PATCH] mergetool: reorder vim/gvim buffers in three-way diffs","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-02-11T19:31:37Z","receivedAt":"2016-02-11T19:31:37Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Dickson Wong writes:\n\n> Thanks for looking into the patch.\n\nNo. Thank _you_ for contributing ;-)\n\n> Vim buffers are not reorderable and windows are always numbered from\n> top-left to bottom-right. However, I can see someone who is familiar with\n> the old behavior issue a \"CTRL-W_K\" command to move the merged window from\n> the bottom to the top, making the merged window the first window and\n> consistent with buffer indexes. If they use this command after the patch,\n> the indexes would no longer be consistent. The command would most likely be\n> issued manually and not through a vim startup script.\n\nSo it should suffice to mention it in the release notes as one\nbullet item that describes one positive change, among all other\nupdates described in a simlar way. And there is no special\n\"warnings for existing users\" necessary, I would say.\n\nThanks.\n"},{"id":"277954","messageId":"CAB8-sypQmomwbq6Fv5OKUbdtBBK5mnuwWg2eAbun9L_K0QcUmA@mail.gmail.com","threadId":"41282","inReplyTo":"xmqqtwlfvyau.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH] mergetool: reorder vim/gvim buffers in three-way diffs","fromName":"Dickson Wong","fromEmail":"dicksonwong@gmail.com","sentAt":"2016-02-11T20:10:33Z","receivedAt":"2016-02-11T20:10:33Z","isPatch":true,"sender":{"key":"dicksonwong@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5284055?v=4"},"body":"On 11 February 2016 at 11:31, Junio C Hamano wrote:\n> So it should suffice to mention it in the release notes as one\n> bullet item that describes one positive change, among all other\n> updates described in a simlar way. And there is no special\n> \"warnings for existing users\" necessary, I would say.\n\nIt's unlikely anyone would move the merged window to the top as a\npreference only without being aware of the original inconsistency.\nIf someone has been using a workaround, it would be fairly obvious\nas to what has changed, and definitely more so than when they first\nencountered the original behavior. Any adjustments to the new behavior\nwould probably be a workflow change rather than a system configuration\nor scripting change.\n"},{"id":"277960","messageId":"20160211211509.GA14667@gmail.com","threadId":"41282","inReplyTo":"xmqqbn7nxmhe.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH] mergetool: reorder vim/gvim buffers in three-way diffs","fromName":"David Aguilar","fromEmail":"davvid@gmail.com","sentAt":"2016-02-11T21:15:09Z","receivedAt":"2016-02-11T21:15:09Z","isPatch":true,"sender":{"key":"davvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13196?v=4"},"body":"On Thu, Feb 11, 2016 at 08:03:57AM -0800, Junio C Hamano wrote:\n> Michael J Gruber writes:\n> \n> >> Does this mean that I should warn in the release notes that some\n> >> existing users might get their expectation broken but we are going\n> >> ahead anyway because we think most people read left to right and\n> >> then top down? I am OK with saying that--I just wanted to make sure\n> >> we know that it is what we are doing.\n> >\n> > I would claim that anyone who notices the difference in buffer numbering\n> > would be positively surprised.\n> \n> Thanks. I, being a non-user of vim, was wondering if people who had\n> their own user-defined commands (macros? and possibly short-cut keys\n> to invoke them) built around the old (and odd) numbering need to\n> adjust--in which case we may need to forewarn.\n> \n> > In any case, the buffer numbering is not the same (it is local remote\n> > base merge) but it doesn't matter in this case because only one window\n> > is displayed, so there is no visual association.\n> \n> OK, thanks.\n\nSorry for not noticing this thread earlier.\nThe change and the rationale sound good to me.\n\nFWIW,\n\nAcked-by: David Aguilar \n\n\nciao,\n-- \nDavid\n"},{"id":"278020","messageId":"xmqqa8n5vlqs.fsf@gitster.mtv.corp.google.com","threadId":"41282","inReplyTo":"20160211211509.GA14667@gmail.com","subject":"Re: [PATCH] mergetool: reorder vim/gvim buffers in three-way diffs","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-02-12T18:15:07Z","receivedAt":"2016-02-12T18:15:07Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"David Aguilar writes:\n\n> On Thu, Feb 11, 2016 at 08:03:57AM -0800, Junio C Hamano wrote:\n>> Michael J Gruber writes:\n>> \n>> >> Does this mean that I should warn in the release notes that some\n>> >> existing users might get their expectation broken but we are going\n>> >> ahead anyway because we think most people read left to right and\n>> >> then top down? I am OK with saying that--I just wanted to make sure\n>> >> we know that it is what we are doing.\n>> >\n>> > I would claim that anyone who notices the difference in buffer numbering\n>> > would be positively surprised.\n>> \n>> Thanks. I, being a non-user of vim, was wondering if people who had\n>> their own user-defined commands (macros? and possibly short-cut keys\n>> to invoke them) built around the old (and odd) numbering need to\n>> adjust--in which case we may need to forewarn.\n>> \n>> > In any case, the buffer numbering is not the same (it is local remote\n>> > base merge) but it doesn't matter in this case because only one window\n>> > is displayed, so there is no visual association.\n>> \n>> OK, thanks.\n>\n> Sorry for not noticing this thread earlier.\n> The change and the rationale sound good to me.\n>\n> FWIW,\n>\n> Acked-by: David Aguilar \n\nThanks all. Will merge to 'next' and then to 'master' shortly.\n"}]}