[MERGE/RFC] Userdoc Driven Design on the Bazaar 2.0 UI

[Stephen J. Turnbull]

John Arbash Meinel writes:
 > Stephen J. Turnbull wrote:
 > > Neil Martinsen-Burrell writes:
 > > 
 > >  > Yes, one can ``echo "git push" > .git/hooks/post-commit`` but that
 > >  > is much more fussy than ``bzr bind`` and again has the wrong
 > >  > ordering for integrity.
 > > 
 > > I don't understand what you mean by that.  Should I infer that "data
 > > integrity" requires that the VCS should push the changes, then fetch
 > > the history back?

 > If two people are using the same "post commit push to remote" hook, then
 > if they both commit one of them will fail.

Sure.  That's not an "integrity" problem, though.  Unless a conflict
is involved, you do a little dance, merge, and commit.  Mercurial does
this automagically, in git you could either "stash" or do a little
dance that could be automated in a shell script with no parameters.
In both cases, everybody will see the same DAG (although in Mercurial
my most recent revnos will be different from yours).  In git even the
SHA1s of the commits will be the same.

 > They won't find out about this until after they have already
 > committed.

I still don't see an integrity issue, just a minor inconvenience.

Unless you have a workflow that insists on linear history.  But even
then, in fact you don't really get one.  You have a history with
several lines of development multiplexed into a single commit stream,
with no automatic way to disentangle them.

 > The big thing is that you don't actually need to 'rebase' the
 > commit,

In Mercurial and git you don't need to rebase *at all*.  In both cases
the natural workflow would involve a merge, not a rebase.  Not to
mention that in Darcs, rebasing is *meaningless*.  Nor to mention that
(absent a merge conflict, in which case all workflows are painful),
rebasing will be really cheap.  Really, all the time and effort is due
to a failed push, a pull, and a re-push ... which can't be reduced
because they are *required to construct the scenario* in the first
place.

 > as the commit wasn't really generated. It removes an extra
 > step (not to mention needing to be aware of the notification that
 > the push failed, etc.)

But to my mind it's *not* an extra step.  In fact, the lack of a local
commit is a real data integrity risk.  Your workspace is *gone* once
you update.  If you get different, less comforting test results after
the pull and fixup, you're going to have to figure out how to undo it,
which may be *impossible* if in resolving a merge conflict you chose
to use text from the pull rather than the text which exists only in
your workspace (and in your wetware memory, maybe, *if* you're lucky).

IMHO the idea that commits are cheap is the foundation of dVCS
sanity.[1]  I find it more than a little perverse that a workflow that
puts your work at risk to avoid the expense of a commit is being
advocated in the name of "data integrity".


Footnotes: 
[1]  In fact, dVCS commits can be so cheap that it's quite reasonable
to put `(shell-command "$VCS commit")' on your after-save-hook.