Questions about experimental Spice compositor rebase

[Pekka Paalanen]

On Mon, 29 Feb 2016 17:07:23 +0100
Yury Shvedov <shved at lvk.cs.msu.su> wrote:

> On 02/29/2016 04:39 PM, Fabio Fantoni wrote:

> > Usually I keep do rebase of my patches (with git rebase -i) and other 
> > patches in development to test always queued to upstream commits to 
> > make it easier and faster update them, have it ready to post upstream 
> > for review any version and add the new upstream commits until my 
> > patches are accepted upstream.
> > For example: https://github.com/Fantu/Xen/commits/rebase/m2r-testing-4.6
> > Probably will be good also for your project (I can do it in newer branch).  
> I don't suppose myself the master of git but in my opinion using git 
> rebase is a bad practice:
> 
>   * rebase can rewrite the history. It can take the part of chain and
>     move fully in another place. While merge doesn't changes history. It
>     simply creates new commit on top of two branches
>   * with rebase in case of conflict you have to resolve them in many
>     commits, while with merge you need to resolve conflict once at the top
>   * sometimes you need to perform code changing while action. In rebase
>     you have to do it in several commits, while with merge - only in one
>   * rolling back the rebase could be really painful
>   * I already had problems with rebase, so now I use it only when it is
>     realy needed and when I can't use merge (never).

Hi,

you cannot say one is always better than the other.

If your history is not of reviewable quality, e.g. adhering to [1],
then your history is worthless to others and possibly to you too. Then
rebasing does not lose anything and it gives you chance to improve your
commit series to acceptable quality.

The history should also be bisectable, which means that every commit is
supposed to build and run at least as well as the commit before it, for
the features that were already present.

If merging a branch has so many conflicts that you end up essentially
rewriting half of the code your branch brings in, I'd question the
value of keeping that history also in that case.

But, if the history has a good quality, it is reviewable and
bisectable, and the merge into master is not a huge rewrite, then there
certainly is value in keeping the history. Especially if the commits in
the branch have undergone serious testing which you have also
documented in the history.

History exists for people to read it, and for regression testing.
Rewriting history is often mandatory for creating a patch series that
can be reviewed. It is more work, but that work is what makes the
history valuable.

Projects also have different styles on choosing between branch merging
and rebasing when integrating new changes. Wayland and Weston projects
use the mailing list for review (or Phabricator soon, perhaps), and we
value linear history, which means rebasing is an integral part of the
development process. Applying a patch from a mailing list or Phab is
essentially a rebase.


Thanks,
pq

[1] http://who-t.blogspot.fi/2009/12/on-commit-messages.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20160301/4eb4b8cd/attachment.sig>