[Kde-scm-interest] Re: Usage of pull rebasing and merges

Johannes Sixt j.sixt at viscovery.net
Wed Feb 9 08:50:12 CET 2011


Am 2/9/2011 8:16, schrieb John Tapsell:
> Or you could have just "git pull --rebase".  You chose to merge, and
> that's great, but I'm saying that you can do perfectly fine with the
> three commands I gave.

"git pull --rebase" may be a reasonable workflow as long as you develop
only small or medium-sized (or completely new and *independent*, and I
*really* mean *independent*) stuff. But it has two drawbacks.

The first one started this thread: When you have to work on more than two
branches, most prominently, when you make a bugfix on 4.6 and need to
"forward port" it to master, then you must not apply "pull --rebase" on
master *after* you merged your local 4.6 into your local master. (Here,
I'm assuming that the recommended workflow for this kind of changes will
be to merge rather than to cherry-pick.)

The second drawback has to do with efficient testing, and it is much more
serious, IMO. When you make a series of changes, you are expected to
ensure that each individual change is self-contained and passes tests.
I.e., after N commits, you have run N tests, at least. When you rebase
this series on top of a new upstream, you have to run another N tests
because you have N new commits. OTOH, when you merge, you have to run only
*one* test.

With small and medium-sized changes, N new tests may be bearable, but any
change of decent size is much better to keep in a topic branch that you
merge, because then you have *one* state that you *know* is good, because
you tested it while you developed it. With a rebase workflow, your topic
is a moving target, and you can be 100% sure that it is good only if you
have to time to test and to test again, and again.

In my book, a "nice" history is not when it is a linear string of changes,
but rather when each commit represents a good (well tested) project state.
If, after a rebase, you test only the tip commit, but not the N-1 other
rebased commits, you do not conform to this definition of "nice".

-- Hannes


More information about the Kde-scm-interest mailing list