[ditz-talk] [PATCH] Allow ditz claim abcd oprah

Thomas Nichols nichols7 at googlemail.com
Mon Nov 10 16:27:33 EST 2008

William Morgan wrote on 2008/11/10 3:48:
> Reformatted excerpts from Thomas Nichols's message of 2008-1
> WDYT? Is this a change that's useful to others?
> I think this is a good change, but it needs a little more work before it
> goes in. In particular I'd like to see:
> - commands for managing aliases (adding and removing)

Yeah, I looked at that and chickened out :-)

Something like a 'ditz nick' command with add/remove? And these would
get added to the devs (better renamed as nicks or aliases) hash in

> - the ability to use either an email address or an alias
Nice. So if the nick is defined, use its expansion, otherwise use the
literal string?
> The ability to assign issues to people is definitely desireable.
>> BTW I'm a bit nervous of continuing with the current implementation of
>> 'mine' since it depends AFAICT on a string comparison of the
>> human-readable email address. Would it be better to store the nickname
>> in the issue-*.yaml 'claimer:' field, instead of the expanded email
>> address, so that emails can change without breaking the output of
>> 'mine'?
> Although it's not ideal in certain situations, I'd like to keep with the
> "git solution" of using one's email address one's canonical, unique
> identifier. It's a little silly in the centralized case, but in the
> decentralized case, you don't really have control over who's committing
> what, and when. So I'm happy with the fact that you can alias people,
> because that will be helpful, but I don't want to make that the
> canonical identifier.
> But you're right in that the current comparison is of the full whoami
> string, and it should probably be of the email address only.

Yup, you're right -- emails work better than aliases as ids. Comparison
of the <attila at the-hun.com> strings would probably be ideal.

One problem I haven't resolved yet is how to code cleanly the ability to
use this logic for commands like 'ditz claimed' which already take an
optional release param. Since we already have optional positional params
I'd like to understand the logic for future syntax extensions. At the

 * ditz claimed    # all of them
 * ditz claimed FIELD  # claimed issues for the FIELD release
so perhaps it could be

 * ditz claimed FIELD oprah    # FIELD issues claimed by Oprah

but then what is

 * ditz claimed oprah

  ? Do we: check for a valid release name, if not found check for a
valid nick/alias? Do we say it *must* be a release, so you cannot search
for all claimed tickets for a developer? Do we add a new switch so we can

 * ditz claimed --claimer oprah

I also smell feature creep here -- what about 'ditz mine', should that
take a --claimer switch, or perhaps an optional positional param? What
about 'ditz add', to automatically claim a ticket as it's being entered?
&c. &c.

I'm not going to get much time on these this week, so perhaps people
could chuck some ideas around, and let me know whether to prefer 'ditz
nick' or 'ditz alias' and I'll have a look at it when I can?

Best regards,

More information about the ditz-talk mailing list