Re: git loses a commit after reordering.

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: May 2, 2017, 14:29 UTC
Message-ID: <alpine.DEB.2.20.1705021608580.3480@virtualbox>
In-Reply-To: <xmqqwpa0f8zm.fsf@gitster.mtv.corp.google.com>

Hi Junio, Kevin & Nikita,

On Mon, 1 May 2017, Junio C Hamano wrote:

Show 17 quoted lines

> Nikita Orlov <fatemail@mail.ru> writes:
> 
> >>On Sun, 30 Apr 2017, 1:56 +03:00 from Kevin Daudt <me@ikke.info>:
> >>Not sure if this is the case here, but it at least confirms that rebase
> >>--preserve-merges was not meant to reorder commits.
> >>
> >>See [this][1] thread for more background on this limitation.
> >>
> >>[0]: https://git-scm.com/docs/git-rebase#_bugs
> >>[1]: https://public-inbox.org/git/1mtveu4.19lvgi1c0hmhaM%25lists@haller-berlin.de/
> >
> > This is it. As I understand git-rebase--helper is an attempt to fix the bug.
> > But it's still in development, isn't it?
> 
> The impression I have been getting is that "rebase -p" was abandoned
> by its author, and the recent rebase--helper work is solely for
> re-implementing the performance sensitive part of "-i" (interactive).

Indeed. The design of `-p` does not really allow for it to be fixed, as it overloads the meaning of `pick` to also "pick a merge commit". This further limits the usefulness of the `-p` feature by not allowing to adjust merge commits to merge anything else than the rebased commit^2 into anything else than the rebased commit^, which is kind of a realy big design bug.

But then, I never meant for -p to be interactive, either, and others made it so. Therefore I refuse to take the blame for that.

After my rebase-i-extra patch series (which Junio currently calls rebase-i-final) will be accepted, I plan to do a bit more work on the rebase -i front.

One thing I have in mind is to implement a new --recreate-merges option. It will be closely modeled after the functionality of my Git garden shears [*1*] that I used to maintain Git for Windows' dozens of patch series on top of git.git's `maint` branch.

Essentially, I want to introduce new commands (that are implemented as `exec` calls in the Git garden shears, with the noticeable performance implications on Windows) that

- allow to mark the current commit with a label,

- reset HEAD to a given label

- merge a branch by a given label

These commands would be new commands, and therefore backwards-compatible with the current command set. No need for special-casing `pick` in the case of the new mode.

And then I would patch in the new --recreate-merges option simply by generating a todo list using those new commands.

The todo list may look somewhat like this:

	mark onto

	# branch <my-cool-feature>
	pick deadbee5 lay some groundwork
	pick beeb0bab implement the cool feature
	pick deebadee document the cool feature
	mark my-cool-feature

	reset onto
	pick cabbadab fix a tyop
	remerge d00beedo my-cool-feature

where `remerge <original-commit> <label>` would merge the commit with the given label using the commit message of the original merge commit.

This would result in a history like this:

------------------------------------------ fix a tyop - Merge my-cool-feature
 \                                                    /
  lay some groundwork - implement ... - document ... -

If you have an idea for a better name than `remerge` (I do want to leave `merge` as command to create new merge commits that have not been there before), I'd like to hear your suggestion.

Ciao, Johannes

Footnote *1*: https://github.com/git-for-windows/build-extra/blob/master/shears.sh