Hi Johannes,
On 26/02/2018 22:29, Johannes Schindelin wrote:
>
> Once upon a time, I dreamt of an interactive rebase that would not
> flatten branch structure, but instead recreate the commit topology
> faithfully.
>
> My original attempt was --preserve-merges, but that design was so
> limited that I did not even enable it in interactive mode.
>
> Subsequently, it *was* enabled in interactive mode, with the predictable
> consequences: as the --preserve-merges design does not allow for
> specifying the parents of merge commits explicitly, all the new commits'
> parents are defined *implicitly* by the previous commit history, and
> hence it is *not possible to even reorder commits*.
>
> This design flaw cannot be fixed. Not without a complete re-design, at
> least. This patch series offers such a re-design.
>
> Think of --recreate-merges as "--preserve-merges done right".
First of all, thanks for this wonderful improvement to existing `git
rebase` functionality, I`m really excited to have this in the mainline! :)
But in the light of "--preserve-merges done right", I would like to
hear your opinion on a topic that might be considered more or less
important, and thus tackled in a few different ways... :$
Rebasing amended merges :( Even though documentation is quite clear
about merge conflicts and manual amendments not recreated
automatically, this might be considered quite an issue (a bug, even),
as even in case of non-interactive rebase, amended content will be
dropped - and even worse, it all happens silently, without alerting
the user (for whom we presume to know what he`s doing, I guess).
Now, might be this is considered the least interesting use case, in
comparison to all the power of more serious interactive rebases, but
I would argue it could be the one most used by less adventurous users
that would simply like to stay up-to-date with upstream, rebasing their
current work on top of it (think `git pull --rebase=recreate`, even).
As it currently is, and that was the case with `--preserve-merges`,
too, this will cause them to silently lose their work (amended merge
content). And while documentation is clear about it, these might be
less knowledgeable users, too, and thus potentially be the ones we
should (try to) protect even more, if possible.
Now, in the light of that other, ongoing "merge rebasing" topic[1],
it seems we really might be able to do much better, actually
_rebasing_ merges (and keeping manual conflict resolutions/amendments),
instead of _recreating_ them (and silently loosing content), and doing
so reliably (or stopping for possible user inspection, but not silently
doing the wrong thing, even if documented).
This concerns non-interactive rebase the most, but I have ideas on
making it aligned with interactive one, too, where user could
actually decide whether to rebase or (re)create the merge (rebase
becoming the default, intuitively aligned with non-interactive rebase).
But before elaborating, I would like to hear your opinion on whether
you find it worth to pursue that goal here, before `--recreate-merges`
hits the mainstream, or it might be just fine as a possible later
improvement, too (if accepted, that is).
My main concern, and why I raised the question inside this topic in
the first place, is default behavior. With `--recreate-merges` just
being introduced, we have no backwards compatibility to think about,
being a unique chance to make default behave as needed (not to say
"correct", even), and might be really ticking one more of
"--preserve-merges done right" boxes, and could be a pretty important
one, too.
But once this becomes widely available, I guess it will be hard to
improve (fix?) this merge rebasing silent content losing behavior
(even if we would acknowledge it as a bug), without introducing
additional options - and without a possibility to make possibly
"right" behavior a default one, thus further complicating user
experience.
So, I wanted to hear your stance on this :(
Knowing how much this means to you, it is really not my wish to drag
this topic further, and if you find it that we`re good here as it is,
I wouldn`t have any objections - I guess later new `--rebase-merges`
option is a possibility, too, might be a wrapper around
`--recreate-merges`, but with actual merge rebasing being a default
(where merge recreation would still be possible, too)...
Otherwise, if you have any interest in it now, I can further elaborate
what I`m thinking about, where it might help improve both user
experience and rebase possibilities, for what might not be too much
extra work... hopefully :P
Whatever ends up being your response, I`m really grateful for your
work on this matter so far, and thank you for everything you did.
p.s. lol, now that I said it, and after writing all this, I might
actually even like the idea of (later) having `--rebase-merges`
alongside `--recreate-merges`, too, each one clearly communicating
its