Re: [PATCH] mergetool: reorder vim/gvim buffers in three-way diffs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Junio C Hamano venit, vidit, dixit 10.02.2016 18:45:
> Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> writes:
> 
>>> Second call for help.  Any comments on this from anybody other than
>>> the author that I missed to support this change?
>>
>> OK, applied it (on top of next), looks sane and improves the situation
>> for the majority of people who read left to right, then top down and
>> assign buffers 1 2 3 4 "mentally" to local base remote merge windows
>> based on that. Their expectation is met now. Thanks!
> 
> Thanks.
> 
> Does this mean that I should warn in the release notes that some
> existing users might get their expectation broken but we are going
> ahead anyway because we think most people read left to right and
> then top down?  I am OK with saying that--I just wanted to make sure
> we know that it is what we are doing.

I would claim that anyone who notices the difference in buffer numbering
would be positively surprised.

>> (Also, the other vim variants don't need a corresponding change.)
> 
> A stupid question while I am here.  What are these different
> variants?  When reviewing this patch for the first time I tried to
> find where they are documented, but didn't spot anything.
> 
> I can see from the code that vimdiff2 variant does not do anything
> special when it is doing a 3-way merge,

It is "vimdiff" without the base window.

> but vimdiff3 variant does
> behave differently when it has $BASE.  It does not need a change
> like this because it already arranges and numbers the windows
> sensibly (in other words, we can label this patch as aligning the
> behaviour of vimdiff to that of vimdiff3)?

git log mergetools/vimdiff3
commit 7c147b77d34f072c40b912fafba499727921fa6e
Author: Felipe Contreras <felipe.contreras@xxxxxxxxx>
Date:   Sun Apr 20 19:24:20 2014 -0500

    mergetools: add vimdiff3 mode

    It's similar to the default, except that the other windows are hidden.
    This ensures that removed/added colors are still visible on the main
    merge window, but the other windows not visible.

    Specially useful with merge.conflictstyle=diff3.


I have to say I'm still not sure what it is about (even after trying it
out, even with the conflictstyle config)).

In any case, the buffer numbering is not the same (it is local remote
base merge) but it doesn't matter in this case because only one window
is displayed, so there is no visual association.

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]