From wmorgan-ditz at masanjin.net  Tue Jul 15 20:47:53 2008
From: wmorgan-ditz at masanjin.net (William Morgan)
Date: Tue, 15 Jul 2008 17:47:53 -0700
Subject: [ditz-talk] ditz debian package available
Message-ID: <1216169257-sup-8136@entry>

Thanks to Christian Garbs:
http://www.cgarbs.de/stuff/deb-repository.html#ditz
-- 
William <wmorgan-ditz at masanjin.net>

From mitch at cgarbs.de  Sun Jul 20 06:46:46 2008
From: mitch at cgarbs.de (Christian Garbs)
Date: Sun, 20 Jul 2008 12:46:46 +0200
Subject: [ditz-talk] bash completion
Message-ID: <20080720104646.GA28085@cgarbs.de>

Hi!

The current ditz bash completion[1] is very simple (it's my first try
at writing a completion).

The first parameter is expanded to the ditz command list (obtained via
the secret parameter `ditz --commands`).
The second parameter is expanded to all open issues (via
`ditz todo 2>/dev/null | grep '^. ' | cut -c 3- | cut -d : -f 1`).

Unfortunately this simplification makes "ditz release" expand to the
open issues and not to the open releases.

I'm working on fixing this and providing proper completions for every
command, but I don't know how to get lists of these items properly:

 - all issues (for 'ditz comment' etc.)
 - all open issues (for 'ditz close')[2]
 - all unstarted issues (for 'start')
 - all started issues ('stop')
 - all assigned issues ('unassign')

 - all releases ('add-release', 'archive', 'changelog', ...)
 - unreleased releases ('release')

 - all components ('set-component')


Would it be possible to add other secret switches like
'ditz --commands' to print these lists of items?

Regards,
Christian


[1] commit cfb08b623811664387829977a927be4921d1439e
[2] I can get this like described above, but a direct output from ditz
    would be faster.
-- 
....Christian.Garbs.....................................http://www.cgarbs.de

Incorrigible punster -- Do not incorrige.


From wmorgan-ditz at masanjin.net  Sun Jul 20 18:28:27 2008
From: wmorgan-ditz at masanjin.net (William Morgan)
Date: Sun, 20 Jul 2008 15:28:27 -0700
Subject: [ditz-talk] bash completion
In-Reply-To: <20080720104646.GA28085@cgarbs.de>
References: <20080720104646.GA28085@cgarbs.de>
Message-ID: <1216592790-sup-5981@entry>

Reformatted excerpts from Christian Garbs's message of 2008-07-20:
>  - all issues (for 'ditz comment' etc.)
>  - all open issues (for 'ditz close')[2]
>  - all unstarted issues (for 'start')
>  - all started issues ('stop')
>  - all assigned issues ('unassign')
> 
>  - all releases ('add-release', 'archive', 'changelog', ...)
>  - unreleased releases ('release')
> 
>  - all components ('set-component')
> 
> Would it be possible to add other secret switches like 'ditz
> --commands' to print these lists of items?

Yes, it's possible and easy. And I think having ditz output these lists
in an easily-parseable way is the right idea. I'll spend a little time
on this.

Thanks for the bash completion, btw!
-- 
William <wmorgan-ditz at masanjin.net>

From wmorgan-ditz at masanjin.net  Mon Jul 21 13:07:39 2008
From: wmorgan-ditz at masanjin.net (William Morgan)
Date: Mon, 21 Jul 2008 10:07:39 -0700
Subject: [ditz-talk] bash completion
In-Reply-To: <1216592790-sup-5981@entry>
References: <20080720104646.GA28085@cgarbs.de> <1216592790-sup-5981@entry>
Message-ID: <1216659978-sup-343@entry>

I forgot that there's already some support for command-specific option
completion (if you pass "<options>" as the argument to a command), so
I'll work on extending that for all commands.

Then the completion scripts can be kept quite simple and don't have to
know about the specifics of ditz commands.
-- 
William <wmorgan-ditz at masanjin.net>

From wmorgan-ditz at masanjin.net  Mon Jul 21 20:52:38 2008
From: wmorgan-ditz at masanjin.net (William Morgan)
Date: Mon, 21 Jul 2008 17:52:38 -0700
Subject: [ditz-talk] bash completion
In-Reply-To: <1216659978-sup-343@entry>
References: <20080720104646.GA28085@cgarbs.de> <1216592790-sup-5981@entry>
	<1216659978-sup-343@entry>
Message-ID: <1216687798-sup-7262@entry>

Ok, check out the master branch. You should be able to call it with
"<options>" at any argument position to get the list of possible
completions.

E.g. "ditz assign <options>" prints the list of all issues, and "ditz
assign ditz-5 <options>" prints the list of all releases.
-- 
William <wmorgan-ditz at masanjin.net>

From mitch at cgarbs.de  Mon Jul 21 15:42:40 2008
From: mitch at cgarbs.de (Christian Garbs)
Date: Mon, 21 Jul 2008 21:42:40 +0200
Subject: [ditz-talk] bash completion
In-Reply-To: <1216659978-sup-343@entry>
References: <20080720104646.GA28085@cgarbs.de> <1216592790-sup-5981@entry>
	<1216659978-sup-343@entry>
Message-ID: <20080721194240.GA13676@cgarbs.de>

On Mon, Jul 21, 2008 at 10:07:39AM -0700, William Morgan wrote:
> I forgot that there's already some support for command-specific option
> completion (if you pass "<options>" as the argument to a command), so
> I'll work on extending that for all commands.

Sounds good, but there might be a problem:
When all ditz arguments are expanded, the shell needs to expand
further arguments by itself, e.g. filenames if your did some kind of
redirection of your output.  But I don't understand enough about bash
completion yet, I'll just have to see and try it to evaluate this.

Regards,
Christian
-- 
....Christian.Garbs.....................................http://www.cgarbs.de

YA BRO NETA


From mitch at cgarbs.de  Tue Jul 22 09:40:02 2008
From: mitch at cgarbs.de (Christian Garbs)
Date: Tue, 22 Jul 2008 15:40:02 +0200
Subject: [ditz-talk] bash completion
In-Reply-To: <1216687798-sup-7262@entry>
References: <20080720104646.GA28085@cgarbs.de> <1216592790-sup-5981@entry>
	<1216659978-sup-343@entry> <1216687798-sup-7262@entry>
Message-ID: <20080722134002.GA4274@cgarbs.de>

On Mon, Jul 21, 2008 at 05:52:38PM -0700, William Morgan wrote:
> Ok, check out the master branch. You should be able to call it with
> "<options>" at any argument position to get the list of possible
> completions.
> 
> E.g. "ditz assign <options>" prints the list of all issues, and "ditz
> assign ditz-5 <options>" prints the list of all releases.

This works great!

The relevant part for the bash completion is this:

_ditz() 
{
    cur=${COMP_WORDS[COMP_CWORD]}
    if [ $COMP_CWORD -eq 1 ]; then
	COMPREPLY=( $( compgen -W "$(ditz --commands)" $cur ) )
    elif [ $COMP_CWORD -eq 2 ]; then
	cmd=${COMP_WORDS[1]}
	COMPREPLY=( $( compgen -W "$(ditz "$cmd" '<options>' 2>/dev/null)" $cur ) )
    elif [ $COMP_CWORD -eq 3 ]; then
	cmd=${COMP_WORDS[1]}
	parm1=${COMP_WORDS[2]}
	COMPREPLY=( $( compgen -W "$(ditz "$cmd" "$parm1" '<options>' 2>/dev/null)" $cur ) )
    fi 
}

Currently the if..elif..fi needs to be expanded if there would be a
command with three arguments.  You could propably refactor it to use a
list but this way it's easier to understand.



I've noticed that only mandatory arguments are expanded.  It would be
nice to expand optional arguments, too, eg. 'ditz help <options>'
giving a list of all commands.

       ditz add-release [name]
       ditz assign <issue> [release]
       ditz help [command]
       ditz set-component <issue> [component]
       ditz status [release]
       ditz todo [release]
       ditz todo-full [release]

This does not need to be done for [dir] arguments (like in ditz
archive or ditz html) as filename/directory expansion is the default
expansion mechanism of the shell.

Regards,
Christian
-- 
....Christian.Garbs.....................................http://www.cgarbs.de

The Consultant's Curse:
        When the customer has beaten upon you long enough, give him
what he asks for, instead of what he needs.  This is very strong
medicine, and is normally only required once.


From wmorgan-ditz at masanjin.net  Wed Jul 23 17:50:00 2008
From: wmorgan-ditz at masanjin.net (William Morgan)
Date: Wed, 23 Jul 2008 14:50:00 -0700
Subject: [ditz-talk] bash completion
In-Reply-To: <20080722134002.GA4274@cgarbs.de>
References: <20080720104646.GA28085@cgarbs.de> <1216592790-sup-5981@entry>
	<1216659978-sup-343@entry> <1216687798-sup-7262@entry>
	<20080722134002.GA4274@cgarbs.de>
Message-ID: <1216849650-sup-4569@entry>

Reformatted excerpts from Christian Garbs's message of 2008-07-22:
> The relevant part for the bash completion is this:
[snip]

Thanks!

> I've noticed that only mandatory arguments are expanded.  It would be
> nice to expand optional arguments, too, eg. 'ditz help <options>'
> giving a list of all commands.

I don't think it's an issue of mandatory vs optional. It's an issue of
'ditz help <options>' specifically not listing anything. I've fixed that
in master.  Try it all out and let me know how it goes.
-- 
William <wmorgan-ditz at masanjin.net>

From wmorgan-ditz at masanjin.net  Wed Jul 23 17:56:29 2008
From: wmorgan-ditz at masanjin.net (William Morgan)
Date: Wed, 23 Jul 2008 14:56:29 -0700
Subject: [ditz-talk] bash completion
In-Reply-To: <1216849650-sup-4569@entry>
References: <20080720104646.GA28085@cgarbs.de> <1216592790-sup-5981@entry>
	<1216659978-sup-343@entry> <1216687798-sup-7262@entry>
	<20080722134002.GA4274@cgarbs.de> <1216849650-sup-4569@entry>
Message-ID: <1216850161-sup-4087@entry>

Reformatted excerpts from William Morgan's message of 2008-07-23:
> Try it all out and let me know how it goes.

