CODEWITHSUNDEEP
gitmerge
Christoph
Christoph

Reputation: 7063

Is `git merge` able to display every change (w.r. to a common ancestor) as merge conflict?

Assume we have a file common_ancestor (master)

ok
ok
ok
ok
ok

From there, we change and commit master to 

ok
change not ok (looking back)
ok
ok
ok
latest change
ok

Now we have a better idea, checkout common_ancestor and change it to

ok
ok
ok
This is a really good change
ok
ok

and commit in a new branch dev. As I need some developments from master, I want to merge dev into master but I want to decide for every change whether to keep or not. I tried

git checkout master
git merge dev --no-ff --no-commit

But I did not get what I expected. What I am looking for is something like:

ok
<<<<HEAD
change not ok (looking back)
====
>>>> HASH
ok
ok
<<<<HEAD
====
This is a really good change
>>>> HASH
ok
<<<<HEAD
latest change
====
>>>> HASH

where conflict markers are visible (see here).

Edit: What I have seen, git merge dev --no-ff --no-commit does not highlight the changes - @VonC explained why there are no conflict markers visible (because there are no conflicts!).

Upvotes: 3

Views: 465

Answers (3)

Christoph
Christoph

Reputation: 7063

As @VonC pointed out, it is not correct to treat differences in two versions as conflicts. Therefore he answered my question. To reach my goal I used

git difftool -t=kdiff3 dev master

and the merge tool therein. In kdiff3, every difference is highlighted and you can choose which version for each line you want to keep. See also here for a video-tutorial.

Upvotes: 2

AnoE
AnoE

Reputation: 8345

I want to merge dev into master but I want to decide for every change whether to keep or not.

That calls for an interactive rebase:

git branch dev_rebase dev
git checkout dev_rebase
git rebase -i master

Then go ahead from there. git help rebase, looking for "interactive mode" should give you ideas. Simply delete lines (commits) you want to skip, and use edit if you want to take parts of a commit but need to edit the files.

If something goes horribly wrong, dev will be untouched, in any case.

# if happy:

git checkout master
git merge --no-ff dev_rebase

# for good measure:

git checkout dev
git rebase master

Upvotes: 0

VonC
VonC

Reputation: 1323743

In your case, merging dev to master would simply:

  • add the change from dev "This is a really good change"
  • keep the change introduced in master "change not ok (looking back)"

That is because those changes were not made at the same spot in the file: there is no concurrent modification at the same line.
That means there is no conflict.

If you want to have a look after a merge (but before the merge commit), you can set up a custom merge driver.

[merge "verify"]
        name = merge and verify driver
        driver = ./merge-and-verify-driver %A %O %B

You can associate that driver to your files in a .gitattributes file.

*.R merge=merge and verify driver

With merge-and-verify-driver.sh a script which always return 1, in order to indicate that there was a conflict, even if the merge was actually resolved without conflicts (which is the case here: no conflict in your merge).

#!/bin/bash
git merge-file "${1}" "${2}" "${3}"
exit 1

Note: In case of conflicts, you will have more information with:

git config --global merge.conflictstyle diff3

Upvotes: 3

Related Questions