1

I know the 3-way merge of git. but sometimes my HEAD and MERGE_HEAD has too many commits behind them, and some modification may perform like git revert. I want to handle these conflicts manually. Is there any way to achieve it?

suikajy
  • 23
  • 3
  • If there are conflicts, Git already stops and requires that you resolve things manually. A "two way merge" is not all that well defined (it's more of a term from sorting algorithms); see https://stackoverflow.com/q/4129049/1256452 (and for sorting https://stackoverflow.com/q/5055909/1256452). – torek Mar 18 '20 at 09:25
  • If what you mean is: can you force `git merge` to stop before committing, even though *Git* did not find any merge conflicts, the answer is yes: just use the `-n` (or `--no-commit` if you like the longer spelling) flag. You can then change the merge all you like before committing. However, some people consider this undesirable. This is usually called an Evil Merge. See https://stackoverflow.com/q/1461909/1256452. – torek Mar 18 '20 at 09:27
  • Forgive my english, I'm not an english speaker. What I mean is: in branch A, I write a line X. And in branch B, I write a line X in commit1, but for some reason I delete the line X in the branch B in a later commit2. Now, I merge the B into A , the line X appear. What I want is let the line X disappear, but git handle it without conflict, I know the line X in my code when the code is run. – suikajy Mar 25 '21 at 09:17
  • Ah: no, Git compares the *merge base* commit (the best commit that's on *both* branches) to the *tip* commits of the two branches, to see what changed. By adding, then removing, that one specific line in branch B, you've made *no* change to that line in branch B. So when Git compares the merge base commit vs the tip of B, there is no change there. When Git compares the merge base commit vs the tip of branch A, the line is added. The combination of "add this line" and "do nothing" is always "add this line". – torek Mar 25 '21 at 19:49

0 Answers0