Seems to work great for me, btw.
-- 
William <wmorgan-ditz at masanjin.net>

From mitch at cgarbs.de  Thu Jul 24 14:45:47 2008
From: mitch at cgarbs.de (Christian Garbs)
Date: Thu, 24 Jul 2008 20:45:47 +0200
Subject: [ditz-talk] bash completion
In-Reply-To: <1216849650-sup-4569@entry>
References: <20080720104646.GA28085@cgarbs.de> <1216592790-sup-5981@entry>
	<1216659978-sup-343@entry> <1216687798-sup-7262@entry>
	<20080722134002.GA4274@cgarbs.de> <1216849650-sup-4569@entry>
Message-ID: <20080724184547.GA17379@cgarbs.de>

On Wed, Jul 23, 2008 at 02:50:00PM -0700, William Morgan wrote:

> I don't think it's an issue of mandatory vs optional. It's an issue of
> 'ditz help <options>' specifically not listing anything. I've fixed that
> in master.  Try it all out and let me know how it goes.

It works great!

I especially like how the issue numbers are expanded together with
their headline.

I've tested every command and this is the only thing I've found:

`ditz add-release <options>` could list all existing releases -- if
the release name gets longer (perhaps including a branch name) you
could take an existing release and change a part of it.



By chance I ran into the following problem:

The completion script redirects error output to /dev/null to not mess
up the screen on possible problems.  I made a test directory under
/tmp where ditz could not find a .ditz-config.  So the completion just
"hung" because ditz was waiting for me to enter my name and mail
adress - but I could not see that.

Could the check for .ditz-config be turned off when an <option>
parameter is given?

Regards,
Christian
-- 
....Christian.Garbs.....................................http://www.cgarbs.de

This is my signature #12. Collect them all to get the whole set!


From wmorgan-ditz at masanjin.net  Thu Jul 24 18:56:04 2008
From: wmorgan-ditz at masanjin.net (William Morgan)
Date: Thu, 24 Jul 2008 15:56:04 -0700
Subject: [ditz-talk] bash completion
In-Reply-To: <20080724184547.GA17379@cgarbs.de>
References: <20080720104646.GA28085@cgarbs.de> <1216592790-sup-5981@entry>
	<1216659978-sup-343@entry> <1216687798-sup-7262@entry>
	<20080722134002.GA4274@cgarbs.de> <1216849650-sup-4569@entry>
	<20080724184547.GA17379@cgarbs.de>
Message-ID: <1216939063-sup-2222@entry>

Reformatted excerpts from Christian Garbs's message of 2008-07-24:
> I especially like how the issue numbers are expanded together with
> their headline.

I believe that was Nicolas's idea. :)

> `ditz add-release <options>` could list all existing releases -- if
> the release name gets longer (perhaps including a branch name) you
> could take an existing release and change a part of it.

That seems a little weird to me, because it has different semantics
from the rest of autocompletion (which is that any of the options are
valid answers). I'd rather keep it as it is.

> Could the check for .ditz-config be turned off when an <option>
> parameter is given?

Good point. This should be fixed now.
-- 
William <wmorgan-ditz at masanjin.net>

From wmorgan-ditz at masanjin.net  Thu Jul 24 20:59:29 2008
From: wmorgan-ditz at masanjin.net (William Morgan)
Date: Thu, 24 Jul 2008 17:59:29 -0700
Subject: [ditz-talk] various news items
Message-ID: <1216947439-sup-4089@entry>

- I've moved the bugs/ directory into master. I think I'm ready for the
  true "ditz experience". The bugs branch should now be considered
  obsolete.
- Slightly improved webpage, including contributors' names.
- 0.4 release is approaching! And planning for 0.5 has begun.
-- 
William <wmorgan-ditz at masanjin.net>

From nicolas.pouillard at gmail.com  Fri Jul 25 03:57:30 2008
From: nicolas.pouillard at gmail.com (Nicolas Pouillard)
Date: Fri, 25 Jul 2008 09:57:30 +0200
Subject: [ditz-talk] various news items
In-Reply-To: <1216947439-sup-4089@entry>
References: <1216947439-sup-4089@entry>
Message-ID: <1216972635-sup-3743@ausone.inria.fr>

Excerpts from William Morgan's message of Fri Jul 25 02:59:29 +0200 2008:
> - I've moved the bugs/ directory into master. I think I'm ready for the
>   true "ditz experience". The bugs branch should now be considered
>   obsolete.
> - Slightly improved webpage, including contributors' names.
> - 0.4 release is approaching! And planning for 0.5 has begun.

All of this is pretty cool!

-- 
Nicolas Pouillard aka Ertai
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/ditz-talk/attachments/20080725/e3d648c2/attachment.bin>

From mitch at cgarbs.de  Sat Jul 26 06:15:42 2008
From: mitch at cgarbs.de (Christian Garbs)
Date: Sat, 26 Jul 2008 12:15:42 +0200
Subject: [ditz-talk] basic ditz manpage
Message-ID: <20080726101542.GA14468@cgarbs.de>

Hi there!

Because Debian packages need to have a manpage for every binary, I've
written a very basic ditz manpage.  It basically tells you to run
"ditz help" but it's better than nothing.  I don't know if it is
useful to be included to the ditz repository as the README contains
much more information.

What is the "normal" way of writing manpages in Ruby?

In Perl, you can embed your documentation directly in the code and
then run pod2man, pod2html or pod2text to extract it in the desired
format.

I came across rdoc, but this looks like developer's documentation to
me, not something for the end user.

Regards,
Christian

PS: I'm deliberately not writing a manpage for the
    ditz-convert-from-monolith binary, as it will be removed anyways :)
-- 
....Christian.Garbs.....................................http://www.cgarbs.de

"However, there is no language wherein a
double positive can form a negative."
"Yeah. Right."
-------------- next part --------------
.TH "ditz" "1" "0.3" "" ""
.SH "NAME"
ditz \- simple, light\-weight distributed issue tracker
.SH "SYNOPSIS"
\fBditz\fR [ \fIoptions\fR ] \fIcommand\fR [ \fIarguments\fR ]

To list all available commands, use \fBditz help\fR.  To get help for a specific command, use \fBditz help
command\fR.
.SH "DESCRIPTION"
Ditz is a simple, light\-weight distributed issue tracker designed to work with
distributed version control systems like darcs and git. Ditz maintains an issue
database directory on disk, with files written in a line\-based and human\-
editable format. This directory is kept under version control alongside
project code. Changes in issue state is handled by version control like code
change: included as part of a commit, merged with changes from other
developers, conflict\-resolved in the standard manner, etc.

Ditz provides a simple, console\-based interface for creating and updating the
issue database files, and some rudimentary HTML generation capabilities for
producing world\-readable status pages. It offers no central public method of
bug submission.
.SH "AUTHOR"
ditz was written by William Morgan <\fIwmorgan\-ditz at masanjin.net\fR>.

This manpage was written for the Debian package of ditz by Christian Garbs
<\fIdebian at cgarbs.de\fR>.
.SH "LICENSE"
Copyright (c) 2008 William Morgan.

This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

From wmorgan-ditz at masanjin.net  Sun Jul 27 14:31:18 2008
From: wmorgan-ditz at masanjin.net (William Morgan)
Date: Sun, 27 Jul 2008 11:31:18 -0700
Subject: [ditz-talk] basic ditz manpage
In-Reply-To: <20080726101542.GA14468@cgarbs.de>
References: <20080726101542.GA14468@cgarbs.de>
Message-ID: <1217182453-sup-2703@entry>

Reformatted excerpts from Christian Garbs's message of 2008-07-26:
> Because Debian packages need to have a manpage for every binary, I've
> written a very basic ditz manpage.  It basically tells you to run
> "ditz help" but it's better than nothing.

Thanks, I've added it to the repo under man/.

> What is the "normal" way of writing manpages in Ruby?
> 
> In Perl, you can embed your documentation directly in the code and
> then run pod2man, pod2html or pod2text to extract it in the desired
> format.

There's no standard way that I know of. AFAIK there's not even a way to
package them as part of a gem.

> I came across rdoc, but this looks like developer's documentation to
> me, not something for the end user.

Correct.

> PS: I'm deliberately not writing a manpage for the
>     ditz-convert-from-monolith binary, as it will be removed anyways :)

Yup, that's fine. It's already removed in the repo.
-- 
William <wmorgan-ditz at masanjin.net>

From mitch at cgarbs.de  Sun Jul 27 16:58:20 2008
From: mitch at cgarbs.de (Christian Garbs)
Date: Sun, 27 Jul 2008 22:58:20 +0200
Subject: [ditz-talk] basic ditz manpage
In-Reply-To: <1217182453-sup-2703@entry>
References: <20080726101542.GA14468@cgarbs.de> <1217182453-sup-2703@entry>
Message-ID: <20080727205820.GA19555@cgarbs.de>

On Sun, Jul 27, 2008 at 11:31:18AM -0700, William Morgan wrote:
> Reformatted excerpts from Christian Garbs's message of 2008-07-26:
> > Because Debian packages need to have a manpage for every binary, I've
> > written a very basic ditz manpage.  It basically tells you to run
> > "ditz help" but it's better than nothing.
> 
> Thanks, I've added it to the repo under man/.

