Yaroslav Halchenko tries to advocate once more for that strategy, but Junio C. It mentions the alias: mtheirs = !sh -c 'git merge -s ours -no-commit $1 & git read-tree -m -u $1'. In short, the previous discussion can be summarized to "we don't want ' -s theirs' as it encourages the wrong workflow". That debate for the pertinence or not of a theirs merge strategy was brought back recently in this Sept. This means that recursive strategy will still merge anything it can, and will only fall back to " theirs" logic in case of conflicts. Xtheirs is a strategy option applied to recursive strategy. Impression that the readers also need to be warned that it is veryĭifferent from -s theirs, which in reality does not even exist. Which is correct, but the description of -Xtheirs that follows itĬarelessly says "this is the opposite of ours", giving a false That tells the readers that it is very different from -s ours, The description of -Xours merge option has a parenthetical note (Merged by Junio C Hamano - gitster - in commit 4da3e23, ) merge-strategies: avoid implying that " -s theirs" exists
See commit c25d98b () by Junio C Hamano ( gitster). Written to suggest that " -s theirs" exists, which is not the case. The documentation for ' -X' for merges was misleadingly
#Git merge branch to master how to
While I mention in " git command for making one branch like another" how to simulate git merge -s theirs, note that Git 2.15 (Q4 2017) is now clearer: In this or other similar/advanced cases the low-level command git commit-tree can be used. If the commit of branchB is an ancestor of branchA, git merge does not work (it just exits with a message like " Already up to date."). This is what Paul Pladijs's answer does (without requiring a temporary branch). # Change content of merge commit to current index (i.e. # This ensures branchA will move when doing 'commit -amend'. # Move HEAD to branchA without changing contents of working tree and index. # -detach ensures branchB will not move when doing the reset in the next step.
# Change working tree and index to desired content. The content of this commit does not matter, the first parent comes from branchA and the second from branchB. only that from branchB) but the order of parents is correct, i.e. It has the same content as in the option before (i.e. This is the real "theirs version for git merge -s ours". Use content from B only and keep correct parent order Note that the merge commits first parent now is that from branchB and only the second is from branchA. # Set branchA to current commit and check it out. # Do the merge an keep current (our) content from branchB we just checked out. # else it will be advanced to the merge commit in the next step. # If you want to keep branchB at the current commit, you can add -detached, This creates a merge commit for both branches but discards all changes from branchA and only keeps the contents from branchB. This is not the "theirs version for git merge -s ours" but the "theirs version for git merge -X ours" (which is short for git merge -s recursive -X ours): git checkout branchA I try to give an overview and see the following three options: It is not entirely clear what your desired outcome is, so there is some confusion about the "correct" way of doing it in the answers and their comments.
0 kommentar(er)
