git loses a commit after reordering.

git loses a commit after reordering.

[Nikita Orlov]

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.

> choco list -l git
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

Re: git loses a commit after reordering.

[Kevin Daudt]

On Thu, Apr 27, 2017 at 10:43:16AM +0300, Nikita Orlov wrote:
> Hello, my name is Nikita (male).
> 
> Could you explain this (subject) is a bug or a feature?
> 
> [snip]
> 
> "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

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

> The todo list presented by --preserve-merges --interactive does not
> represent the topology of the revision graph. Editing commits and
> rewording their commit messages should work fine, but attempts to
> reorder commits tend to produce counterintuitive results.

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/

Re[2]: git loses a commit after reordering.

[Nikita Orlov]

>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?

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

Re: git loses a commit after reordering.

[Junio C Hamano]

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

Re: git loses a commit after reordering.

[Johannes Schindelin]

Hi Junio, Kevin & Nikita,

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

> 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