git loses a commit after reordering.

Hello, my name is Nikita (male).

Could you explain this (subject) is a bug or a feature?

I follow Pro Git Reordering Commits (https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History) to reorder commits and lose one without any conflict.

I've got git under Windows 10 Enterprise 64-bit installed through Chocolatey.

Chocolatey v0.10.5 chocolatey 0.10.5 git 2.12.2.2 gitpad 1.2 msysgit 1.7.10.20120526 4 packages installed.

$ git --version git version 2.12.2.windows.1

Example.

There are two branches:
- master
- feature-branch

feature-branch is on master.

MyPC MINGW64 /path/to/repository (feature-branch)

$ git log -9 --oneline 5045d1eca Merge branch 'feature-3' into 'feature-branch' 006fc549d Done Task 3 a2a52441e Merge branch 'feature-2' into 'feature-branch' e73527115 Done Task 2 f0454685e Merge branch 'feature-1' into 'feature-branch' 3ab82e4c6 Done Task 1 f15037d64 Some independent changes 2 cba3ebb4e Some independent changes 1 bc19473cf Head of master

$ git rebase -i -p master

I change the rebase script from:

pick cba3ebb4e Some independent changes 1 pick f15037d64 Some independent changes 2 pick 3ab82e4c6 Done Task 1 pick f0454685e Merge branch 'feature-1' into 'feature-branch' pick e73527115 Done Task 2 pick a2a52441e Merge branch 'feature-2' into 'feature-branch' pick 006fc549d Done Task 3 pick 5045d1eca Merge branch 'feature-3' into 'feature-branch'

to:

pick f15037d64 Some independent changes 2 pick cba3ebb4e Some independent changes 1 pick 3ab82e4c6 Done Task 1 pick f0454685e Merge branch 'feature-1' into 'feature-branch' pick e73527115 Done Task 2 pick a2a52441e Merge branch 'feature-2' into 'feature-branch' pick 006fc549d Done Task 3 pick 5045d1eca Merge branch 'feature-3' into 'feature-branch'

No any conflict and I see: Successfully rebased and updated refs/heads/feature-branch.

$ git log -9 --oneline 47e579ce0 Merge branch 'feature-3' into 'feature-branch' a7c6b8b8e Done Task 3 5df7ce105 Merge branch 'feature-2' into 'feature-branch' 0197797d7 Done Task 2 e680488fe Merge branch 'feature-1' into 'feature-branch' 731a57580 Done Task 1 10da9cd85 Some independent changes 2 bc19473cf Head of master d91947abd Commit under the head of master

"Some independent changes 1" is missed and its changes are missed as well.

I tried to move another commit to a farther distance below but there was still only one missed commit.

Could you explain it?

Thank you in advance and sorry for my English.

Best, Nikita

On Thu, Apr 27, 2017 at 10:43:16AM +0300, Nikita Orlov wrote:

[man git-rebase][0] mentions this under the bug section:

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?

Is there a simple/the right way how to do reordering without losing merge commits now? E.g., I've done it by git-cherry-pick during interactive rebasing.

Thanks.

-- Nikita Orlov

Nikita Orlov <fatemail@mail.ru> writes:

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

Hi Junio, Kevin & Nikita,

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

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