Re: RFC: mtn split (Was: [Monotone-devel] Best practice using monotone)

[Derek Scherger]

Ethan Blanton wrote:
> Now, the hard part here is providing a UI for this which doesn't
> require the user to carry around a lot of baggage; for two or three
> logical changes it's not hard, necessarily (something like 'mtn split
> -r B', 'mtn split -r B --whatever B1', 'mtn split -r B --whatever B1
> --whatever B2', etc.), but for large such revisions it gets ugly fast
> if the user has to track each sub-changeset revision individually.
> Perhaps the best interface is really something like pluck-and-prune
> followed by merge (maybe with a tool to approve individual "hunks" of
> the plucked diff one by one, as Daniel recommended) with no such logic
> for "ignoring" sub-changes as I describe above, but this seems like
> the most logical place where monotone can "help" to me.
>
> Hopefully that was halfway coherent.  ;-)

I hope this will be too!

I've thought a few times (in not a lot of detail) about a command 
(perhaps "mtn restrict -r B [PATH]...") that would "restrict" the 
changes in revision B and commit a new revision B' according to the 
restriction specified by the listed paths. B' would be the revision you 
would have committed when committing B had you restricted the commit 
with the same [PATH]... specification.

The idea of doing this in a clean workspace which would further allow 
you to fine tune the changes before committing them would certainly seem 
good. Although, presumably this is exactly what restricted pluck does 
now? (I haven't really looked at pluck yet).

Another thought I've had relates this to restriction granularity. 
Currently we support a granularity of a single file (i.e. 'mtn commit 
foo' restricts the commit to file foo). The idea of restricting down to 
individual diff hunks within a file (as darcs does) is essentially 
allowing a finer granularity than we currently have.

I really haven't used darcs very much but the interactive ui they have 
for this seems a bit error prone, if I understand it correctly. i.e. 
once I've said "yes" or "no" to some hunk I can't change my mind without 
killing the process and going through it all again.

There was talk here a while ago of listing files and diffs in the 
changelog editor during a commit which would allow for further selection 
and this sounds somewhat reasonable.

Cheers,
Derek