Changing the UI of checkout

[Matthew D. Fuller]

On Mon, Apr 20, 2009 at 12:58:17AM +0900 I heard the voice of
Stephen J. Turnbull, and lo! it spake thus:
> 
> Of course you do.  As soon as you save a change, *you're out of
> sync*.

While philosophically apt, this is pragmatically nugatory.  And
philosophically, you don't take the point far enough.  Why give such
importance to the point where you save a change?  Why not when it's
made in your editor?  Why not when it's made in your head?  Why not
when it's conceptual, before translated into code?

In a practical sense, from the perspective of a VCS, anything that
happens before you commit is Not My Problem.


> The whole idea of checkouts with "working trees" is ill-conceived.
> [...]  But anybody who makes changes to the code is putting
> themselves in harm's way by doing it in a checkout.

This is meaningless.  You can't commit WITHOUT a working tree.
Checkout is just how you get the working tree.


> To protect your work, there should be a place to commit it. [...]

There is.  The branch connected to the working tree you're in.  If you
want to commit, but DON'T want to commit to that branch, the problem
isn't that commit will put it there, it's that you've setup your
workspace wrong.  Work in the working tree of the branch you want to
work on.

Your objection is that you don't want a workflow where there are
multiple working trees connected to a single branch.  Which is fine;
that workflow has implications significantly different from one where
there is only ever 1 working tree connected to a given branch.  But
just because you don't want those properties doesn't mean other people
don't.


-- 
Matthew Fuller     (MF4839)   |  fullermd at over-yonder.net
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
           On the Internet, nobody can hear you scream.