Re: What's cooking in git.git (Apr 2018, #01; Mon, 9)

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Apr 9, 2018, 20:14 UTC
Message-ID: <nycvar.QRO.7.76.6.1804092110300.55@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz>
In-Reply-To: <xmqqd0z865pk.fsf@gitster-ct.c.googlers.com>

Hi Junio,

On Mon, 9 Apr 2018, Junio C Hamano wrote:

Show 20 quoted lines

> * js/rebase-recreate-merge (2018-02-23) 12 commits
>   (merged to 'next' on 2018-03-15 at 3d1671756f)
>  + rebase -i: introduce --recreate-merges=[no-]rebase-cousins
>  + pull: accept --rebase=recreate to recreate the branch topology
>  + sequencer: handle post-rewrite for merge commands
>  + sequencer: make refs generated by the `label` command worktree-local
>  + rebase: introduce the --recreate-merges option
>  + rebase-helper --make-script: introduce a flag to recreate merges
>  + sequencer: fast-forward merge commits, if possible
>  + sequencer: introduce the `merge` command
>  + sequencer: introduce new commands to reset the revision
>  + git-rebase--interactive: clarify arguments
>  + sequencer: make rearrange_squash() a bit more obvious
>  + sequencer: avoid using errno clobbered by rollback_lock_file()
> 
>  "git rebase" learned "--recreate-merges" to transplant the whole
>  topology of commit graph elsewhere.
> 
>  This serise has been reverted out of 'next', expecting that it will
>  be replaced by a reroll on top of a couple of topics by Phillip.

Sorry, it took a little longer. I did decide in the end that --rebase-merges is a better name for the option.

And I worked on the add-on patch series, too, mainly to prove that we can switch to a better strategy than blindly re-create recursive merges from scratch. That part is not really done to my satisfaction, though: while I already demonstrated that Sergey's approach causes way too many merge conflicts to be useful in practice, I now have a reproducer to show that even Phillip's strategy *can* cause awful (and avoidable) merge conflicts.

For anybody who is interested in the specifics, I'd like to point you to the `sequencer-shears` branch thicket in https://github.com/dscho/git (it is a moving target, but you should find the commit called "t3430: add some realistic tests for --rebase-merges" that demonstrates the issues.

Be that as it may, I will send out a new iteration of the patch series (the --rebase-merges one, formerly known as --recreate-merges) soon (hopefully still today).

Ciao, Dscho