Karl Fogel wrote:
> glasser_at_tigris.org writes:
>> Log:
>> Retool conflict resolver menu into three sections:
>>
>> Edit the merged file:
>> (e) edit - change merged file in an editor
>> (df) diff-full - show all changes made to merged file
>> (r) resolved - accept merged version of file
>> Just deal with the conflicts (ignoring merged file):
>> (dc) display-conflict - shows all conflicts
>> (mc) mine-conflict - accept my version for all conflicts
>> (tc) theirs-conflict - accept their version for all conflicts
>> General:
>> (p) postpone - mark the conflict to be resolved later
>> (l) launch - launch external tool to resolve conflict
>> (s) show all - show this list
>
> Before criticizing this one minor decision, I want to state how totally
> and completely I love that you are completing the interactive conflict
> resolution feature. Yay!
>
> But, is it really wise to add these section headers? I found the
> categorizations confusing -- like, why are "(e)" and "(l)" in different
> sections? They feel so similar. Same with "(df)" and "(dc)"...
>
> My point is not that the sections need retooling; any categorization is
> going to create similar conundrums. Meanwhile, what does it gain us? A
> user encountering the menu for the first time just has to read all the
> options to make an intelligent choice; as they learn the options through
> repeated exposure (and learn which ones they usually use), the category
> headers are just that much wasted vertical space.
>
> To my eye, they just get in the way of the real information.
Heheh. To my eye, the lack of a blank line before each section header makes
me read the second and third headers as wrapped long lines, as if (r) was
really:
(r) resolved - accept merged version of file Just deal with the
conflicts (ignoring merged file):
but line-wrapped after "... of file".
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2008-05-02 18:18:25 CEST