Re: VC mode and git

[Stephen J. Turnbull]

Alan Mackenzie writes:
 
 > Irreversable?  Any patch operation without conflicts is reversable, and
 > if there are conflicts, a backup of the original should have been made by
 > the patch program.

In a VCS, backup is spelled C-O-M-M-I-T.  Which is exactly what you
say you don't want to do.  *shrug*

 > Anyhow, there are lots of irreversable things that happen in a VCS
 > repository.  The act of having committed, or merged, or whatever
 > cannot, with some exceptions, be reversed.

Of course.  But I mean irreversible changes to the working tree.

 > It is documented in the hg page.  It says (under merge): "The current
 > working directory is updated with all changes made in the requested
 > revision since the last common predecessor revision.".  If this doesn't
 > work when a file in the W.D. has been changed, that looks like a bug,
 > whether in the code or the documentation.

The code won't permit.

 > > .... and Bazaar requires that you use "bzr merge --force".  I really
 > > don't understand how you can criticize git alone for this.
 > 
 > Because it's only git that's ever given me problems in this
 > respect.  I don't recall ever having problems with bzr update when
 > I had uncommitted changes.  I use hg in such a way that mergeing is
 > rarely, if ever, needed.

It seems bzr update doesn't have that restriction.  I don't know why
not, bzr merge does have it.  Both are so documented.  My experience
with hg in XEmacs is that when other developers are active, I need an
explicit merge frequently.

If bzr and hg don't give you problems but git does, then either your
git workflow deviates substantially from the workflows you use with
bzr and hg, or you've just been lucky to not get nasty conflicts that
are difficult to resolve with bzr and hg.  I suspect it's the latter,
and the big difference is the projects, not the VCSes.  Specifically,
I suppose Emacs gets a lot more changes from other developers per unit
time than your other projects do.

 > I do not love risk.  The risk of getting my repository in an
 > inextricable tangle, like Richard has done, far outweighs any
 > supposed risks of just-in-time committing.

Richard's repo is tangled *because* he, like you, doesn't commit until
he's ready to push.  If you keep your changes in commits instead of
the working tree, it's *very* hard to get inextricably tangled in git
because a quick reset puts you back in control, in a known state.