darcs

Issue 2205 better ui when diff has multiple matches on a single patch

Title better ui when diff has multiple matches on a single patch
Priority feature Status given-up
Milestone Resolved in
Superseder Nosy List kowey, sleemanj
Assigned To
Topics UI

Created on 2012-06-20.15:11:49 by kowey, last changed 2017-07-31.00:42:46 by gh.

Messages
msg15813 (view) Author: kowey Date: 2012-06-20.15:11:47
This is potentially tricky: what should darcs diff when you select 
multiple patches?

In James's case below, it's unfortunate when you have a situation where 
you select two patches that happen to have the same name.

There are, on the other hand, potential uses for multi-patch diff (eg. 
“show me the diff resulting from patches from Bob this December”, or 
“show me the diff for patches on ticket #230”)

Is there a sensible way to detect common cases in practise where 
matchers result in an unintentional ambiguity?

http://lists.osuosl.org/pipermail/darcs-users/2012-June/026527.html
msg15837 (view) Author: sleemanj Date: 2012-06-29.08:59:54
To clarify...

  $ darcs diff --match="Thing That Matches Two Patches"
  ... diff output from only the latest match ...

Is what I did/got.  So I was (trying to) select a single patch, that matched a 
string, and get the diff, which is exactly what darcs did, except there were 2 
patches that matched the criteria and darcs did not mention that fact when it 
showed the diff of only the most recent one.

Just a simple warning "hey genius, there are other patches that matched, perhaps 
you want to be more specific, but here's the latest anyway" (in not quite those 
words ;-)) to alert the user would help.  

In the case of the user selecting multiple patches (not really sure how that 
works) then the same would apply, there if there are other patches that could 
have formed part of that criteria based set but were not selected a notice to 
indicate that would be nice.

Of course, I'm guessing that the match is lazy in this regard, the first match 
stops darcs looking.  I assume that --patch, --from-*, --to-* etc are similar in 
this respect, start at the top and work down until they find a patch that 
matches, and stop looking.  So currently the information that there are other 
matching patches is probably just not there to warn about.

I don't know how expensive checking ALL the patches is for a match which would 
be necessary to produce such a warning, so perhaps it's simply "uneconomic" to 
do so.

Unfortunately my time is short and it's been at least a dozen years since I've 
used Haskell so I probably can't look at it myself at least in the immediate 
future.

FWIW
  $ darcs -v
  2.7.99.1 (release candidate 1)
  $ uname -a
  Linux mortimer 3.2.0-24-generic #39-Ubuntu SMP Mon May 21 16:52:17 UTC 2012 
x86_64 x86_64 x86_64 GNU/Linux
History
Date User Action Args
2012-06-20 15:11:49koweycreate
2012-06-29 08:59:55sleemanjsetnosy: + sleemanj
messages: + msg15837
2017-07-31 00:42:46ghsetstatus: unknown -> given-up