Don't forget to change the version number in the manpage (first line,
.TH) when you release ditz 0.4 (I'm looking forward to that!).

Without a Makefile or something similar, this will have to be changed
manually on every release :-(

Regards,
Christian
-- 
....Christian.Garbs.....................................http://www.cgarbs.de

I believe the technical term is "Oops!"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://rubyforge.org/pipermail/ditz-talk/attachments/20080727/57fc2b29/attachment.bin>

From wmorgan-ditz at masanjin.net  Sun Jul 27 17:51:03 2008
From: wmorgan-ditz at masanjin.net (William Morgan)
Date: Sun, 27 Jul 2008 14:51:03 -0700
Subject: [ditz-talk] Problems with environment "HOME" under Windows
In-Reply-To: <20080618153110.tguax6cuwwc4ocsc@webmail.df.eu>
References: <20080618153110.tguax6cuwwc4ocsc@webmail.df.eu>
Message-ID: <1217195405-sup-2568@entry>

Reformatted excerpts from Andreas Habel's message of 2008-06-18:
> when I try to use ditz3.0 I receive the following error:
> 
[snip]
> 
> The mentioned line tries to get the value "HOME" from my environment,  
> which is not set on my windows box.

This should be fixed in git, as well as in the 0.4 release coming out
today. Let me know if not.
-- 
William <wmorgan-ditz at masanjin.net>

From wmorgan-ditz at masanjin.net  Sun Jul 27 18:16:37 2008
From: wmorgan-ditz at masanjin.net (William Morgan)
Date: Sun, 27 Jul 2008 15:16:37 -0700
Subject: [ditz-talk] [ANN] Ditz 0.4 released
Message-ID: <1217196871-sup-9188@entry>

Ditz version 0.4 has been released!

* <http://ditz.rubyforge.org>

Ditz is a simple, light-weight distributed issue tracker designed to work with
distributed version control systems like git, darcs, Mercurial, and Bazaar. It
can also be used with centralized systems like SVN.

Ditz maintains an issue database directory on disk, with files written in a
line-based and human-editable format. This directory can be kept under version
control, alongside project code.

Ditz provides a simple, console-based interface for creating and updating the
issue database file, and some rudimentary HTML generation capabilities for
producing world-readable status pages. It currently offers no central public
method of bug submission.

Synopsis:

# set up project. creates the bugs.yaml file.
1. ditz init
2. ditz add-release

# add an issue
3. ditz add

# where am i?
4. ditz status
5. ditz todo (or simply "ditz")

# do work
6. write code
7. ditz close <issue-id>
8. commit
9. goto 3

# finished!
10. ditz release <release-name>

Changes:

## 0.4 / 2008-07-27
* bugfix: HOME environment variable now correctly detected on windows
* hooks loaded from both home directory and project directory
* added bash shell completion
* plugin architecture for tighter SCM integration, etc
* 'ditz grep' should also grep against comments, log messages, etc
* added man page
* removed ditz-convert-from-monolith
* lots of HTML output tweaking
-- 
William <wmorgan-ditz at masanjin.net>

From xbenlau at gmail.com  Sun Jul 27 22:04:42 2008
From: xbenlau at gmail.com (Ben Lau)
Date: Mon, 28 Jul 2008 10:04:42 +0800
Subject: [ditz-talk] HTML output do not show issue name
Message-ID: <f9a7555e0807271904w67e2e60ck896a454af597888e@mail.gmail.com>

Hi all,

   In the generated HTML from ditz, only exportable ID (issue id?) is
shown, it do not show the issue name which can be understood by ditz
command. I think it is inconvenient.

   For example, if your read from the HTML page, and find that one of
the issue is already fixed. And then you would like to close it by
type a ditz command. As ditz do not understand the 40 bytes HEX char ,
you have to type another command to find out the issue name first.
(e.g  ditz grep Title).  If the issue name is also shown in the HTML
page, then you could skip the 'ditz grep' command. It is more
convenient.

   Would it possible to consider to show issue name in the HTML page?

Thanks.

From wmorgan-ditz at masanjin.net  Sun Jul 27 23:22:40 2008
From: wmorgan-ditz at masanjin.net (William Morgan)
Date: Sun, 27 Jul 2008 20:22:40 -0700
Subject: [ditz-talk] HTML output do not show issue name
In-Reply-To: <f9a7555e0807271904w67e2e60ck896a454af597888e@mail.gmail.com>
References: <f9a7555e0807271904w67e2e60ck896a454af597888e@mail.gmail.com>
Message-ID: <1217214695-sup-2804@entry>

Reformatted excerpts from Ben Lau's message of 2008-07-27:
> Would it possible to consider to show issue name in the HTML page?

Unfortunately, the issue names are not global and not exportable. Ditz
generates them to make commandline use easier, but they're not
guaranteed to be unique across repositories. For example, if you clone
the ditz repo right now, add a bunch of issues, and meanwhile I add my
own issues on my repo, the names will conflict.

Only the 40-byte ids are guaranteed [1] to be unique, and that's why any
public issue information can use the ids but cannot use the names.

What I can do, which I think will help, is make the commandline accept
the issue ids in addition to issue names. I've assigned this issue to
0.5:

http://ditz.rubyforge.org/ditz/issue-31e555aefd93edaa1f7074c4f67106b1e24b6af4.html

[1] with a high probability, at least
-- 
William <wmorgan-ditz at masanjin.net>

From nichols7 at googlemail.com  Mon Jul 28 10:11:33 2008
From: nichols7 at googlemail.com (Thomas Nichols)
Date: Mon, 28 Jul 2008 15:11:33 +0100
Subject: [ditz-talk] HTML output do not show issue name
In-Reply-To: <1217214695-sup-2804@entry>
References: <f9a7555e0807271904w67e2e60ck896a454af597888e@mail.gmail.com>
	<1217214695-sup-2804@entry>
Message-ID: <488DD395.6080201@googlemail.com>

Hey,


William Morgan wrote on 2008/07/28 4:22:
> What I can do, which I think will help, is make the commandline accept
> the issue ids in addition to issue names. I've assigned this issue to
> 0.5:
>
> http://ditz.rubyforge.org/ditz/issue-31e555aefd93edaa1f7074c4f67106b1e24b6af4.html
>
> [1] with a high probability, at least
>   

That would be splendid. That bug says, "For convenience, accept issue 
hash ids (ideally prefixes as well) as well as the issue names for 
commandline use"; does "accept prefixes" mean I could use just the 
initial characters of the ID, so long as they uniquely identify the 
issue in the repo, as I can in Git?


ATM, because the "#{component_name}-#{numeric-id}" identifiers are 
(understandably) mutable, we've taken to allocating UIDs manually - so a 
ticket I create for myself might have a subject of

@prio=2 @thomas N117 Resolve rake spec weirdness with Globalite @est=2

The @thomas tag says it's assigned to me. The N117 is manually 
maintained -- all tickets I create start with N, using a7b6 or whatever 
would work better for us. The tags idea comes from [todotxt][].

Then I can
ditz todo Etna | grep "@thomas" | grep -vr "^x" |  sort -k 3

to get a priority-sorted list of my open tickets. Summing all of the 
@est values needs a trivial script and tells me whether I'm on track.

I'd rather have a 'tags' attribute for an issue to keep this kind of 
metadata, though, instead of shoving it into the title. That said, ditz 
is a great improvement on all the other approaches we've tried; thanks 
for publishing!

-- Thomas.

[todotxt]: http://todotxt.com/ and http://code.google.com/p/todotxt/


From wmorgan-ditz at masanjin.net  Mon Jul 28 11:56:04 2008
From: wmorgan-ditz at masanjin.net (William Morgan)
Date: Mon, 28 Jul 2008 08:56:04 -0700
Subject: [ditz-talk] HTML output do not show issue name
In-Reply-To: <488DD395.6080201@googlemail.com>
References: <f9a7555e0807271904w67e2e60ck896a454af597888e@mail.gmail.com>
	<1217214695-sup-2804@entry> <488DD395.6080201@googlemail.com>
Message-ID: <1217260121-sup-9146@entry>

Reformatted excerpts from Thomas Nichols's message of 2008-07-28:
> That would be splendid. That bug says, "For convenience, accept issue
> hash ids (ideally prefixes as well) as well as the issue names for
> commandline use"; does "accept prefixes" mean I could use just the
> initial characters of the ID, so long as they uniquely identify the
> issue in the repo, as I can in Git?

Yep. It accepts prefixes of any size. If the prefix matches more than
one issue it dies with an error. It's in the repo now if you want to try
it out.

> I'd rather have a 'tags' attribute for an issue to keep this kind of 
> metadata, though, instead of shoving it into the title. That said, ditz 
> is a great improvement on all the other approaches we've tried; thanks 
> for publishing!

Ditz ships with a deliberately stripped-down issue model (no priorities,
no assignments), but now that the plugin stuff is ready, you can add
your own fields, commands and output. See
  http://all-thing.net/2008/07/ditz-04-and-magic-of-ruby-dsls.html
for an example. If you want to tweak the output of todo, we'll have to
do a little more work, but everything else is ready.
-- 
William <wmorgan-ditz at masanjin.net>

From wmorgan-ditz at masanjin.net  Mon Jul 28 14:52:49 2008
From: wmorgan-ditz at masanjin.net (William Morgan)
Date: Mon, 28 Jul 2008 11:52:49 -0700
Subject: [ditz-talk] non-git users?
Message-ID: <1217271138-sup-2317@entry>

Just curious if anyone is actually using Ditz with a VCS besides git.
-- 
William <wmorgan-ditz at masanjin.net>

From nichols7 at googlemail.com  Mon Jul 28 15:02:14 2008
From: nichols7 at googlemail.com (Thomas Nichols)
Date: Mon, 28 Jul 2008 20:02:14 +0100
Subject: [ditz-talk] non-git users?
In-Reply-To: <1217271138-sup-2317@entry>
References: <1217271138-sup-2317@entry>
Message-ID: <488E17B6.8000507@googlemail.com>



William Morgan wrote on 2008/07/28 19:52:
> Just curious if anyone is actually using Ditz with a VCS besides git.
>   

I'm using it with git, will shortly also be using it with bzr. One (of 
many) advantages ditz has over ticgit :-)

(Thanks for the pointer re the plugin system, btw, I posted just before 
reading your post about it... looks ideal.)

-- Thomas


From mitch at cgarbs.de  Mon Jul 28 15:26:09 2008
From: mitch at cgarbs.de (Christian Garbs)
Date: Mon, 28 Jul 2008 21:26:09 +0200
Subject: [ditz-talk] [ANN] Ditz 0.4 released
In-Reply-To: <1217196871-sup-9188@entry>
References: <1217196871-sup-9188@entry>
Message-ID: <20080728192609.GA15478@cgarbs.de>

On Sun, Jul 27, 2008 at 03:16:37PM -0700, William Morgan wrote:

> ## 0.4 / 2008-07-27

Yay!  The next release!

I'm building a new Debian package right now and I've stumbled across
two issues:

 - The manpage seems to be missing from the 0.4 tarball.

 - Does anybody know the Debian way of registering zsh completion
   files?  The bash completion goes into /etc/bash_completion.d, but
   where do I put the _ditz.zsh file?

Regards,
Christian
-- 
....Christian.Garbs.....................................http://www.cgarbs.de

Murphy's Laws of Combat:
3.  Don't look conspicuous, it draws fire.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://rubyforge.org/pipermail/ditz-talk/attachments/20080728/965b91e8/attachment.bin>

