Hi Mark, On Thursday, July 27, 2017 at 12:48:25 AM UTC+2, Mark Waite wrote: > > Yes, your simplification expresses what I was trying to achieve. >
Good, then we understood each other, thanks for confirming :) > I specifically merged from master to one so that one could be tested with > the merge from master. The subsequent merge from one to master was to have > master include a commit which shows one merged into it. Same pattern for > master to two, then two to master. > Understandable. I just moved the "subsequent" (the other way around) merges to the end (being fast-forward ones), once the three "incremental" (and real) merges are done. Might be easier to comprehend like that, otherwise I agree with you`re logic. > I assumed (possibly incorrectly) that there would be conflicts to resolve > in either merging one or two or both to master. I assumed that resolving > the conflicts would be easier if there were incremental steps which > represented the merges. > > If there are no conflicts, then isn't the ultimate simplification to merge > both 1 and two to master with a single command? > > $ git checkout master > $ git merge one two > > That will perform an octopus merge and create a merge which has 3 parents, > rather than the more common 2 parents. > Yes, correct. Even if it`s probably unlikely (or is it?), "no conflict octopus merge" scenario is worth mentioning as well, being the easiest/simplest one. Regards, Buga -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
