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 default mode of operation - rebase merges vs. recreate merges... as one might rightfully expect ;) Eh :P Regards, Buga [1] https://public-inbox.org/git/87y3jtqdyg.fsf@xxxxxxxxx/
