Re: [Monotone-devel] Interoperating with upstream open-source projects

[Nathaniel Smith]

On Wed, Apr 13, 2005 at 11:05:51AM -0600, Shaun Jackman wrote:
> Is it possible to attach a name to an e-mail address in a key? For
> example, I tried...
> $ monotone --db=.mt genkey 'Shaun Jackman <address@hidden>'
> monotone: misuse: error converting 23 UTF-8 bytes to IDNA ACE: non-LDH
> characters
> ... with no luck.

No, as you discovered.  Is there a particular reason you need this,
or?

> Could monotone generate a log in ChangeLog format? For example...
> $ monotone changelog # (or perhaps even ChangeLog)
> 2005-04-13  Shaun Jackman  <address@hidden>
> 
>       * hello.c: New file.
> 
> ... where the string "* hello.c: New file." is the verbatim --message
> text. Although it would be great if the log message editor
> automatically generated a template in ChangeLog format.

Your best bet here would be to override the hook "edit_comment"
(described at http://www.venge.net/monotone/docs/Hook-Reference.html).
The "commentary" argument it gets is the text of the revision being
committed, which is in a reasonably easily parseable format; you could
write a little bit of lua (or write an external program, and then
write some lua to call out to it) that takes revision text and
generates you a changelog template.  (Presumably you would also teach
this code to figure out your name and email address, or just hard code
them.)

> I'm often working on two or three unrelated patches for a single
> project at one time. I'll post each of the patches to the project's
> mailing list at the end of one day, and then based on feedback, make
> further revisions to the patches the next day. I then resubmit the
> patches in their entirety to the project's mailing list. The trick is
> that I need to associate the changes I make in the second day to one
> of those patches. I then pull all the diff hunks associated with a
> specific patch and send them upstream along with their ChangeLog
> entries. It's also likely that these unrelated patches will be working
> in the same file. I expect this will use branches somehow, but I
> haven't figured it out yet.

It sounds like you want to create a branch for each unrelated change.
Something like:
  $ monotone --branch=com.host.project.upstream checkout change1
  $ monotone --branch=com.host.project.upstream checkout change2
  <poke around editing things in change1 and change2>
  .../change1$ monotone --branch=com.other.local.change1 commit
  .../change2$ monotone --branch=com.other.local.change2 commit
Now you can diff between these files and the version you originally
branched from (you can get the branch point from "monotone log", or
monotone-viz), and mail that into the list.  When you want to modify
the patch more, make some more changes on either branch, and then
regenerate the patch the same way to send in for more feedback.  If
there are changes made upstream along the way, that you want to merge
into your local work (so your patch stays current), just say
  $ monotone propagate com.host.project.upstream com.other.local.change1

> One final thing. What's the selector for an empty file, and what's the
> selector for the current merged head? I'm looking for something that
> looks like monotone diff -r empty -r head hello.c.

There is no selector for the current head.  It's kinda an obvious
lack, but no-one's gotten around to adding it.  (Patches accepted.)

I'm not sure what you mean by "empty file selector"; selectors are for
whole revisions, not individual files.  If you just want to get the
contents of hello.c in some revision, you can say
  $ monotone cat file REVISION-ID-OR-SELECTOR hello.c

-- Nathaniel

-- 
In mathematics, it's not enough to read the words
you have to hear the music