[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Git transition workflow

From: Stephen J. Turnbull
Subject: Re: Git transition workflow
Date: Wed, 13 Aug 2014 12:59:42 +0900

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 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]