From wmorgan-ditz at masanjin.net  Mon Jul 28 16:07:49 2008
From: wmorgan-ditz at masanjin.net (William Morgan)
Date: Mon, 28 Jul 2008 13:07:49 -0700
Subject: [ditz-talk] [ANN] Ditz 0.4 released
In-Reply-To: <20080728192609.GA15478@cgarbs.de>
References: <1217196871-sup-9188@entry> <20080728192609.GA15478@cgarbs.de>
Message-ID: <1217275209-sup-2358@entry>

Reformatted excerpts from Christian Garbs's message of 2008-07-28:
> I'm building a new Debian package right now and I've stumbled across
> two issues:

Excellent! Apparently ticgit is going into Debian, so I have some
competition to beat.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=483003

>  - The manpage seems to be missing from the 0.4 tarball.

I decided to leave it out of the manifest but that was silly.

>  - Does anybody know the Debian way of registering zsh completion
>    files?  The bash completion goes into /etc/bash_completion.d, but
>    where do I put the _ditz.zsh file?

Maaaybe /usr/share/zsh/functions/Completion/Unix/ ?
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=489646
-- 
William <wmorgan-ditz at masanjin.net>

From wmorgan-ditz at masanjin.net  Mon Jul 28 16:10:29 2008
From: wmorgan-ditz at masanjin.net (William Morgan)
Date: Mon, 28 Jul 2008 13:10:29 -0700
Subject: [ditz-talk] non-git users?
In-Reply-To: <488E17B6.8000507@googlemail.com>
References: <1217271138-sup-2317@entry> <488E17B6.8000507@googlemail.com>
Message-ID: <1217275810-sup-1737@entry>

Reformatted excerpts from Thomas Nichols's message of 2008-07-28:
> I'm using it with git, will shortly also be using it with bzr. One (of
> many) advantages ditz has over ticgit :-)

Cool. Let me know how it goes.
-- 
William <wmorgan-ditz at masanjin.net>

From wmorgan-ditz at masanjin.net  Mon Jul 28 16:32:48 2008
From: wmorgan-ditz at masanjin.net (William Morgan)
Date: Mon, 28 Jul 2008 13:32:48 -0700
Subject: [ditz-talk] [ANN] Ditz 0.4 released
In-Reply-To: <1217275209-sup-2358@entry>
References: <1217196871-sup-9188@entry> <20080728192609.GA15478@cgarbs.de>
	<1217275209-sup-2358@entry>
Message-ID: <1217277073-sup-8043@entry>

Reformatted excerpts from William Morgan's message of 2008-07-28:
> I decided to leave it out of the manifest but that was silly.

So I've put this back in the manifest. Can you pull it from the repo (or
your original copy; I didn't change it) for now?
-- 
William <wmorgan-ditz at masanjin.net>

From mitch at cgarbs.de  Mon Jul 28 17:00:03 2008
From: mitch at cgarbs.de (Christian Garbs)
Date: Mon, 28 Jul 2008 23:00:03 +0200
Subject: [ditz-talk] [ANN] Ditz 0.4 released
In-Reply-To: <1217275209-sup-2358@entry>
References: <1217196871-sup-9188@entry> <20080728192609.GA15478@cgarbs.de>
	<1217275209-sup-2358@entry>
Message-ID: <20080728210003.GA10078@cgarbs.de>

On Mon, Jul 28, 2008 at 01:07:49PM -0700, William Morgan wrote:
> Reformatted excerpts from Christian Garbs's message of 2008-07-28:

> > I'm building a new Debian package right now and I've stumbled across
> > two issues:
 
> Excellent! Apparently ticgit is going into Debian, so I have some
> competition to beat.
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=483003

Who wants to file the ITP for ditz?  :-)
As I'm using stable on all my machines, my packages are targeted at
Etch, but they should be usable under Lenny, too.

> >  - Does anybody know the Debian way of registering zsh completion
> >    files?  The bash completion goes into /etc/bash_completion.d, but
> >    where do I put the _ditz.zsh file?
> 
> Maaaybe /usr/share/zsh/functions/Completion/Unix/ ?
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=489646

When I install zsh, there is no directory of that name, only
/usr/share/zsh/4.3.2/functions/Completion/Unix/ which looks awfully
dependent on the installed zsh version.  Also I think I would be
invading the zsh package namespace at /usr/share/zsh.

I fully support the bug report: An application specific completion
should be packaged with the application, not with the shell, as the
application syntax is expected to change faster than the shell syntax.
That's the way it is done with bash , but apparently this is currently
neither implemented nor wanted/planned for zsh.

Regards,
Christian
-- 
....Christian.Garbs.....................................http://www.cgarbs.de

Light travels faster than sound.
That's why some people appear bright until you hear them speak.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://rubyforge.org/pipermail/ditz-talk/attachments/20080728/4d71238f/attachment.bin>

From mitch at cgarbs.de  Mon Jul 28 17:03:47 2008
From: mitch at cgarbs.de (Christian Garbs)
Date: Mon, 28 Jul 2008 23:03:47 +0200
Subject: [ditz-talk] [ANN] Ditz 0.4 released
In-Reply-To: <1217277073-sup-8043@entry>
References: <1217196871-sup-9188@entry> <20080728192609.GA15478@cgarbs.de>
	<1217275209-sup-2358@entry> <1217277073-sup-8043@entry>
Message-ID: <20080728210347.GB10078@cgarbs.de>

On Mon, Jul 28, 2008 at 01:32:48PM -0700, William Morgan wrote:
> Reformatted excerpts from William Morgan's message of 2008-07-28:
> > I decided to leave it out of the manifest but that was silly.
> 
> So I've put this back in the manifest. Can you pull it from the repo (or
> your original copy; I didn't change it) for now?

Debian package ditz_0.4-1 is already released and I've updated the
manpage from the repo, so it's included.  Also, the zsh completion is
currently installed to /usr/share/doc/ditz/examples.

Regards,
Christian
-- 
....Christian.Garbs.....................................http://www.cgarbs.de

A pianist  playing Chopin's  _Revolution_Etude_ at  the full tempo (76
bars per minute) hammers out sixteenths at a rate of ~10.8 per second.
This would be considered pretty good performance for a submachine gun,
especially if sustained for the ?tude's full length.           -- mawa
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://rubyforge.org/pipermail/ditz-talk/attachments/20080728/c1658353/attachment-0001.bin>

From ninja at slaphack.com  Tue Jul 29 04:15:16 2008
From: ninja at slaphack.com (David Masover)
Date: Tue, 29 Jul 2008 03:15:16 -0500
Subject: [ditz-talk] First impressions
Message-ID: <200807290315.16589.ninja@slaphack.com>

Using 0.4...  Doesn't work on Ruby 1.9 (I suspect this is a 'sha1' 
vs 'digest/sha1' issue).

Aside from that, here's my startup hooks:

module Lowline
  # Put the comments at the bottom of the file,
  # as comments will be ignored anywhere, and
  # most editors make it quickest to start editing at the top.
  # Since there's no template to edit, I have to copy/paste/hack
  # the whole method...
  def ask_via_editor q, default=nil
    fn = run_editor do |f|
      f.puts default ? default : ''
      f.puts
      f.puts '# ' + '-'*60
      f.puts '# ' + q
      f.puts '# ' + '-'*60
      f.puts "# Lines starting with a '#' will be ignored."
    end
    return unless fn
    IO.read(fn).gsub(/^#.*$/, "").multistrip
  end

  # I'm quick enough with Vim that I'd rather not have to type
  # /edit every time.
  alias_method :ask_multiline, :ask_via_editor
end

# Blank-ify, if not already done by e.g. Rails.
# I think that's what the ditz authors were expecting.
# Turns crash into a more helpful error when quitting the editor
# without saving the file (or changing it at all).
unless nil.respond_to? :blank?
  class NilClass
    def blank?
      true
    end
  end
end


Now, it's cool that I can extend Ditz this way. But it's kind of annoying that 
I have to -- should I be submitting a patch (or full-fledged plugin) to make 
it more simply configurable and editor-friendly? (In particular, it feels like 
the editor template could be made into a user-overridable ERB file.)

From wmorgan-ditz at masanjin.net  Tue Jul 29 12:20:43 2008
From: wmorgan-ditz at masanjin.net (William Morgan)
Date: Tue, 29 Jul 2008 09:20:43 -0700
Subject: [ditz-talk] First impressions
In-Reply-To: <200807290315.16589.ninja@slaphack.com>
References: <200807290315.16589.ninja@slaphack.com>
Message-ID: <1217347125-sup-3460@entry>

Hi David,

Thanks for the feedback. It looks like you've brought up a couple
issues:

Reformatted excerpts from David Masover's message of 2008-07-29:
> Using 0.4...  Doesn't work on Ruby 1.9 (I suspect this is a 'sha1' vs
> 'digest/sha1' issue).

Ok, I've added an issue for this (eab2a567). Patches welcome.

>   # Put the comments at the bottom of the file,
>   # as comments will be ignored anywhere, and
>   # most editors make it quickest to start editing at the top.

This sounds reasonable and I'm happy for this to be the default
behavior. I've added an issue (5fb1747c) and patches are welcome.

>   # I'm quick enough with Vim that I'd rather not have to type
>   # /edit every time.
>   alias_method :ask_multiline, :ask_via_editor

I would accept a patch to make this a regular configuration option
settable in .ditz-config. Or we can leave it as a hook issue.

> # Blank-ify, if not already done by e.g. Rails.
> # I think that's what the ditz authors were expecting.
> # Turns crash into a more helpful error when quitting the editor
> # without saving the file (or changing it at all).

I'm not sure what this is about. Does ditz crash for you if you don't
make any changes to the file, during e.g. a ditz add? It doesn't for
me...

In general I don't like hacking NilClass and I'd rather fix the problem
at its source.

> (In particular, it feels like the editor template could be made into a
> user-overridable ERB file.)

Seems maybe like overkill, since I can't imagine people really wanting
to configure that on a regular basis, but if it scratches your itch,
go for it!
-- 
William <wmorgan-ditz at masanjin.net>

