>>>>> "Rich" == Richard Lowe <richlowe at richlowe.net> writes:
Rich> More practically, we can return them to either where they were, or Rich> the new tip (another option, which I didn't mention). I like the option of returning at the new tip. If we require the user to start at the local tip, and we always end at the new tip, the user always sees consistent behavior. The only change in the case of an exception is that one or more branches didn't go away. Rich> That's part of what I was considering with "further changes" Rich> above, currently we take an informed guess based on the branch the Rich> user is on (which, in the case of recommit, will always lead to a Rich> single revision. Rich> Whether that remains true depends on what we decide to do about Rich> in-workspace branching (allow it? disallow it?) As we discussed on IRC, disallowing branching is simpler, and it reflects what we do today with TeamWare. So I think we should disallow it, and if someone someday wants to allow branching, they can figure out how to make it work. Rich> It would make sense, to me, to force them to already be at the tip Rich> when they do this, however, we take them there anyway as part of Rich> running. The advantage of forcing the user to do it is that it makes it a conscious act on his part--less mysterious stuff going on behind the user's back. >> Also, what happens to the new tip if we catch an exception from >> q.strip()? Rich> It remains. I'm unwilling to allow recommit to remove a change Rich> that is not going to remain in some other fashion (this is why we Rich> construct and commit the conglomerate *then* remove local change), Rich> I'm not willing to remove the new tip if there's any possibility Rich> of us having removed any of the prior change, and in this case, we Rich> have. It would be unsafe. Yes, good point. mike
