Re: git loses a commit after reordering.

[Johannes Schindelin]

Hi Junio, Kevin & Nikita,

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

> Nikita Orlov  writes:
> 
> >>On Sun, 30 Apr 2017, 1:56 +03:00 from Kevin Daudt :
> >>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%25li...@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 
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  ` 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

Re: git loses a commit after reordering.

[Junio C Hamano]

Nikita Orlov  writes:

>>On Sun, 30 Apr 2017, 1:56 +03:00 from Kevin Daudt :
>>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%25li...@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.

[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%25li...@haller-berlin.de/