[darcs-users] a couple of features (logs & managing patches)

David Roundy droundy at abridgegame.org
Thu Aug 19 11:00:03 UTC 2004


On Tue, Aug 17, 2004 at 04:29:04PM -0400, Isaac Jones wrote:
> Please excuse me if this has been talked about before, I don't follow
> this list in great detail.

The 'make log' concept has been discussed, but I don't think everyone was
entirely satisfied with the outcome.  So if relevant parties could comment
on my suggestion below, that would be great.  I don't want to implement it
unless there is something like a consensus that it's an improvement.

> One feature that I really like in tla is the 'make log' command, in a
> way.  I like the fact that it's easy to write down my changes as I go,
> and when I "record", it knows where to look for the log file.  This
> feature could be added to darcs without darcs forcing me to use it
> like tla does.
> 
> In brief, tla make-log outputs the name of a log file.  Therefore,
> emacs `tla make-log` will create or edit the file, then "tla commit"
> will use that file for its log.
> 
> I know that one can specify a logfile with "record", but it's nice to
> have the command to create a logfile that "record" will find
> automagically.  (It should perhaps also have the feature that if I
> start the log file while working on a one patch, then I record and
> specify a different file, the next time I do a record, it shouldn't
> use the old file.)

Hmmm.  I think that I might like a different way of implementing this sort
of functionality... which I think could be implemented perhaps a bit more
simply, and might lead to more flexibility in use.

I'm thinking that by adding a "--delete-logfile" option to record, and
simply changing darcs' behavior when the specified logfile doesn't exist,
and changing the behavior of --edit-long-comment, we should be in very good
shape, in that we should be able to satisfy everyone I've heard from on
this subject (which has been a lot).

Obviously the --delete-logfile would address your concern about
accidentally re-using a logfile.

If we make --logfile=foo simply be ignored if --foo doesn't exist, then you
could safely add this to your defaults, without restricting yourself to
always create a logfile.

If we make --edit-long-comments have the result (when combined with
--logfile) that the logfile is then popped up for some last minute editing
of the comments, which I personally would find valuable.  This would imply
changing the behavior of the --edit-long-comments option, in that it would
presumably allow you to edit the patch name, as --logfile does, with the
patch name being the first line.

The only additional feature that people seem likely to want is the ability
to flag part of the --edit-long-comments file as ignored, and to add a
patch summary to the file before it pops up in the editor, so you can see
what you're recording.

So to get the behavior your requesting, your logfile would always have the
same name (foo in my example), and you'd have in your defaults

--logfile foo
--delete-logfile

and possible (I would if I were you...)
--edit-long-comments

Then you'd just have to edit "foo" as you work, but if you forget, you'd
still be fine.

> Also, has anyone implemented anything like tla-pqm[1] for darcs?
> That's tla's "Patch Queue Manager", which a friend of mine wrote.  I'm
> not sure that this is exactly what I want, but I would love to have
> some kind of support for managing patches besides ticking them in
> email.
> 
> Here's a somewhat related use case that would be nice:
> 
> - I get a patch in email
> - I pipe my email to "darcs swallow-patch"
> - Later, I can say "darcs show-unapplied-patches"
> - darcs apply -p"the patch name"
> (and it deletes it from the show-unapplied list)
> 
> Of course, this could be a wrapper script as well.

Sounds like you could almost get this functionality with a separate "queue"
repository to which you apply patches you get via email.  You could then
pull them from this repository.  The only catch is that you'd have to keep
this repo up to date, or the patches won't apply (since they won't have the
required context), and you'd have to occasionally clean up rejected patches
to avoid getting to many merge conflicts, which would slow things down
(perhaps to a halt).

Or this sort of thing could be done with an external tool, keeping the
patches in patch bundle format (the format "send" uses) and then selecting
the patch you want and running apply on it.  This would almost certainly be
cleaner than sticking them in a repo.

Another possibility (which might be at least "interesting") would be to
create a tool (probably a command within darcs) to convert a patch bundle
into a very "partial" repository--much more partial than one from get
--partial, since it could only be pulled from or pushed from.  But changes
and a few other commands would work.
-- 
David Roundy
http://www.abridgegame.org




More information about the darcs-users mailing list