Need-action: discussion from darcs-users on the sanity of my suggestion.

I think this might be a small piece of low-hanging conflicts UI fruit,
not a whole lot of bang, but not a whole lot of buck either.

The attached patch bundle to screened (at the time of this writing; use
darcs get --context) has a conflict in it.  If you mark it up, you get
something unpleasant like this:

v v v v v v v
    if os(windows)
      hs-source-dirs: src/win32
      include-dirs:   src/win32
      other-modules:  CtrlC
                      System.Posix
                      System.Posix.Files
                      System.Posix.IO
      cpp-options:    -DWIN32
      c-sources:      src/win32/send_email.c
      build-depends:  unix-compat >= 0.1.2
============= (BLOCK A)
    cpp-options:      -DGADT_WITNESSES=1

    if os(windows)
      hs-source-dirs: src/win32
      include-dirs:   src/win32
      other-modules:  CtrlC
                      System.Posix
                      System.Posix.Files
                      System.Posix.IO
      cpp-options:    -DWIN32
      c-sources:      src/win32/send_email.c
      build-depends:  unix-compat >= 0.1.2,
                      regex-posix >= 0.94.4 && < 0.95
************* (BLOCK B)
  cpp-options:      -DGADT_WITNESSES=1

  if os(windows)
    hs-source-dirs: src/win32
    include-dirs:   src/win32
    other-modules:  CtrlC
                    System.Posix
                    System.Posix.Files
                    System.Posix.IO
    cpp-options:    -DWIN32
    c-sources:      src/win32/send_email.c
    build-depends:  unix-compat >= 0.1.2,
                    regex-posix >= 0.94.4 && < 0.95
************* (BLOCK C)
  if os(windows)
    hs-source-dirs: src/win32
    include-dirs:   src/win32
    other-modules:  CtrlC
                    System.Posix
                    System.Posix.Files
                    System.Posix.IO
    cpp-options:    -DWIN32
    c-sources:      src/win32/send_email.c
    build-depends:  unix-compat >= 0.1.2,
                    regex-posix >= 0.94.4 && < 0.95
************* (BLOCK D)
  if os(windows)
    hs-source-dirs: src/win32
    include-dirs:   src/win32
    other-modules:  CtrlC
                    System.Posix
                    System.Posix.Files
                    System.Posix.IO
    cpp-options:    -DWIN32
    c-sources:      src/win32/send_email.c
    build-depends:  unix-compat >= 0.1.2,
                    regex-posix >= 0.94.4 && < 0.95
^ ^ ^ ^ ^ ^ ^

I've annotated the blocks as BLOCK {A,B,..}

I claim that the output would be very slightly less unpleasant version
of this output would not have BLOCK D because if you do a diff on BLOCKS
C and D, they turn out to have exactly the same textual context.

Now I haven't had the "pleasure" of meeting the conflicts marking code
yet, so I have no idea if this would be actually easy to accomplish, but
if somehow darcs conflict marking was aware that it was writing out
different blocks of output, it seems like it would be very easy for it
to do a simple nub on those blocks to get rid of duplicates.

Also, (and perhaps this should be a separate ticket), maybe arbitrarily
naming the blocks as I've done would make it easier to follow [this is
debatable; it could just be confusion for nothing].

Anyway, I don't think we can get very far until somebody who knows the
conflict marking code can confirm if implementation-wise, this really is
as "easy" as I'm hoping it would be.

Attachments

• force-regex_posix-version-to-be-greater-than-0_94_4-on-windows-to-avoid-linking-errors.dpatch

How would squishing duplicated blocks coexist with the other proposal to 
use patch names in the blocks?

Two options I was thinking of for playing nice with issue833 that you 
pointed out:

1. list multiple short ids, maybe omitting the short patch names if 
there are multiple entries, or maybe just having a multi-line list

v v v v v v (48ba9899f fix #498: crash in creativity subroutine...
             83ccdd001 creativity subroutine, minor bugfix)

2. treat squishing as a stop-gap measure, and restore duplicate blocks 
when we do get patch-ids (this is if getting patch-ids would take a long 
time)

On Fri, 5 Nov 2010, Eric Kow wrote:

> Eric Kow <kowey@darcs.net> added the comment:
>
> Two options I was thinking of for playing nice with issue833 that you
> pointed out:
>
> 1. list multiple short ids, maybe omitting the short patch names if
> there are multiple entries, or maybe just having a multi-line list

Ignoring the duplicates issue, a single conflict block could arise from a 
chain of patches, and that needs to be represented somehow. So with 
squishing you have to represent (x;y | z;w).

> v v v v v v (48ba9899f fix #498: crash in creativity subroutine...
>             83ccdd001 creativity subroutine, minor bugfix)
>
> 2. treat squishing as a stop-gap measure, and restore duplicate blocks
> when we do get patch-ids (this is if getting patch-ids would take a long
> time)

The refactoring I'm doing atm to abstract over Prim is actually targeted 
at getting patch-ids, but I can't promise it'll work out for that purpose 
until I've done it (which is why I haven't said anything).

Duplicate squishing is actually easy, btw; but I'm not entirely convinced 
it's the right thing. In particular if you're dealing with the same 
multi-way conflict in a few different places, then it could be confusing 
to not see the extra blocks both times.

Also, there's classic justification for duplicate patches being a conflict 
(as it is in v1 patches) is adding elements to the end of a list. That 
would go wrong if conflict markers were squished, as you couldn't visibly 
see that the same thing was added multiple times and even if you deduce 
that fact from the presence of markers, you can't tell whether it was 2, 3 
or more times.

Ganesh

I can see why duplicate squishing would introduce more UI pain/confusion 
that it tries to save.  Hmm, oh well!  The patch ids are definitely 
something to look forward to.