Something like "darcs record" / "hg record" == Select changes to commit.

[Stephen J. Turnbull]

Ben Finney writes:

 > "Stephen J. Turnbull" <stephen at xemacs.org> writes:
 > 
 > > >>>>> At some point Ben Finney wrote
 > >
 > >  > Because of the above issue, I think Bazaar should not have the
 > >  > behaviour you describe.
 > >
 > > It seems to me that Ben's opinion is clearly opposed to the general
 > > trend of Bazaar development, which is to allow users to develop their
 > > own workflows and have Bazaar manage them conveniently. If Ben doesn't
 > > like it, he can just resist the temptation to abuse it.
 > 
 > Is there a reole for Bazaar to be opinionated on the matter?

Sure, but that would be stupid.  It would alienate some users to no
purpose, because they can implement the same series of commits but at
unnecessarily high cost, by using shelve.

 > To make different workflows possible, but to make the more destructive
 > one (in this case, the one which encourages committing a working tree
 > that the hacker has never actually had on disk) more difficult than
 > doing it a more recommended way (‘bzr shelve’)?

Who cares what the hacker does or does not have on disk?  The question
that matters is whether a particular version has ever been tested.
bzr shelve makes it easier for the hacker to do the testing manually,
but those who want interactive commit probably won't test the interim
version anyway.  At least for me, a typical use case for a partial
commit (whether only of certain files, or something more fine-grained
as permitted by Darcs) is that I have an *untestable* change (such as
a typo fix or other documentation change irrelevant to my main task)
that I want to isolate in a separate changeset.  (This use case has
been mentioned by others.)

A partial commit with interactive hunk selection is a very efficient
way to make such commits.

And if there's a buildbot tracking changes to the tree, the version
*will* exist on disk, just not on the hacker's disk, and *will* be
tested, just not by the hacker.  Now what do you have to complain
about?

 > It seems to me that this is the case with re-writing history, for
 > example.

I could argue that, but let me just point out that the analogy is
broken.  Recording history is bzr's responsibility, and it makes sense
for bzr to make it hard to lose history.  Enforcing testing in a
workflow is not and never was bzr's responsibility.

 > > As Pythonistas say, "we're all consenting adults around here."

 > Pythonistas also say “There should be one – and preferably only one –
 > obvious way to do it”. For the task at hand I think ‘bzr shelve’ is the
 > one obvious way to do it.

No, once you've actually tried Darcs, Darcs-style interactive commit
is the obvious way to do it.

It's just that, unfortunately, bzr doesn't implement it yet.