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

[Miles Bader]

On Fri, Oct 03, 2003 at 07:07:11AM -0700, Robert Anderson wrote:
> > By modifying the changeset creation mechanism to have the notion of a
> > `limit', and ignore files not inside it.  Simple and straight-forward
> > (indeed, I'd think this was the _obvious_ way to do it...).
>
> You've elided my suggestion.  I wonder what you thought about it.

As what?  As an _user_ alternative to restricted commit?  It's annoying
make-work.

As a method used internally to implement restricted commit?  It's probably
workable (whereas tree-copying is unacceptably expensive); as long as it's
efficient, it shouldn't be noticeably different to the user than a more
straight-forward restricted commit implementation.

Of course, it would be more inefficient in the case of a small restricted
commit done in a heavily modified tree, but I'm not sure the difference is
enough to worry about, given that even `big' changesets are usually not
_that_ big.

If having pre-commit hooks that do some sort of tree checking is a common
case, then it's probably useful to give them a coherent tree -- but of course
pre-commit hooks are obviously currently not common because they're not even
implemented; if they _were_ implemented, they'd probably still be the
uncommon case.

Implementation-wise, having the partial-undo required for the method you
suggest is probably _exactly_ the same code as is required to do a more
straight-forward restricted commit, since they both apply a limit when
creating a changeset (in the case of a partial undo, it's inverted, of
course, but that's mostly* just a flag somewhere).  So regardless of the
final details of the commit code, the hardest part of the code should be the
same whether commit uses your technique, or whether it uses a
straight-forward restricted commit.

* The semantics of `limit-crossing' changes might need extra care

> As for your suggestion, it does not meet my criteria for a good commit
> process for one simple reason:  you never get a look at the revision
> that will end up in the archive before it gets there.  To me, that is
> unacceptable.

Who's `you' in this case, a pre-commit hook?  That's the only case where it
conceivably makes a difference.

-Miles
-- 
Quidquid latine dictum sit, altum viditur.