[darcs-users] darcs patch: Resolve issue1093: warn about ugly?patch... (and 1 more)
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