Re: Git transition workflow

[Stephen J. Turnbull]

Achim Gratz writes:
 > Jan Nieuwenhuizen writes:
 > >     Daily work
 > >     If you’re using the command-line:
 > >
 > >     git pull
 > >
 > > May I suggest to change this to
 > >  
 > >     git pull --rebase / git pull -r
 > >
 > > or we're going to see a whole lot of merge commits.

This requires people who don't already know how to "git rebase" to
learn it (I mean the resolution workflow, not the command, of course).
It will get a lot of pushback, and I expect that those users will
revert to "git pull".  On the other hand, merge conflicts are familiar
from ancient times, and doesn't require learning a new workflow.

You'll probably get used to it; I did when XEmacs moved to hg (and
after several years of git use with rebasing before pushing, I was
pretty disgusted by the XEmacs repo's DAG in the early days).  It was
not a big deal for most of our developers, so I accepted the
inevitable.  You probably should too.

It should be "easy" to write a commit hook that just exchanges parents
of a merge commit when the first parent's committer (author?) is the
same as the merge commit's and the other parent is different.  This
(with high probability) preserves the mainline in a bzr-like fashion,
and would be easy for CVS-like users to adopt (since only the merge
commit object is manipulated, and that is automagic, no workflow
change is involved).

Then developers who really hate "redundant" merge commits can use
"log --first-parent" to see pretty much what they want (the merge
commit that integrates a trivial one-or-two-commit branch, and rebased
commits that fast-forward when pushed).  You'll miss important history
from a few feature branches, but that's generally fixable with
"log --committer" (plus --date or --skip to drill down).  This is a
workflow change for you, I grant, but you are more able to adopt it
easily or do without, and your decision affects only you.

Note that I generally agree with you about best practice (and disagree
with the "even private history is sacred"/"rebased commits need
testing" crowd).  However, as I wrote before, Emacs doesn't *need*
such best practice (let alone generally conform to it currently), and
my experience with the Python, XEmacs, and Emacs CVCS-to-DVCS
migrations is that trying to implement workflow changes at the same as
changing VCSes doesn't work -- people too important to discipline balk
and/or threaten to delay the move (cf. "vc-find-conflicting-files must
work"), new committers don't know about the policies, etc.

Take an improvement in