From wmorgan-ditz at masanjin.net  Tue Jul 29 14:00:29 2008
From: wmorgan-ditz at masanjin.net (William Morgan)
Date: Tue, 29 Jul 2008 11:00:29 -0700
Subject: [ditz-talk] Some work on ditz
In-Reply-To: <8e50e92e0807291017q54a32a28y81e205aede8e9162@mail.gmail.com>
References: <8e50e92e0807291017q54a32a28y81e205aede8e9162@mail.gmail.com>
Message-ID: <1217354174-sup-9459@entry>

Hi Ohad,

[cc'ing ditz-talk for posterity]

Reformatted excerpts from Ohad Lutzky's message of 2008-07-29:
> I really like ditz (saw it mentioned on _why's blog), so I'm hacking
> on it a bit.

Great!

> I've put some work into ditz-1 (commands need full argument parsing).

That particular issue is  a little dangerous to work on, but only
because I have some very specific ideas on how I want this done. I'm
happy to elucidate those for you, of course!

> However, gitorious is very slow for me, so I'm using github instead
> (which means I can't send you merge requests).  Care to take a look?

The only commit I see so far is the one creating two new ditz issues.
Are there more you meant to push?

Using github is fine, btw. Git doesn't care, and I'm happy to receive
manual merge requests.
-- 
William <wmorgan-ditz at masanjin.net>

From ohad at lutzky.net  Tue Jul 29 16:21:01 2008
From: ohad at lutzky.net (Ohad Lutzky)
Date: Tue, 29 Jul 2008 23:21:01 +0300
Subject: [ditz-talk] Some work on ditz
In-Reply-To: <1217354174-sup-9459@entry>
References: <8e50e92e0807291017q54a32a28y81e205aede8e9162@mail.gmail.com>
	<1217354174-sup-9459@entry>
Message-ID: <8e50e92e0807291321w7dac21aal90cf9ddfdd868c4@mail.gmail.com>

So I've been talking to will, and hacking on ditz at
http://github.com/lutzky/ditz.git... and the conversation continues
here :)

> I've put some work into ditz-1 (commands need full argument parsing).
>
> That particular issue is  a little dangerous to work on, but only
> because I have some very specific ideas on how I want this done. I'm
> happy to elucidate those for you, of course!

So I've been working on it, and found trollop a bit lacking, so I
figured we might want to roll a more custom-made commandline parser.
However, now I realize trollop is also yours, so it makes more sense
to hack on that...

For now I've hacked around the issue I was having (trollop was
"stealing" flags from the subcommand, and stop_on couldn't be
specified without the hack in
126f410e7ebc900f2b60abf124cda042a4e07a6c. So I figured we might want
to bring that hack straight into trollop - add a general
"stop_on_subcommand" flag which doesn't need to know what the
subcommand would be.

So - other ideas? Elucidate away :)

-- 
Man is the only animal that laughs and weeps, for he is the only
animal that is struck with the difference between what things are and
what they ought to be.
 - William Hazlitt

Ohad Lutzky

From ninja at slaphack.com  Wed Jul 30 00:25:27 2008
From: ninja at slaphack.com (David Masover)
Date: Tue, 29 Jul 2008 23:25:27 -0500
Subject: [ditz-talk] First impressions
In-Reply-To: <1217347125-sup-3460@entry>
References: <200807290315.16589.ninja@slaphack.com> <1217347125-sup-3460@entry>
Message-ID: <200807292325.27659.ninja@slaphack.com>

On Tuesday 29 July 2008 11:20:43 William Morgan wrote:

> I'm not sure what this is about. Does ditz crash for you if you don't
> make any changes to the file, during e.g. a ditz add? It doesn't for
> me...

I don't remember exactly what the context was. I do remember that it did 
crash. If you need help, I can try to reproduce it...

What I think happened is that a particular area was assuming that 
ask_multiline (or ask_via_editor) was 

> In general I don't like hacking NilClass and I'd rather fix the problem
> at its source.

True -- however, the use of blank? is a Rails-ism, and I believe ActiveSupport 
does extend NilClass the same way I have here.

The reason I've monkeypatched things this way is, for the moment, I'm using 
bzr for development. I don't particularly like certain parts of git, but I 
haven't really used it. I'll have to learn at some point, but since the 
monkeypatch worked, this isn't enough of an itch to force the issue.

From wmorgan-ditz at masanjin.net  Wed Jul 30 16:09:54 2008
From: wmorgan-ditz at masanjin.net (William Morgan)
Date: Wed, 30 Jul 2008 13:09:54 -0700
Subject: [ditz-talk] Some work on ditz
In-Reply-To: <8e50e92e0807291321w7dac21aal90cf9ddfdd868c4@mail.gmail.com>
References: <8e50e92e0807291017q54a32a28y81e205aede8e9162@mail.gmail.com>
	<1217354174-sup-9459@entry>
	<8e50e92e0807291321w7dac21aal90cf9ddfdd868c4@mail.gmail.com>
Message-ID: <1217447386-sup-7191@entry>

Reformatted excerpts from Ohad Lutzky's message of 2008-07-29:
> However, now I realize trollop is also yours, so it makes more sense
> to hack on that...

Yes, I'm generally happy to develop trollop, using ditz as a use case.

> For now I've hacked around the issue I was having (trollop was
> "stealing" flags from the subcommand, and stop_on couldn't be
> specified without the hack in
> 126f410e7ebc900f2b60abf124cda042a4e07a6c. So I figured we might want
> to bring that hack straight into trollop - add a general
> "stop_on_subcommand" flag which doesn't need to know what the
> subcommand would be.

Adding an unconditional "stop at first non-option argument" to Trollop
is a good idea.

But I also think we should just remove the :plugins_file option from
ditz. I added it on a whim, and I don't think it's useful, and since
plugins can affect parsing, you can construct ambiguous/paradoxical
commandlines like "ditz --plugin-file a b --plugin-file c". If a is a
plugin file that doesn't add b as a command, then should ditz unload it
and load c instead? What if c is a plugin file that does add b as a
command? Should ditz simply explode in a ball of fire?

Does anyone make use of the --plugins-file option? I could make it an
environment variable instead.
-- 
William <wmorgan-ditz at masanjin.net>

From ohad at lutzky.net  Wed Jul 30 16:23:58 2008
From: ohad at lutzky.net (Ohad Lutzky)
Date: Wed, 30 Jul 2008 23:23:58 +0300
Subject: [ditz-talk] Some work on ditz
In-Reply-To: <1217447386-sup-7191@entry>
References: <8e50e92e0807291017q54a32a28y81e205aede8e9162@mail.gmail.com>
	<1217354174-sup-9459@entry>
	<8e50e92e0807291321w7dac21aal90cf9ddfdd868c4@mail.gmail.com>
	<1217447386-sup-7191@entry>
Message-ID: <8e50e92e0807301323u2e8fda74y841546d18351b49a@mail.gmail.com>

On Wed, Jul 30, 2008 at 11:09 PM, William Morgan
<wmorgan-ditz at masanjin.net> wrote:
> Reformatted excerpts from Ohad Lutzky's message of 2008-07-29:
>> However, now I realize trollop is also yours, so it makes more sense
>> to hack on that...
>
> Yes, I'm generally happy to develop trollop, using ditz as a use case.
>
>> For now I've hacked around the issue I was having (trollop was
>> "stealing" flags from the subcommand, and stop_on couldn't be
>> specified without the hack in
>> 126f410e7ebc900f2b60abf124cda042a4e07a6c. So I figured we might want
>> to bring that hack straight into trollop - add a general
>> "stop_on_subcommand" flag which doesn't need to know what the
>> subcommand would be.
>
> Adding an unconditional "stop at first non-option argument" to Trollop
> is a good idea.

Will do :)
By the way - where should I do it? Trollop's repository is SVN, and I
see ditz has its own version...

> But I also think we should just remove the :plugins_file option from
> ditz. I added it on a whim, and I don't think it's useful, and since
> plugins can affect parsing, you can construct ambiguous/paradoxical
> commandlines like "ditz --plugin-file a b --plugin-file c". If a is a
> plugin file that doesn't add b as a command, then should ditz unload it
> and load c instead? What if c is a plugin file that does add b as a
> command? Should ditz simply explode in a ball of fire?
>
> Does anyone make use of the --plugins-file option? I could make it an
> environment variable instead.

You should also take note that some plugins should be project-wide
(such as git. Why is .ditz-plugins gitignored?), and some should be
system-wide (a plugin to make all of the commands work in a nifty
manner using vi, perhaps). I vote for dropping --plugins-file (but
still using stop at first non-option).

Any Debian users to appreciate the "super cow powers" joke around? :)

-- 
Man is the only animal that laughs and weeps, for he is the only
animal that is struck with the difference between what things are and
what they ought to be.
 - William Hazlitt

Ohad Lutzky

From wmorgan-ditz at masanjin.net  Wed Jul 30 16:25:19 2008
From: wmorgan-ditz at masanjin.net (William Morgan)
Date: Wed, 30 Jul 2008 13:25:19 -0700
Subject: [ditz-talk] Some work on ditz
In-Reply-To: <8e50e92e0807291321w7dac21aal90cf9ddfdd868c4@mail.gmail.com>
References: <8e50e92e0807291017q54a32a28y81e205aede8e9162@mail.gmail.com>
	<1217354174-sup-9459@entry>
	<8e50e92e0807291321w7dac21aal90cf9ddfdd868c4@mail.gmail.com>
Message-ID: <1217448631-sup-803@entry>

Reformatted excerpts from Ohad Lutzky's message of 2008-07-29:
> So - other ideas? Elucidate away :)

Looking at your branch, you have exactly the new syntax for
Operator#operation that I wanted:

 -  operation :help, "List all registered commands", :maybe_command
 -  def help project, config, command
 +  operation :help, "List all registered commands", :maybe_command do
 +    opt :cow, "Activate super cow powers", :default => false
 +  end
 +  def help project, config, opts, command

So, nice work.

I'm also considering the idea of having opts just merge with config, so
the command only has one source of options. Unless there's a real reason
for the command to distinguish between global and command-specific
options. Thoughts?

The only other comment I have is that instead of replacing args with
ARGV everywhere in operator.rb, I'd prefer you just pass ARGV to
Operator#do in bin/ditz. That way Operator is insulated from where its
arguments actually came from. (You can imagine other uses that don't
involve ARGV.) Since all gets calls are now called on $stdin explicitly,
it shouldn't be a problem to just pass ARGV around.
-- 
William <wmorgan-ditz at masanjin.net>

