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

[Daniel Carrera]

On Wednesday, June 06, 2012 at 10:10 PM, Stephen J. Turnbull <stephen at xemacs.org> wrote:

> 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.

That's how I feel. I would add that I have experimented with "shelve" and some times it doesn't let me select individual hunks in a file if they are very close. So the only way to commit the change I want (e.g. fixing a typo in a comment) is to undo some of the work I've done in nearby lines, then commit, and then re-add my changes... That feels like something my VCS would ideally take care of... I currently use Hg with the crecord plugin because it gives me per-line granularity.

> 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.

Indeed. I am not likely to change my testing patterns because of prodding from my VCS. If I decide that clarifying a point in the source documentation does not require a test run, my VCS is not going to convince me otherwise.

Another example I gave earlier is if I add a new ODE integrator to my math library, and I change one of my simulations to use the new ODE integrator. I will usually want to make that two different commits. It is nonsense to speak of testing the first commit on its own - I can't test a new function in the library unless I use the function somewhere.... But I also don't want to mix together a change to the library with a change to one of the 8 simulations in my project directory. To me the logical thing is to have one changeset for the library, and one changeset for each simulation that I choose to move to the new integrator.

This scenario is not a rare case for me. Most of my program code is in libraries. The previous example about documentation is not rare for me either. I like having a lot of documentation embedded in my source files.



> > 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.

Indeed.

Cheers,
Daniel.