Re: State of the repository conversion

[Stephen J. Turnbull]

About the workflow, Eli Zaretskii writes:

 > It is better to draw upon the knowhow and experience of veteran git
 > users among us to identify in advance the preferred workflows,

And the resulting recommendations will be ignored in favor of the
convenience of the powers that be, as the recommendations for Bazaar
were.  (And mostly, so were such recommendations ignored when Python
converted from Subversion to Mercurial.)  I don't know about Eric's
experience (he's participated in a lot more of these than I have), but
I suspect at least subconsciously he's thinking the same thing.

Please remember what that convenience boiled down to: "don't change
anything that doesn't need to change, because the current workflow
works fine for us".  I admit I was wrong to suggest "the workflows
that work in other projects."  Experience showed that people adopted
those workflows as needed for their own work, but many people
continued to use Bazaar as if it were CVS.  It's only a tiny bit
harder to use git that way (no bound branches or lightweight
checkouts, so you do have to learn to push, and merge from upstream if
your push wouldn't be a fast-forward).  But people are used to the
up-to-date check failing, I suspect, and it's not that hard to learn
-- everybody did learn in the bad old days of CVS.  So it amounts to
learning that you need to "git push" after "git commit", if you were
using a checkout with Bazaar.

People who do want to use git as a free-branching distributed VCS
already know how to do that, and they may or may not follow
"recommended" workflows themselves.

So I think this is really a non-problem.  Just translate bzr commands
to the git equivalents, configure public repos to prevent "destructive"
commands (require fast-forward pushes, mostly), and let the git fans
teach those who want to improve their git skills as issues come up.
Emacs doesn't have much structure in its abstract workflow (it
basically comes down to "hack, save, push") that requires careful
consideration of VCS operations.