From wmorgan-ditz at masanjin.net  Wed Jul 30 16:32:22 2008
From: wmorgan-ditz at masanjin.net (William Morgan)
Date: Wed, 30 Jul 2008 13:32:22 -0700
Subject: [ditz-talk] First impressions
In-Reply-To: <200807292325.27659.ninja@slaphack.com>
References: <200807290315.16589.ninja@slaphack.com> <1217347125-sup-3460@entry>
	<200807292325.27659.ninja@slaphack.com>
Message-ID: <1217449815-sup-4025@entry>

Reformatted excerpts from David Masover's message of 2008-07-29:
> I don't remember exactly what the context was. I do remember that it
> did crash. If you need help, I can try to reproduce it...

I'd be interested. Ditz shouldn't crash(tm).

> What I think happened is that a particular area was assuming that
> ask_multiline (or ask_via_editor) was 

Was...? :)

> The reason I've monkeypatched things this way is, for the moment, I'm
> using bzr for development. I don't particularly like certain parts of
> git, but I haven't really used it. I'll have to learn at some point,
> but since the monkeypatch worked, this isn't enough of an itch to
> force the issue.

Cool, you're the second person to mention ditz with bzr recently. I'm
interested to hear about your experience!
-- 
William <wmorgan-ditz at masanjin.net>

From nichols7 at googlemail.com  Wed Jul 30 17:10:54 2008
From: nichols7 at googlemail.com (Thomas Nichols)
Date: Wed, 30 Jul 2008 22:10:54 +0100
Subject: [ditz-talk] Some work on ditz
In-Reply-To: <1217447386-sup-7191@entry>
References: <8e50e92e0807291017q54a32a28y81e205aede8e9162@mail.gmail.com>	<1217354174-sup-9459@entry>	<8e50e92e0807291321w7dac21aal90cf9ddfdd868c4@mail.gmail.com>
	<1217447386-sup-7191@entry>
Message-ID: <4890D8DE.5060501@googlemail.com>

William Morgan wrote on 2008/07/30 21:09:
> Does anyone make use of the --plugins-file option? I could make it an
> environment variable instead.
>   

I don't use Debian, but FWIW I understand they discourage use of 
environment variables:

http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.9

"A program must not depend on environment variables to get reasonable 
defaults..."

(But I don't use --plugins-file, and using env vars is no problem at all 
for me :-) )

-- Thomas.


From ohad at lutzky.net  Wed Jul 30 17:13:16 2008
From: ohad at lutzky.net (Ohad Lutzky)
Date: Thu, 31 Jul 2008 00:13:16 +0300
Subject: [ditz-talk] Some work on ditz
In-Reply-To: <4890D8DE.5060501@googlemail.com>
References: <8e50e92e0807291017q54a32a28y81e205aede8e9162@mail.gmail.com>
	<1217354174-sup-9459@entry>
	<8e50e92e0807291321w7dac21aal90cf9ddfdd868c4@mail.gmail.com>
	<1217447386-sup-7191@entry> <4890D8DE.5060501@googlemail.com>
Message-ID: <8e50e92e0807301413s485a8936i48f4d53831859ed9@mail.gmail.com>

On Thu, Jul 31, 2008 at 12:10 AM, Thomas Nichols
<nichols7 at googlemail.com> wrote:
> William Morgan wrote on 2008/07/30 21:09:
>>
>> Does anyone make use of the --plugins-file option? I could make it an
>> environment variable instead.
>>
>
> I don't use Debian, but FWIW I understand they discourage use of environment
> variables:
>
> http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.9
>
> "A program must not depend on environment variables to get reasonable
> defaults..."

To get reasonable *defaults* is the point there. The program should
work well if they are not set (and ditz does, defaulting to
.ditz-plugins in the project directory). So we actually comply with
that :)

>
> (But I don't use --plugins-file, and using env vars is no problem at all for
> me :-) )
>
> -- Thomas.
>
> _______________________________________________
> ditz-talk mailing list
> ditz-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ditz-talk
>



-- 
Man is the only animal that laughs and weeps, for he is the only
animal that is struck with the difference between what things are and
what they ought to be.
 - William Hazlitt

Ohad Lutzky

From ohad at lutzky.net  Wed Jul 30 17:33:42 2008
From: ohad at lutzky.net (Ohad Lutzky)
Date: Thu, 31 Jul 2008 00:33:42 +0300
Subject: [ditz-talk] Some work on ditz
In-Reply-To: <8e50e92e0807301433j18472c58o25d241df4c8be0a@mail.gmail.com>
References: <8e50e92e0807291017q54a32a28y81e205aede8e9162@mail.gmail.com>
	<1217354174-sup-9459@entry>
	<8e50e92e0807291321w7dac21aal90cf9ddfdd868c4@mail.gmail.com>
	<1217448631-sup-803@entry>
	<8e50e92e0807301433j18472c58o25d241df4c8be0a@mail.gmail.com>
Message-ID: <8e50e92e0807301433lffc3dd5w36989db2cb465aaa@mail.gmail.com>

On Thu, Jul 31, 2008 at 12:33 AM, Ohad Lutzky <ohad at lutzky.net> wrote:
> On Wed, Jul 30, 2008 at 11:25 PM, William Morgan
> <wmorgan-ditz at masanjin.net> wrote:
>> Reformatted excerpts from Ohad Lutzky's message of 2008-07-29:
>>> So - other ideas? Elucidate away :)
>>
>> Looking at your branch, you have exactly the new syntax for
>> Operator#operation that I wanted:
>>
>>  -  operation :help, "List all registered commands", :maybe_command
>>  -  def help project, config, command
>>  +  operation :help, "List all registered commands", :maybe_command do
>>  +    opt :cow, "Activate super cow powers", :default => false
>>  +  end
>>  +  def help project, config, opts, command
>>
>> So, nice work.
>
> Hurray! :)
>
>> I'm also considering the idea of having opts just merge with config, so
>> the command only has one source of options. Unless there's a real reason
>> for the command to distinguish between global and command-specific
>> options. Thoughts?
>
> Well, config is currently a custom object (why, by the way?), whereas
> trollop just gives us a hash. It would be possible to merge them,
> manually adding fields for anything we need, but I'm not sure what
> we'd gain.
>
>> The only other comment I have is that instead of replacing args with
>> ARGV everywhere in operator.rb, I'd prefer you just pass ARGV to
>> Operator#do in bin/ditz. That way Operator is insulated from where its
>> arguments actually came from. (You can imagine other uses that don't
>> involve ARGV.) Since all gets calls are now called on $stdin explicitly,
>> it shouldn't be a problem to just pass ARGV around.
>
> This would work if trollop weren't hardwired to work with ARGV.
> However, currently Trollop's "options" sends all of his parameters on
> to Trollop::Parser.initialize, which in turn passes them to cloaker,
> and I have no idea what that does :)
>
> --
> Man is the only animal that laughs and weeps, for he is the only
> animal that is struck with the difference between what things are and
> what they ought to be.
>  - William Hazlitt
>
> Ohad Lutzky
>



-- 
Man is the only animal that laughs and weeps, for he is the only
animal that is struck with the difference between what things are and
what they ought to be.
 - William Hazlitt

Ohad Lutzky

From wmorgan-ditz at masanjin.net  Wed Jul 30 17:48:54 2008
From: wmorgan-ditz at masanjin.net (William Morgan)
Date: Wed, 30 Jul 2008 14:48:54 -0700
Subject: [ditz-talk] Some work on ditz
In-Reply-To: <8e50e92e0807301323u2e8fda74y841546d18351b49a@mail.gmail.com>
References: <8e50e92e0807291017q54a32a28y81e205aede8e9162@mail.gmail.com>
	<1217354174-sup-9459@entry>
	<8e50e92e0807291321w7dac21aal90cf9ddfdd868c4@mail.gmail.com>
	<1217447386-sup-7191@entry>
	<8e50e92e0807301323u2e8fda74y841546d18351b49a@mail.gmail.com>
Message-ID: <1217453914-sup-4269@entry>

Reformatted excerpts from Ohad Lutzky's message of 2008-07-30:
> By the way - where should I do it? Trollop's repository is SVN, and I
> see ditz has its own version...

I've just moved it to Gitorious. http://gitorious.org/projects/trollop.

Ditz has its own version in an attempt to make ditz easy to install for
people who are not living the RubyGems lifestyle. We'll just have to
remember to synchronize it.

> You should also take note that some plugins should be project-wide
> (such as git. Why is .ditz-plugins gitignored?), and some should be
> system-wide (a plugin to make all of the commands work in a nifty
> manner using vi, perhaps).

You're right, .ditz-plugins shouldn't be gitignored, and plugins should
be split into per-project and per-user. I've just added two issues that
I think reflect the ultimate desired behavior, which is that both
plugins and configuration have both per-user and per-project components,
and that the latter should generally override the former.

http://ditz.rubyforge.org/ditz/issue-1276a5bfe1f38d0c39c1fdf48d72e19a51481369.html
http://ditz.rubyforge.org/ditz/issue-91c18e278b34cedac00820e395dd7dcae6c2d4d7.html

It will be slightly more work to make the configuration overrideable
since it's a ModelObject, but it's not impossible.

> I vote for dropping --plugins-file (but still using stop at first
> non-option).

Sounds fine to me.

> Any Debian users to appreciate the "super cow powers" joke around? :)

Yes, but only after a search. :)
-- 
William <wmorgan-ditz at masanjin.net>

From wmorgan-ditz at masanjin.net  Wed Jul 30 18:03:29 2008
From: wmorgan-ditz at masanjin.net (William Morgan)
Date: Wed, 30 Jul 2008 15:03:29 -0700
Subject: [ditz-talk] Some work on ditz
In-Reply-To: <8e50e92e0807301433j18472c58o25d241df4c8be0a@mail.gmail.com>
References: <8e50e92e0807291017q54a32a28y81e205aede8e9162@mail.gmail.com>
	<1217354174-sup-9459@entry>
	<8e50e92e0807291321w7dac21aal90cf9ddfdd868c4@mail.gmail.com>
	<1217448631-sup-803@entry>
	<8e50e92e0807301433j18472c58o25d241df4c8be0a@mail.gmail.com>
Message-ID: <1217454686-sup-8609@entry>

Reformatted excerpts from Ohad Lutzky's message of 2008-07-30:
> Well, config is currently a custom object (why, by the way?), whereas
> trollop just gives us a hash. It would be possible to merge them,
> manually adding fields for anything we need, but I'm not sure what
> we'd gain.

