On Mon, 29 Feb 2016 17:07:23 +0100 Yury Shvedov <[email protected]> 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
pgpZeXdowSPpg.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
