Hi Phillip, > On Fri, Mar 2, 2018 at 4:36 AM, Phillip Wood wrote: > > > > > It is interesting to think what it means to faithfully rebase a '-s > > > ours' merge. > > > > I should have explained that I mean is a faithful rebase one that > > adheres to the semantics of '-s ours' (i.e. ignores any changes in the > > side branch) or one that merges new changes from the side branch into > > the content of the original merge? In your example you add B4 to B. If > > M' preserves the semantics of '-s ours' then it will not contain the > > changes in B4. I think your result does (correct me if I'm wrong) so it > > is preserving the content of the original merge rather than the > > semantics of it. Yeah, I understood what you mean, and I see you noticed that B4 commit, for which I did anticipate possibly bringing up a discussion like this ;) I agree with Jake here, my thoughts exactly (what I wrote in that other subthread[1], too): On 02/03/2018 17:02, Jacob Keller wrote: > > We only have the content, and we don't know the semantics (nor, I > think, should we attempt to understand or figure out the semantics). Hmm, I wanted to elaborate a bit here, but that sentence seems to summarize the pure essence of it, and whatever I write looks like just repeating the same stuff again... That`s just it. And stopping to give the user a chance to review/amend the result, where he might decide he actually did want something else - so all good. Otherwise, I would be interested to learn how context/semantics guessing could provide a better default action (without introducing more complexity for might not be much benefit, if any). But in the end, I guess we can just discuss the "most sane default" to present to the user (introduce or obsolete that new commit B4, in the discussed example[2]), as we should definitely stop for amending anyway, not proceeding automatically whenever U1' != U2'. Oh, and what about situations where we introduce new or drop existing branches (which should be possible with new `--recreate-merges`)...? "Preserving old branch semantics" may have even less sense here - the (possibly heavily reorganized) content is the only thing we have, where context will (and should) be provided by the user. And I guess being consistent is pretty important, too - if you add new content during merge rebase, it should always show up in the merge, period. It seems pretty confusing to find out one of the branches "declared special" (even more if it`s based on uncertain guess-work), so when you add something to it it`s just "swallowed", as the whole branch is always obsoleted, for now and ever. I might even see a value in such behavior, but only as a conscious user action, not something done automatically... I guess? :) Regards, Buga [1] https://public-inbox.org/git/f26cdbe2-1bc3-02ff-7b99-12a6ebab5a70@xxxxxxxxx/ [2] https://public-inbox.org/git/f1a960dc-cc5c-e7b0-10b6-39e5516655b3@xxxxxxxxx/
