On 02/03/18 23:33, Igor Djordjevic wrote: > 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). I don't think its possible to guess the semantics of the original merge as users can use custom merge strategies and amend the result. It would be possible to detect and unamended '-s ours' merge but special casing that may end up causing users more confusion rather than helping them. > 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'. I can see the reason for that but I'm concerned that it might get annoying with an interactive rebase as it would stop whenever one of the commits on a topic branch that is a parent of a merge gets amended. (squashing and reordering existing commits on a topic branch would be OK though) > 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. In this scheme there is now way to change the parents of a merge so preserving the old branch sementics is well defined. If the user wants to change the parents of the merge then this scheme wont help them. > 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. Yes, that should make it easy for the user to know what to expect from rebase. > 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/ >
