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

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Apr 9, 2018, 21:32 UTC
Message-ID: <nycvar.QRO.7.76.6.1804092325100.55@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz>
In-Reply-To: <nycvar.QRO.7.76.6.1804092110300.55@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz>

Hi,

On Mon, 9 Apr 2018, Johannes Schindelin wrote:

Show 24 quoted lines

> 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.
> 
> [.,..] I will send out a new iteration of the patch series (the
> --rebase-merges one, formerly known as --recreate-merges) soon
> (hopefully still today).

I encountered one more scenario I need to handle: when all the patches in a topic branch were already applied upstream, I typically want to skip merging a now-empty branch.

Since upstream might have changed the patches subtly (so that --cherry-pick does not skip them), the user may have had to `git rebase --skip` the unmodified version of the now-upstream patches. Therefore, we cannot test at todo list generation time whether a merge can be skipped because it would merge an ancestor of its first parent.

I plan on introducing a flag similar to "rebase-cousins" for this: probably "skip-empty-merges", defaulting to skipping them (because why would you want to merge something that is already part of the HEAD's commit history?).

However, I won't be able to finish this today.

Thanks for your patience, Dscho