What are A, B, and C in KDIFF merge

Question

Why am I given three choices when merging between my code and someone else's? Shouldn't there just be my code, the other person's code, and the output below? The documentation for KDIFF doesn't help me understand.

Tenney

Answer 1

Sounds like you're doing a three-way merge, so A should be the base revision that B and C are based on, B is theirs and C is yours (I believe; B and C might be the opposite, though).

Embolus

What is the base revision about? Does that help in some cases? – Tenney

@user464095: For KDiff I believe that it's the revision that both B and C are modifying. So you can compare B to its base (A), C to its base (also A) and the changes in B and C to each other. That way you can resolve conflicts by using the changes in B or C or by reverting to the original (A). – Embolus

I still don't understand, can you elaborate some more? – Tenney

Well, consider a case where you and another developer make conflicting changes to the same code. It's typically helpful to have the context of the original file, so you know if either one of you is breaking previous functionality. You could diff your file with the other developer's, resolve conflicts, and then diff it with the original, but a three-way diff performs the same function in fewer steps. – Embolus

As @gbarry explains in this related SO thread, the BASE revision is the one you last downloaded from the repository, at least with Subversion. He also talks about editing conflicts and how this effects the BASE and HEAD revisions. – Helman

This is the first time I've actually understood the reason for a 3-way diff. Thanks! – Gaskill

@Embolus +1 for saying "fewer steps" instead of "less steps" ;) – Scopoline

Answer 2

A refers to the version your merge target is based on. If you Merge from branch to trunk, 'A' will be the previous trunk version.

B is what you currently have in your local trunk folder, including local changes.

C is the Version you wanna merge on top of B.

Dowson

B means before stash apply OR after stash apply ? – Astigmatism

Stashed changes are not applied during the merge. They stay stashed until they are explicitly unstashed. – Illtreat

Answer 3

A (BASE) ‐‐> Original file that currently sits in remote repo.
B (LOCAL) ‐‐> Your file. This shows only your changes as compared to A.
C (REMOTE) ‐‐> Their file. This shows only their changes as compared to A.

If the changes are on different code lines, you take from both B and C. If the changes are on same code lines (conflict), you take either from B or C.

Whereunto

Answer 4

A is your parent revision having B and C as child.
Which means B contains the changes done on A by user1/repo1 and C also contains the changes on A but by other user (user2/repo2)

kdiff gives you the option either to select modification from b or c (or take both) or from parent also 'A'

Wore

Answer 5

If I did git rebase, my observation was that: C - is what in my_branch locally ( i.e. was seen in my editor before the rebase started and conflicts occurred). B - branch I was rebasing my_branch on top of (say master branch for example) A - base revision of B & C (which didn't matter to me too much in this case)

Litterbug

Yes it seem that B&C are inversed between the merge and the rebase – Dhyana