On 02/03/2018 19:14, Igor Djordjevic wrote: > > > > It is interesting to think what it means to faithfully rebase a '-s > > > ours' merge. In your example the rebase does not introduce any new > > > changes into branch B that it doesn't introduce to branch A. Had it > > > added a fixup to branch B1 for example or if the topology was more > > > complex so that B ended up with some other changes that the rebase did > > > not introduce into A, then M' would contain those extra changes whereas > > > '--recreate-merges' with '-s ours' (once it supports it) would not. > > > > Unless the method of merging was stored, I don't think we *can* > > correctly automate resolving of "-s ours" because all we store is the > > resulting content, and we don't know how or why the user generated it > > as such. I believe the "correct" solution in any case would be to take > > the content we DO know and then ask the user to stop for amendments. > > I agree with Jake, and for the exact same reasons. > > That said, I`d like to see what mentioned '--recreate-merges' with > '-s ours' does (or would do, once it supports it), would you have a > pointer for me where to look at? > > But if that`s something yet to come, might be it`s still open for > discussion. I mean, even this topic started inside original > `--recreate-merges` one[1], and hopefully it can still bring > improvements there (sooner or later). > > [1] https://public-inbox.org/git/cover.1516225925.git.johannes.schindelin@xxxxxx/ Ok, I went through mentioned `--recreate-merges` topic again, and I think I see one crucial merge commit handling difference. In there, as it is at the moment, merge commits are really to be _recreated_... as the option name seems to imply ;) In terms of interactive rebasing, it actually comes from "todo list" becoming much more powerful, gaining ability to create (new) merges, which is wonderful from the aspect of history rewriting (what rebase is all about). But, I would argue it is a different concept from actually _rebasing_ existing merge commits, being what we`re discussing about here. Yes, you can use merge commit (re)creation to "rebase" existing merge commit so the end result is the same, being what `--recreate-merges` now does, but that only goes for some (uninteresting?) merge commits where not knowing the deeper context of how the merge commit is originally created is not important as no content is to be lost (due to missing that deeper and utterly unknown context). But as soon as you try to do that with more complex merge commits, like holding manual amendments and conflict resolutions, it doesn`t really work as expected - which I demonstrated in my original example script[1] in this topic, original merge commit amendment lost on rebase, and even worse - that happened silently. Now, not to get misinterpreted to pick sides in "(re)create" vs "rebase" merge commit discussion, I just think these two (should) have a different purpose, and actually having both inside interactive rebase is what we should be aiming for. And that`s what I think is important to understand before any further discussion - _(re)creating_ existing merge commits is not the same as _rebasing_ them, even though the former can sometimes be used to achieve the latter. Regards, Buga [1] https://public-inbox.org/git/bbe64321-4d3a-d3fe-8bb9-58b600fabf35@xxxxxxxxx/
