Re: What's cooking in git.git (Apr 2018, #01; Mon, 9)
- Date: Mon, 9 Apr 2018 22:14:08 +0200 (DST)
- From: Johannes Schindelin <Johannes.Schindelin@xxxxxx>
- Subject: Re: What's cooking in git.git (Apr 2018, #01; Mon, 9)
On Mon, 9 Apr 2018, Junio C Hamano wrote:
> * 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).