Whoops, I meant $opts and opts, not config and opts. Do away with the
global, and have one hash that contains global and subcommand options.
Config can stay as it is. (It's a ModelObject because that allows us to
interactively create it when needs be.)

> This would work if trollop weren't hardwired to work with ARGV.
> However, currently Trollop's "options" sends all of his parameters on
> to Trollop::Parser.initialize, which in turn passes them to cloaker,
> and I have no idea what that does :)

I think that for subcommand arguments, we want to construct a
Trollop::Parser of our own anyways, since we probably want to handle
things like HelpNeeded and VersionNeeded specially. Not sure.

I kinda forget where I was going with the parameters to
Trollop::options. Doesn't look like they're used. If that's really true,
it could just take a single argument that defaults to ARGV instead.
-- 
William <wmorgan-ditz at masanjin.net>

From ohad at lutzky.net  Wed Jul 30 18:42:58 2008
From: ohad at lutzky.net (Ohad Lutzky)
Date: Thu, 31 Jul 2008 01:42:58 +0300
Subject: [ditz-talk] Some work on ditz
In-Reply-To: <1217454686-sup-8609@entry>
References: <8e50e92e0807291017q54a32a28y81e205aede8e9162@mail.gmail.com>
	<1217354174-sup-9459@entry>
	<8e50e92e0807291321w7dac21aal90cf9ddfdd868c4@mail.gmail.com>
	<1217448631-sup-803@entry>
	<8e50e92e0807301433j18472c58o25d241df4c8be0a@mail.gmail.com>
	<1217454686-sup-8609@entry>
Message-ID: <20080730224258.GA1931@yasmin.technion.ac.il>

On Wed, Jul 30, 2008 at 03:03:29PM -0700, William Morgan wrote:
> Reformatted excerpts from Ohad Lutzky's message of 2008-07-30:
> > Well, config is currently a custom object (why, by the way?), whereas
> > trollop just gives us a hash. It would be possible to merge them,
> > manually adding fields for anything we need, but I'm not sure what
> > we'd gain.
> 
> Whoops, I meant $opts and opts, not config and opts. Do away with the
> global, and have one hash that contains global and subcommand options.
> Config can stay as it is. (It's a ModelObject because that allows us to
> interactively create it when needs be.)

I'm not sure having one hash for both global and subcommand options would
work well. For example, you'll want the following two commands to behave
differently:

  ditz -v commit ditz-1         # Be verbose about ditz's initialization
  ditz commit -v ditz-1         # Add patchlog to commit-message buffer

> > This would work if trollop weren't hardwired to work with ARGV.
> > However, currently Trollop's "options" sends all of his parameters on
> > to Trollop::Parser.initialize, which in turn passes them to cloaker,
> > and I have no idea what that does :)

> I think that for subcommand arguments, we want to construct a
> Trollop::Parser of our own anyways, since we probably want to handle
> things like HelpNeeded and VersionNeeded specially. Not sure.

Hey, yeah, ditz cmd --help could just go ahead and do ditz help cmd :)

> I kinda forget where I was going with the parameters to
> Trollop::options. Doesn't look like they're used. If that's really true,
> it could just take a single argument that defaults to ARGV instead.

Will do. I'll have any remaining arguments passed on as they are now.

From wmorgan-ditz at masanjin.net  Wed Jul 30 18:56:03 2008
From: wmorgan-ditz at masanjin.net (William Morgan)
Date: Wed, 30 Jul 2008 15:56:03 -0700
Subject: [ditz-talk] Some work on ditz
In-Reply-To: <20080730224258.GA1931@yasmin.technion.ac.il>
References: <8e50e92e0807291017q54a32a28y81e205aede8e9162@mail.gmail.com>
	<1217354174-sup-9459@entry>
	<8e50e92e0807291321w7dac21aal90cf9ddfdd868c4@mail.gmail.com>
	<1217448631-sup-803@entry>
	<8e50e92e0807301433j18472c58o25d241df4c8be0a@mail.gmail.com>
	<1217454686-sup-8609@entry>
	<20080730224258.GA1931@yasmin.technion.ac.il>
Message-ID: <1217458164-sup-6885@entry>

Reformatted excerpts from Ohad Lutzky's message of 2008-07-30:
> I'm not sure having one hash for both global and subcommand options would
> work well. For example, you'll want the following two commands to behave
> differently:
> 
>   ditz -v commit ditz-1         # Be verbose about ditz's initialization
>   ditz commit -v ditz-1         # Add patchlog to commit-message buffer

As long as the long forms of the two -v options were different, trollop
would turn them into different hash keys.  It's only when the long forms
conflict that it's a problem. Is it reasonable for a subcommand to have
an option whose long form conflicts with a global option? I kinda think
not (I can imagine unreasonable cases, but not reasonable ones), but I'm
not sure.
-- 
William <wmorgan-ditz at masanjin.net>

From ohad at lutzky.net  Thu Jul 31 05:50:34 2008
From: ohad at lutzky.net (Ohad Lutzky)
Date: Thu, 31 Jul 2008 12:50:34 +0300
Subject: [ditz-talk] Some work on ditz
In-Reply-To: <1217458164-sup-6885@entry>
References: <8e50e92e0807291017q54a32a28y81e205aede8e9162@mail.gmail.com>
	<1217354174-sup-9459@entry>
	<8e50e92e0807291321w7dac21aal90cf9ddfdd868c4@mail.gmail.com>
	<1217448631-sup-803@entry>
	<8e50e92e0807301433j18472c58o25d241df4c8be0a@mail.gmail.com>
	<1217454686-sup-8609@entry>
	<20080730224258.GA1931@yasmin.technion.ac.il>
	<1217458164-sup-6885@entry>
Message-ID: <8e50e92e0807310250s45e7b979v45e5e9785fd24e0f@mail.gmail.com>

On Thu, Jul 31, 2008 at 1:56 AM, William Morgan
<wmorgan-ditz at masanjin.net> wrote:
> Reformatted excerpts from Ohad Lutzky's message of 2008-07-30:
>> I'm not sure having one hash for both global and subcommand options would
>> work well. For example, you'll want the following two commands to behave
>> differently:
>>
>>   ditz -v commit ditz-1         # Be verbose about ditz's initialization
>>   ditz commit -v ditz-1         # Add patchlog to commit-message buffer
>
> As long as the long forms of the two -v options were different, trollop
> would turn them into different hash keys.  It's only when the long forms
> conflict that it's a problem. Is it reasonable for a subcommand to have
> an option whose long form conflicts with a global option? I kinda think
> not (I can imagine unreasonable cases, but not reasonable ones), but I'm
> not sure.

Well, in that example, I'd say both flags should be called --verbose.
I wouldn't really want to have --verbose-ditz-messages or
--verbose-commit-message...

> --
> William <wmorgan-ditz at masanjin.net>
> _______________________________________________
> ditz-talk mailing list
> ditz-talk at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ditz-talk
>



-- 
Man is the only animal that laughs and weeps, for he is the only
animal that is struck with the difference between what things are and
what they ought to be.
 - William Hazlitt

Ohad Lutzky

From ninja at slaphack.com  Thu Jul 31 10:49:38 2008
From: ninja at slaphack.com (David Masover)
Date: Thu, 31 Jul 2008 09:49:38 -0500
Subject: [ditz-talk] First impressions
In-Reply-To: <1217449815-sup-4025@entry>
References: <200807290315.16589.ninja@slaphack.com>
	<200807292325.27659.ninja@slaphack.com> <1217449815-sup-4025@entry>
Message-ID: <200807310949.39086.ninja@slaphack.com>

On Wednesday 30 July 2008 15:32:22 William Morgan wrote:
> Reformatted excerpts from David Masover's message of 2008-07-29:

> > What I think happened is that a particular area was assuming that
> > ask_multiline (or ask_via_editor) was 
> 
> Was...? :)

...I must have been up too late.

...was always returning a string, so it would be expecting an empty string, 
and not nil.

> Cool, you're the second person to mention ditz with bzr recently. I'm
> interested to hear about your experience!

Well, once the basic functionality was done -- that is, some auto-adding, 
auto-checkin, that Nil fix, and forcing the editor -- it works very well. I 
can afford to be a bit more aggressive with checkins, because on the few 
occasions I didn't want to check that in immediately, I can just run 'bzr 
uncommit'.

Couple things I'm starting to notice, though -- one thing I miss from Trac is 
the ability to go back and edit other parts of the issue before I submit.

Could probably get the same effect by providing an editor-friendly format (not 
yaml) in which to enter a complete ticket. For example:

Title:
(empty line here in which to type)
(b)ugfix, (f)eature, (t)ask:
t
Description:

Changing who submitted it isn't a common operation, and is deceptive enough 
that it might be worthwhile to only allow this through either hacking Ditz, 
or changing the username in setup.

Bugfix/Feature/Task should probably be set to some default, as I'm assuming it 
must be provided.

And that format means tapping the up and down arrows will take you between 
fields, and saving/quitting will commit the whole thing. (If I have 
additional comments, I can do 'ditz comment' later.)

One more thing: For a one-project setup, having to type <project>-123 at the 
commandline is annoying. That could be implied.

You'll note that all of these are just UI changes, and everyone seems to 
disagree about UI. I have no complaints (so far) about the actual 
functionality.

From ninja at slaphack.com  Thu Jul 31 10:53:24 2008
From: ninja at slaphack.com (David Masover)
Date: Thu, 31 Jul 2008 09:53:24 -0500
Subject: [ditz-talk] First impressions
In-Reply-To: <1217449815-sup-4025@entry>
References: <200807290315.16589.ninja@slaphack.com>
	<200807292325.27659.ninja@slaphack.com> <1217449815-sup-4025@entry>
Message-ID: <200807310953.24678.ninja@slaphack.com>

Oh, one more bug, while I'm at it:

If working in my home directory, the first parent .ditz folder will be 
~/.ditz, which means Ditz will run any hooks there twice.

I've worked around this by moving bzr-specific stuff into the root of my bzr 
work, and leaving startup stuff in ~/.ditz, but this should be a trivial fix.

