Re: [Gnu-arch-users] Re: fixing and extending "selected commit"

[Robert Anderson]

On Thu, 2003-10-02 at 15:10, Miles Bader wrote:
> > So, you know, if your development environment is _so_ out of scale
> > with your tree that copying the tree is just too horrible to
> > complicate:  then perhaps either your environment is far weaker than
> > you need, or your tree is out of control.c
> 
> Well what do you want me to say?  Clearly trees like linux (or emacs)
> are accepted by the general developer community as being `small enough'
> for general use; if arch can't handle them, people will think `arch
> sucks' rather than `my development style sucks.'  Me too, BTW; sometimes
> there are pretty inescapable reasons to do things like tree-copying, but
> well, not in this case.
> 
> Having a _way_ to do what's basically a `copy-as-if-committed-
> respecting-limits' might be great for doing pre-commit testing or
> whatever, maybe I'll even use it sometimes, but I think it's not
> appropriate to make it the only way to do partial commits.

I think you're missing the point.  The point is entirely not that we
want an additional "copy-as-if-respecting-limits".  The point is that we
want a way to create tree states and commit them.  Period.

The question is how to get there in the best way.  The "copy" is just
one way of getting at it and you seem to be saying you wouldn't like the
performance of a whole-tree copy.

So how else could you do it?  You could generate a "partial-undo"
changeset and apply it as a pre-commit step.  Then as a post-commit hook
you'd apply that undo in reverse, generating the complement tree
in-place.  No need for tree copies.

How does that appeal to you?

Bob