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

Trent W. Buck trentbuck at gmail.com
Wed Feb 4 00:14:38 UTC 2009


Dan Pascu <dan at ag-projects.com> writes:

> 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"

I'm interested in such an approach, but I'm not interested in coding it.

But if we are to take a configurable/generic approach, I would prefer
this logic to be encoded in a "pre-hook" rather than in Darcs' own
codebase.  This would make it easier for users to add very complex
validation rules without needing to patch Darcs.

This might already be achievable if the patch name is accessible from
the test harness -- the "test" preference can be a shell script which
starts with things like

    #!/bin/bash
    if test 70 -lt "$(wc -w <<<"$PATCH_NAME")"
    then echo "Your patch name is too long!"
         # exit 1 # uncomment for errors instead of warnings
    fi

> 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.

Is this where we start talking about German essets and Greek final
sigmas? ;-)

> 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.

I dunno; technically I am consenting to use mercurial instead of darcs
at work (instead of resigning), but I'm sure not happy about it :-)

> 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.
> [...] 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.

+1 for that.  Writing heuristics that are both useful (many true
positives) and still widely applicable (few false positives) is
something which I hope to get out of this discussion.

> 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.

+1 there; this is why I adopted the approach of emitting a warning and
allowing the user to amend --edit (which can edit the patch name) rather
than an (IMO) more invasive approach of prompting:

    $ darcs record
    [...]
    What is the patch name: x
    I think your patch name it stupid, change it now? [Y/n] N
    OK, fine, be that way.  See if I care.
    $



More information about the darcs-users mailing list