Experiences with Bazaar in a Commercial Environment

[Stephen J. Turnbull]

Martin Pool writes:
 > On 22 February 2012 20:13, Stephen J. Turnbull <stephen at xemacs.org> wrote:
 > > No, it *is* specific to Bazaar.  Bazaar is the only major DVCS that
 > > encourages you to merge into a dirty workspace.
 > 
 > Why do you say bzr encourages this?  'bzr merge' will error by default
 > if the tree is dirty.

Sorry, I should have qualified that statement.  I meant in the case of
a checkout (heavy or light), because that's the "obvious" way to deal
with "can't commit" in a centralized workflow.  That's what I always
did with CVS, unless I had an unusually large (say > 10 hunks) diff
(and then I'd "stash" a diff and apply with patch).  But I tried very
hard to avoid that, eg by using feature branches (even in CVS!) if I
expected to produce a large change.

 > results uncommitted.  They may conflict.  But git-checkout also
 > carries your uncommitted changes without needing to be forced, and
 > istr hg does too.

I don't see your point.  "git checkout $BRANCH" will not do anything
if any dirty files would be changed by the checkout.  So "git diff
HEAD" gives the same result (except for listing a different parent
commit in the headers) before and after the checkout.  This is not
true for the use case we're discussing.

And of course "git checkout $FILE" is *supposed* to overwrite the
file, so you won't be surprised by that.