On 08/03/18 11:20, Phillip Wood wrote: > On 07/03/18 07:26, Johannes Schindelin wrote: >> Hi Buga, >> >> On Tue, 6 Mar 2018, Igor Djordjevic wrote: >> >>> On 06/03/2018 19:12, Johannes Schindelin wrote: >>>> >>>>>> 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 will be slightly inconsistent. But in a defendable way, I think. >>> >>> I like where this discussion is heading, and here`s what I thought >>> about it :) >>> >>> [...] >>> >>> Here`s a twist - not letting `merge` trying to be too smart by >>> figuring out whether passed arguments correspond to rewritten >>> versions of the original merge parents (which would be too >>> restrictive, too, I`m afraid), but just be explicit about it, instead! >> >> That's the missing piece, I think. >> >>> So, it could be something like: >>> >>> merge -C deadbee 123abc:cafecafe 234bcd:bedbedbed >> >> I like where this is heading, too, but I do not think that we can do this >> on a per-MERGE_HEAD basis. The vast majority of merge commits, in >> practice, have two parents. So the `merge` command would actually only >> have one revision to merge (because HEAD is the implicit first parent). So >> that is easy. >> >> But as soon as you go octopus, you can either perform an octopus merge, or >> rebase the original merge commit. You cannot really mix and match here. >> >> Unless we reimplement the octopus merge (which works quite a bit >> differently from the "rebase merge commit" strategy, even if it is >> incremental, too), which has its own challenges: if there are merge >> conflicts before merging the last MERGE_HEAD, the octopus merge will exit >> with status 2, telling you "Should not be doing an octopus.". While we >> will want to keep merge conflict markers and continue with the "rebase the >> original merge commit" strategy. >> >> And it would slam the door shut for adding support for *other* merge >> strategies to perform a more-than-two-parents merge. >> >> Also, I do not think that it makes a whole lot of sense in practice to let >> users edit what will be used for "original parent". If the user wants to >> do complicated stuff, they can already do that, via `exec`. The `merge` >> command really should be about facilitating common workflows, guiding the >> user to what is sane. >> >> Currently my favorite idea is to introduce a new flag: -R (for "rebase the >> original merge commit"). It would look like this: >> >> merge -R -C <original-merge> <merge-head> # <oneline> >> >> This flag would of course trigger the consistency check (does the number >> of parents of the original merge commit agree with the parameter list? Was >> an original merge commit specified to begin with?), and it would not fall >> back to the recursive merge, but error out if that check failed. >> >> Side note: I wonder whether we really need to perform the additional check >> that ensures that the <merge-head> refers to the rewritten version of the >> original merge commit's parent. >> >> Second side note: if we can fast-forward, currently we prefer that, and I >> think we should keep that behavior with -R, too. > > I think that would be a good idea to avoid unpleasant surprises. Oops that was referring to the first side note. I think fast forwarding is a good idea. I'm not so sure about checking that <merge-head> refers to the rewritten version of the original merge commit's parent any more though. Having thought some more, I think we would want to allow the user to rearrange a topic branch that is the parent of a merge and that would require allowing a different parent as the old parent could be dropped or swapped with another commit in the branch. I can't think of a way to mechanically check that the new parent is 'somehow derived from' the old one. >> If the user wants to force a new merge, they simply remove that -R flag. >> >> What do you think? > > I did wonder about using 'pick <original-merge>' for rebasing merges and > keeping 'merge ...' for recreating them but I'm not sure if that is a > good idea. It has the advantage that the user cannot specify the wrong > parents for the merge to be rebased as 'git rebase' would work out if > the parents have been rebased, but maybe it's a bit magical to use pick > for merge commits. Also there isn't such a simple way for the user to go > from 'rabase this merge' to 'recreate this merge' as they'd have to > write the whole merge line themselves (though I guess something like > emacs' git-rebase.el would be able to help with that) Scrub that, it is too magical and I don't think it would work with rearranged commits - it's making the --preserve-merges mistake all over again. It's a shame to have 'merge' mean 'recreate the merge' and 'rebase the merge' but I don't think there is an easy way round that. > Best Wishes > > Phillip > > >> Ciao, >> Dscho >> >