From mitch at cgarbs.de  Thu Jul 31 13:55:00 2008
From: mitch at cgarbs.de (Christian Garbs)
Date: Thu, 31 Jul 2008 19:55:00 +0200
Subject: [ditz-talk] Some work on ditz
In-Reply-To: <1217453914-sup-4269@entry>
References: <8e50e92e0807291017q54a32a28y81e205aede8e9162@mail.gmail.com>
	<1217354174-sup-9459@entry>
	<8e50e92e0807291321w7dac21aal90cf9ddfdd868c4@mail.gmail.com>
	<1217447386-sup-7191@entry>
	<8e50e92e0807301323u2e8fda74y841546d18351b49a@mail.gmail.com>
	<1217453914-sup-4269@entry>
Message-ID: <20080731175500.GB17044@cgarbs.de>

On Wed, Jul 30, 2008 at 02:48:54PM -0700, William Morgan wrote:
> Reformatted excerpts from Ohad Lutzky's message of 2008-07-30:
> > By the way - where should I do it? Trollop's repository is SVN, and I
> > see ditz has its own version...
> 
> I've just moved it to Gitorious. http://gitorious.org/projects/trollop.
> 
> Ditz has its own version in an attempt to make ditz easy to install for
> people who are not living the RubyGems lifestyle. We'll just have to
> remember to synchronize it.

That's a question I was going to ask, too.

Currently, my Debian repository contains both a ditz and a
libtrollop-ruby package.  ditz Depends: on libtrollop-ruby.  I think
the extra trollop package is nice, perhaps somebody wants to use
trollop but does not need ditz.

I understand that there is now a newer copy of trollop in the ditz
repository.  Propably ditz 0.5 won't work with trollop 1.8.2 any more.

On the next ditz release, will there also be a release of the
then-current trollop library in the trollop repository?
It would be the easiest way for the package maintenance.

Regards,
Christian
-- 
....Christian.Garbs.....................................http://www.cgarbs.de

<Telius> Nobody escapes the Spanish Inquisition!
<codepoet> \S\p\a\n\i\s\h\ \I\q\u\i\s\i\t\i\o\n
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://rubyforge.org/pipermail/ditz-talk/attachments/20080731/4707edb1/attachment-0001.bin>

From nicolas.pouillard at gmail.com  Thu Jul 31 14:48:05 2008
From: nicolas.pouillard at gmail.com (Nicolas Pouillard)
Date: Thu, 31 Jul 2008 20:48:05 +0200
Subject: [ditz-talk] non-git users?
In-Reply-To: <1217271138-sup-2317@entry>
References: <1217271138-sup-2317@entry>
Message-ID: <1217530011-sup-6229@ausone.local>

Excerpts from William Morgan's message of Mon Jul 28 20:52:49 +0200 2008:
> Just curious if anyone is actually using Ditz with a VCS besides git.

I'm using it with darcs, BTW I attach my hooks file.

-- 
Nicolas Pouillard aka Ertai
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ditz-SCM-hooks.rb
Type: application/octet-stream
Size: 1224 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/ditz-talk/attachments/20080731/c31bb86b/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 240 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/ditz-talk/attachments/20080731/c31bb86b/attachment.bin>

From wmorgan-ditz at masanjin.net  Thu Jul 31 16:11:19 2008
From: wmorgan-ditz at masanjin.net (William Morgan)
Date: Thu, 31 Jul 2008 13:11:19 -0700
Subject: [ditz-talk] Some work on ditz
In-Reply-To: <20080731175500.GB17044@cgarbs.de>
References: <8e50e92e0807291017q54a32a28y81e205aede8e9162@mail.gmail.com>
	<1217354174-sup-9459@entry>
	<8e50e92e0807291321w7dac21aal90cf9ddfdd868c4@mail.gmail.com>
	<1217447386-sup-7191@entry>
	<8e50e92e0807301323u2e8fda74y841546d18351b49a@mail.gmail.com>
	<1217453914-sup-4269@entry> <20080731175500.GB17044@cgarbs.de>
Message-ID: <1217534607-sup-1328@entry>

Reformatted excerpts from Christian Garbs's message of 2008-07-31:
> Currently, my Debian repository contains both a ditz and a
> libtrollop-ruby package.  ditz Depends: on libtrollop-ruby.  I think
> the extra trollop package is nice, perhaps somebody wants to use
> trollop but does not need ditz.

I agree, it is nice.

> I understand that there is now a newer copy of trollop in the ditz
> repository.  Propably ditz 0.5 won't work with trollop 1.8.2 any more.

The ditz copy of trollop is still 1.8.2. 

> On the next ditz release, will there also be a release of the
> then-current trollop library in the trollop repository?
> It would be the easiest way for the package maintenance.

The trollop repository will always have the most recent version of
trollop. If there are modifications to be made to Trollop, they'll go
there, and we can copy trollop back over to ditz.

Ditz's copy of trollop is just a copy, to make things easier for people
who want to install via setup.rb and who don't live the Rubygems
lifestyle.
-- 
William <wmorgan-ditz at masanjin.net>

From wmorgan-ditz at masanjin.net  Thu Jul 31 16:11:49 2008
From: wmorgan-ditz at masanjin.net (William Morgan)
Date: Thu, 31 Jul 2008 13:11:49 -0700
Subject: [ditz-talk] Some work on ditz
In-Reply-To: <8e50e92e0807310250s45e7b979v45e5e9785fd24e0f@mail.gmail.com>
References: <8e50e92e0807291017q54a32a28y81e205aede8e9162@mail.gmail.com>
	<1217354174-sup-9459@entry>
	<8e50e92e0807291321w7dac21aal90cf9ddfdd868c4@mail.gmail.com>
	<1217448631-sup-803@entry>
	<8e50e92e0807301433j18472c58o25d241df4c8be0a@mail.gmail.com>
	<1217454686-sup-8609@entry>
	<20080730224258.GA1931@yasmin.technion.ac.il>
	<1217458164-sup-6885@entry>
	<8e50e92e0807310250s45e7b979v45e5e9785fd24e0f@mail.gmail.com>
Message-ID: <1217535095-sup-9161@entry>

Reformatted excerpts from Ohad Lutzky's message of 2008-07-31:
> Well, in that example, I'd say both flags should be called --verbose.
> I wouldn't really want to have --verbose-ditz-messages or
> --verbose-commit-message...

I see your point. Let's keep them separate for now.
-- 
William <wmorgan-ditz at masanjin.net>

From ohad at lutzky.net  Thu Jul 31 17:03:43 2008
From: ohad at lutzky.net (Ohad Lutzky)
Date: Fri, 1 Aug 2008 00:03:43 +0300
Subject: [ditz-talk] Some work on ditz
In-Reply-To: <1217535095-sup-9161@entry>
References: <8e50e92e0807291017q54a32a28y81e205aede8e9162@mail.gmail.com>
	<1217354174-sup-9459@entry>
	<8e50e92e0807291321w7dac21aal90cf9ddfdd868c4@mail.gmail.com>
	<1217448631-sup-803@entry>
	<8e50e92e0807301433j18472c58o25d241df4c8be0a@mail.gmail.com>
	<1217454686-sup-8609@entry>
	<20080730224258.GA1931@yasmin.technion.ac.il>
	<1217458164-sup-6885@entry>
	<8e50e92e0807310250s45e7b979v45e5e9785fd24e0f@mail.gmail.com>
	<1217535095-sup-9161@entry>
Message-ID: <8e50e92e0807311403u7e3cd8d6s19d96f7dbd9facc@mail.gmail.com>

On Thu, Jul 31, 2008 at 11:11 PM, William Morgan
<wmorgan-ditz at masanjin.net> wrote:
> Reformatted excerpts from Ohad Lutzky's message of 2008-07-31:
>> Well, in that example, I'd say both flags should be called --verbose.
>> I wouldn't really want to have --verbose-ditz-messages or
>> --verbose-commit-message...
>
> I see your point. Let's keep them separate for now.

Anything else to do before merging then?

-- 
Man is the only animal that laughs and weeps, for he is the only
animal that is struck with the difference between what things are and
what they ought to be.
 - William Hazlitt

Ohad Lutzky

From wmorgan-ditz at masanjin.net  Thu Jul 31 19:18:41 2008
From: wmorgan-ditz at masanjin.net (William Morgan)
Date: Thu, 31 Jul 2008 16:18:41 -0700
Subject: [ditz-talk] Some work on ditz
In-Reply-To: <8e50e92e0807311403u7e3cd8d6s19d96f7dbd9facc@mail.gmail.com>
References: <8e50e92e0807291017q54a32a28y81e205aede8e9162@mail.gmail.com>
	<1217354174-sup-9459@entry>
	<8e50e92e0807291321w7dac21aal90cf9ddfdd868c4@mail.gmail.com>
	<1217448631-sup-803@entry>
	<8e50e92e0807301433j18472c58o25d241df4c8be0a@mail.gmail.com>
	<1217454686-sup-8609@entry>
	<20080730224258.GA1931@yasmin.technion.ac.il>
	<1217458164-sup-6885@entry>
	<8e50e92e0807310250s45e7b979v45e5e9785fd24e0f@mail.gmail.com>
	<1217535095-sup-9161@entry>
	<8e50e92e0807311403u7e3cd8d6s19d96f7dbd9facc@mail.gmail.com>
Message-ID: <1217545108-sup-6970@entry>

Reformatted excerpts from Ohad Lutzky's message of 2008-07-31:
> Anything else to do before merging then?

I don't think so. I'm probably going to take your branch, squash the
earlier and later commits together, and elide the trollop changes.
Someone else just submitted some trollop patches, so I'd like to keep
trollop development out of ditz as much as possible.
-- 
William <wmorgan-ditz at masanjin.net>

From wmorgan-ditz at masanjin.net  Thu Jul 31 19:20:36 2008
From: wmorgan-ditz at masanjin.net (William Morgan)
Date: Thu, 31 Jul 2008 16:20:36 -0700
Subject: [ditz-talk] non-git users?
In-Reply-To: <1217530011-sup-6229@ausone.local>
References: <1217271138-sup-2317@entry> <1217530011-sup-6229@ausone.local>
Message-ID: <1217546358-sup-4296@entry>

Reformatted excerpts from nicolas.pouillard's message of 2008-07-31:
> I'm using it with darcs, BTW I attach my hooks file.

Cool. I just need an hg user and I'll have the quadumvirate!

I'll probably start posting some of the hooks files on the webpage too.
-- 
William <wmorgan-ditz at masanjin.net>