[Monotone-devel] Re: Cherry-Picking, Renames, Etc.

[Bruce Stephens]

Oren Ben-Kiki <address@hidden> writes:

[...]

> Hmmm. Point taken. So, suppose that someday someone submitted a patch 
> to monotone that added "monotone guess" - an independent command that 
> just invoked "monotone rename" and so on, but was integrated into 
> monotone in other respects (used the same configuration files etc.). 
> That would be acceptable, right?

My guess is that a couple of Lua hooks would be more likely to
accepted, probably post_checkout and pre_commit, or something.  Then
you could do anything you wanted inside those.  Maybe that's too icky:
it would involve "monotone commit" potentially invoking "monotone
rename" and things, which might cause problems.

Or maybe as you suggest a "monotone guess" command which would just
run a single hook, and either that would execute suitable "monotone
rename", etc., commands, or it could return some Lua tables or
something.

Why not just have the things independent of monotone?  So you run
monotone_guess before committing, or something?  I guess in Arch it
could be done in one of the dozen or more frontends, but I don't think
there's such a culture of frontends for monotone.


For what it's worth, I think commit ought to work from a specially
formatted file, which would include the log and list the files to
change.  So you'd use "monotone prepare" or something (possibly an
option to "monotone status") that would prepare such a file (with the
list of file changes), then you'd edit that adding a log, and maybe
removing some of the file changes if you didn't want to commit them.
Then "monotone commit" could use that file.  (It could also behave as
now, if not given such a file.)

That would more naturally separate out the process of deciding what's
changed and actually committing it, and would more cleanly (IMHO)
allow alternatives such as using file tags to detect file renames, or
using some kind of note-taking application to capture file-specific
log information.

More philosophically, it would return control to me.  Right now commit
drives everything: it decides what files it thinks need to be
committed, it throws me into an editor to construct the long log
message.  (It's no different to other systems in this respect as far
as I know, and normally this is what you want, but I'd like a
user-driven alternative sometimes.)