darcs-style cherry-picking of changes to commit ?

[Martin Pool]

On  2 Dec 2005, Michael Ellerman <michael at ellerman.id.au> wrote:
> On Fri, 2 Dec 2005 19:57, Simon Michael wrote:
> > Good evening all.. I'm a happy darcs user, checking out bzr which also
> > looks great. Thanks for creating it.
> 
> I was also a fan of darcs hunk-selection at commit behaviour, and originally I 
> was hoping to add something similar to bzr. (it's still a possibility)
> 
> However I've decided now that darcs' behaviour actually encourages bad 
> practice, in that it makes it very easy to create revisions that never 
> existed in your working tree. This is a bad idea because it means you end up 
> with revisions in history that were never built or tested.

I agree that it's possible to use it in a bad way.  But there is a way
to mitigate it.  That is: let the user choose the hunks to be committed,
and build an in-memory tree describing what they chose.  Export that to
a temporary directory, and run a configured selftest command in there;
if the test fails then show the error and disallow the commit.

I think darcs does this but I'm not sure.  For that matter it's
similar to Aegis too.

I'd like to make a few cleanups to the commit code which might allow
this sort of thing:

 - make it less entangled with the weave storage

 - first "plan" or "prepare" the commit, and let the caller look at what
   will be committed.  they can use that to prepare the commit message
   template, etc.

 - return an object describing what was committed so people can have
   verbose output from that if desired (rather than running bzr st)

-- 
Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051206/01d42720/attachment.pgp