Re: [Monotone-devel] Perhaps strange request: partial per-file commit

[William Uther]

On 16/01/2008, at 3:02 AM, Alvaro Herrera wrote:

> Ralf S. Engelschall wrote:
> > On Tue, Jan 15, 2008, Thomas Moschny wrote:
> >
> > > On Tuesday 15 January 2008, Ralf S. Engelschall wrote:
> > > > So, it would be also nice
> > > > to have the "hunk restriction" feature for "mtn diff":
> > > >
> > > >     $ mtn diff file11:-2,-4
> > >
> > > You can use filterdiff from the very useful patchutils[1]  
> > > collection for that:
> > >
> > >   mtn diff file11 | filterdiff -# 1,3,5-
> > >
> > > would show hunks one, three and all hunks starting from the fifth.
> > > Selecting hunks based on which lines they contain is also possible.
> >
> > Ok, right, for "mtn diff" this works. But unfortunately, for the main
> > purpose, the partial per-file commit, it still doesn' help... :-(
>
> Yeah, what I do is save the full diff somewhere, get the partial diff
> with filterdiff, save it to a tmp file, revert all changes, apply the
> partial diff, commit, apply the full diff back.  Lather, rinse,  
> repeat.
> It's truly cumbersome.  It would be awesome to have an easier way  
> to do
> it, something like
>
> mtn diff | filterdiff -# 1,3,5 -x "*executor.c" | mtn commitdiff
>
> where the "commitdiff" would get the diff and commit only that part.
>
> Not sure this is the right API (in fact it still looks cumbersome),  
> but
> implementing filterdiff inside monotone does not seem a truly
> interesting prospect ...

I like this 'commitdiff' concept.  It is a simple command that could be
implemented fairly easily.  It also allows many other things to build
on top of it.  While not a good User interface, it is a much better
programatic interface than the --interactive option.

In fact, you could probably make a simple script that
implemented commitdiff... Use the automate interface to make a
workspace-less commit with the associated diffs applied.  Then
apply the diff backwards to the current workspace to remove the
changes you just committed (so that they don't conflict in the next  
step).
Then update the workspace to the new revision, which would re-introduce
the changes in the diff into the workspace.

The only real question is how this affect items that monotone tracks  
that
are not represented in a normal diff format - file and property adds,
deletes and renames, etc.

Cheers,

Will        :-}