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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Junio,

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).

Ciao,
Dscho



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux