[darcs-users] darcs patch: Resolve issue1093: warn about ugly?patch... (and 1 more)

Dan Pascu dan at ag-projects.com
Tue Feb 3 18:53:13 UTC 2009

On Tuesday 03 February 2009, Eric Kow wrote:
> On Tue, Feb 03, 2009 at 19:56:57 +0200, Dan Pascu wrote:
> > I agree. It's an absolute NO to impose someone's view on style on
> > everybody else.
> Okay, that's three comments, all pointing in the same direction.
> Thanks all!

As I said, I do think there can be some merit to the idea if done right. 
Say we have some functions to check specific predefined rules, but by 
default they do not enforce anything. Then let's say I have a way to 
indicate per repository that  want to use certain rules that I find 
useful. Say something like:

darcs setpref patch_naming_rules "length=10:70,capitalize,end_with_dot"

Which means that in that project I want patch names to not exceed 70 chars 
or be shorter than 10 chars, I want to have a capital first letter in the 
patch name and I want it to end with a dot.
Of course the last 2 can even be smart, so instead of just warning me that 
I didn't followed those rules, to automatically capitalize the first 
letter and add a dot at the end if missing. However this "smartness" is 
debatable as it can easily turn against you.

Now I'm not sure how easy would be to implement something like this in 
darcs, but in this form it can become useful without being annoying.
These rules should enforce the style, i.e. if you do not follow it, they 
won't just warn you they will simply refuse to do the operation. But 
then, they were added with consent by the people working on the project 
with the purpose of enforcing a certain style, so they will not be 
perceived as annoyances, but as reminders.

> > As for issue1000, how do you define a "strange" name and where do you
> > stop?
> Well, in the case of issue1000, I'll point out that the intention is
> not to trap user style errors, but to preserve user intention.  That
> is, most likely, the user did not mean to enter '.' or '-l' as a patch
> name, so I think it's acceptable to do something.  On the other hand, I
> also agree with the UI principle an undo mechanism is far better than a
> confirmation dialogue

I agree that trying to trap some user errors can be helpful to prevent a 
more costly undo/redo operation. However this approach only works well if 
you can made the false positives approach zero. In this case the user can 
really perceive it as helpful because it warned him of a real issue 
before it happened, avoiding a more costly undo/redo after the problem is 
noticed. However if the false positive rate is high then the warnings 
will be perceived as annoyances instead and the user will quickly learn 
to ignore them, even when they may be valid.
Say for example you warn for a dash at the beginning of the patch name. 
Now assume someone always uses a dash at the beginning of every patch 
name because he thinks it looks better than way. In this case you have 
100% false positives and the warnings will be annoying.

This is why I asked how do you define these cases and where do you stop. 
Probably there are some cases that can be defined without problem, for 
example no patch name should be an option name from the preceding 
command. Or consist of a single character. However predicting what is an 
user error and what is just someone's idea of how is best to operate his 
repository is not that easy and can turn back to bite you. OTOH having 
the ability to undo never does that as it moves the responsibility of 
fixing the error to the entity that generated it (the user) and knows 
better if it's an error or not and how to fix it.


More information about the darcs-users mailing list