Johannes Schindelin [off-list ref] writes:
[...]
+--recreate-merges::
+ Recreate merge commits instead of flattening the history by replaying
+ merges. Merge conflict resolutions or manual amendments to merge
+ commits are not preserved.
I wonder why you guys still hold on replaying "merge-the-operation"
instead of replaying "merge-the-result"? The latter, the merge commit
itself, no matter how exactly it was created in the first place, is the
most valuable thing git keeps about the merge, and you silently drop it
entirely! OTOH, git keeps almost no information about
"merge-the-operation", so it's virtually impossible to reliably replay
the operation automatically, and yet you try to.
IMHO that was severe mistake in the original --preserve-merges, and you
bring with you to this new --recreate-merges... It's sad. Even more sad
as solution is already known for years:
bc00341838a8faddcd101da9e746902994eef38a
Author: Johannes Sixt [off-list ref]
Date: Sun Jun 16 15:50:42 2013 +0200
rebase -p --first-parent: redo merge by cherry-picking first-parent change
and it works like a charm.
-- Sergey
On Tue, Feb 6, 2018 at 10:16 PM, Sergey Organov [off-list ref] wrote:
Johannes Schindelin [off-list ref] writes:
[...]
quoted
+--recreate-merges::
+ Recreate merge commits instead of flattening the history by replaying
+ merges. Merge conflict resolutions or manual amendments to merge
+ commits are not preserved.
I wonder why you guys still hold on replaying "merge-the-operation"
instead of replaying "merge-the-result"? The latter, the merge commit
itself, no matter how exactly it was created in the first place, is the
most valuable thing git keeps about the merge, and you silently drop it
entirely! OTOH, git keeps almost no information about
"merge-the-operation", so it's virtually impossible to reliably replay
the operation automatically, and yet you try to.
I'm not sure I follow what you mean here?
You mean that you'd want this to actually attempt to re-create the
original merge including conflict resolutions by taking the contents
of the result?
How do you handle if that result has conflicts? What UX do you present
to the user to handle such conflicts? I don't think the normal 3-way
conflicts would even be possible in this case?
Thanks,
Jake
IMHO that was severe mistake in the original --preserve-merges, and you
bring with you to this new --recreate-merges... It's sad. Even more sad
as solution is already known for years:
bc00341838a8faddcd101da9e746902994eef38a
Author: Johannes Sixt [off-list ref]
Date: Sun Jun 16 15:50:42 2013 +0200
rebase -p --first-parent: redo merge by cherry-picking first-parent change
and it works like a charm.
-- Sergey
Am 07.02.2018 um 07:16 schrieb Sergey Organov:
Johannes Schindelin [off-list ref] writes:
[...]
quoted
+--recreate-merges::
+ Recreate merge commits instead of flattening the history by replaying
+ merges. Merge conflict resolutions or manual amendments to merge
+ commits are not preserved.
I wonder why you guys still hold on replaying "merge-the-operation"
instead of replaying "merge-the-result"? The latter, the merge commit
itself, no matter how exactly it was created in the first place, is the
most valuable thing git keeps about the merge, and you silently drop it
entirely! OTOH, git keeps almost no information about
"merge-the-operation", so it's virtually impossible to reliably replay
the operation automatically, and yet you try to.
Very well put. I share your concerns.
-- Hannes
IMHO that was severe mistake in the original --preserve-merges, and you
bring with you to this new --recreate-merges... It's sad. Even more sad
as solution is already known for years:
bc00341838a8faddcd101da9e746902994eef38a
Author: Johannes Sixt [off-list ref]
Date: Sun Jun 16 15:50:42 2013 +0200
rebase -p --first-parent: redo merge by cherry-picking first-parent change
and it works like a charm.
-- Sergey
Hi,
On Wed, 7 Feb 2018, Sergey Organov wrote:
Johannes Schindelin [off-list ref] writes:
[...]
quoted
+--recreate-merges::
+ Recreate merge commits instead of flattening the history by replaying
+ merges. Merge conflict resolutions or manual amendments to merge
+ commits are not preserved.
I wonder why you guys still hold on replaying "merge-the-operation"
instead of replaying "merge-the-result"?
This misses the point of rebasing: you want to replay the changes.
The latter, the merge commit itself, no matter how exactly it was
created in the first place, is the most valuable thing git keeps about
the merge, and you silently drop it entirely!
You miss another very crucial point. I don't blame you, as you certainly
have not used the Git garden shears for years.
Let me explain the scenario which comes up plenty of times in my work with
Git for Windows. We have a thicket of some 70 branches on top of git.git's
latest release. These branches often include fixup! and squash! commits
and even more complicated constructs that rebase cannot handle at all at
the moment, such as reorder-before! and reorder-after! (for commits that
really need to go into a different branch).
Even if you do not have such a complicated setup, it is quite possible
that you need to include a commit in your development that needs to be
dropped before contributing your work. Think e.g. removing the `-O2` flag
when compiling with GCC because GDB gets utterly confused with executables
compiled with `-O2` while single-stepping. This could be an initial commit
called `TO-DROP` or some such.
And guess what happens if you drop that `pick` line in your todo list and
then the `merge` command simply tries to re-create the original merge
commit's changes?
Exactly. The merge will become an evil merge, and will introduce that very
much not-wanted and therefore-dropped changes.
OTOH, git keeps almost no information about "merge-the-operation", so
it's virtually impossible to reliably replay the operation
automatically, and yet you try to.
That is true. However, the intended use case is not to allow you to
recreate funny merges. Its use case is to allow you to recreate merges.
At a later stage, I might introduce support to detect `-s ours` merges,
because they are easy to detect. But even then, it will be an opt-in.
IMHO that was severe mistake in the original --preserve-merges, and you
bring with you to this new --recreate-merges... It's sad.
Please refrain from drawing this discussion into an emotional direction.
That is definitely not helpful.
Even more sad as solution is already known for years:
bc00341838a8faddcd101da9e746902994eef38a
Author: Johannes Sixt [off-list ref]
Date: Sun Jun 16 15:50:42 2013 +0200
rebase -p --first-parent: redo merge by cherry-picking first-parent change
and it works like a charm.
It might work for you, as you probably used --preserve-merges, and dealt
with the fact that you could neither drop nor reorder commits.
So --preserve-merges --first-parent is probably what you were looking for.
Instead, --recreate-merges is all about allowing the same level of freedom
as with regular interactive rebases, but recreating the original commit
topology (and allowing to change it, too).
Therefore, I think that it would be even harmful to allow
--recreate-merges --first-parent *because it would cause evil merges*!
And I totally could see myself being vexed again about options that worked
perfectly well (just like --preserve-merges) being completely messed up by
allowing it to be combined with options *that they cannot work with* (just
like --preserve-merges --interactive, a *huge* mistake causing so many
annoying "bug" reports: I *never intended it that way because I knew it
would not work as users expect*).
So no, I do not think that --recreate-merges --first-parent is a good idea
at all. Unless you try to do that non-interactively only, *and disallow it
in interactive mode*. Because the entire point of the interactive rebase
is to allow reordering and dropping commits, in --recreate-merges even
moving, introducing and dropping merge commits. The --first-parent option
flies in the face of this idea.
Ciao,
Johannes
edit: Sending again, hopefully without HTML :). Sorry for spamming.
Hi, I think --recreate-merges is a very exciting feature.
I've also been puzzled by why we can't just pick merge commits directly
including
conflict resolutions, so allow me to join the discussion.
On Wed, Feb 7, 2018 at 6:36 PM, Johannes Schindelin <Johannes.Schindeli
n@gmx.de> wrote:
Hi,
[...]
And guess what happens if you drop that `pick` line in your todo list
and
then the `merge` command simply tries to re-create the original merge
commit's changes?
Exactly. The merge will become an evil merge, and will introduce that
very
much not-wanted and therefore-dropped changes.
I think I understand. Evil merges happen when we change the branch
that is not the mainline..? Is there any reason why the following
wouldn't work?
Imagine rebase is about to pick a merge commit, and we have edited at
least one
commit in each branch to be merged.
1. apply patch mainline_orig..merge_orig
2. apply patch branch1_orig..branch1
...
N. apply patch branchN_orig..branchN
N+1. Commit merge
I do see complications, like the fact that steps 2-N can be done in any
order, with
possibly quite different results. Moving commits from one branch to
another might
not work very well. And what to do when you remove branches or create
new ones?
These problems might be prohibitive, but picking merge commits seems
like
something that should be possible to do.
[...]
So --preserve-merges --first-parent is probably what you were looking
for.
I want this as well :). I don't quite see the risk if it's not used
with --interactive.
[...]
So no, I do not think that --recreate-merges --first-parent is a good
idea
at all. Unless you try to do that non-interactively only, *and
disallow it
in interactive mode*. Because the entire point of the interactive
rebase
is to allow reordering and dropping commits, in --recreate-merges
even
moving, introducing and dropping merge commits. The --first-parent
option
flies in the face of this idea.
FWIW I'd be totally fine with disallowing it in --interactive. It would
be incredibly useful
e.g. with pull --rebase in merge-based workflows.
BTW what is the difference between --recreate-merges and --preserve-
merges when
--interactive is not present? I apologize if you have explained this
somewhere
else in the patch series.
Ciao,
Johannes
Thanks,
Øyvind