How to solve Git merge conflicts using kdiff?

KDiff's windows (or any other three way merge tool's windows) aren't quite so intuitive, so here's some help.

Let's say you've worked on the master branch

and somebody else worked on a "tryingOutSomething" branch

...and you decide to merge that person's changes into your code.

But Git complains that there are merge conflicts!
Turns out the other person was working on the same file you were working on, and also on the same lines.

GitExtensions refers you to KDiff3 to solve the merge conflicts. Select the option to start merging and you see a screen with four sections.

Click image to view larger

The sections from right to left are:

• Section C: The code of the branch you are going to merge into your branch.
• Section B: The code of your current branch.
• Section A: The code that is in the commit which is a common ancestor of B and C. Don't bother about section A. You'd hardly ever use it.
• Bottom section: It's what your code will look like once you've done the merges and save the file.

You can manually make changes or copy code and paste it into the bottom section like this:

The "m" I've circled in green, is KDiff's indication that it is a line of code that's not from section A, B or C. It's a line that you manually modified.

Or, note that the extreme left of the bottom section is segregated into areas where there are merge conflicts and it shows letters A, B, C or m. Any letters that are present before you started merging (indicated in the image below by the red arrows pointing leftward), are merges that happened automatically. If that's not what you wanted to merge, click on the letter in the bottom-left section and select A, B or C in the toolbar on top (indicated in the below image by the red arrow pointing upward).

You can even edit the automatically merged conflicts and choose A, B or C or edit it manually.

That's it. Now just save and exit, and Git will allow you to commit.

Solution to another issue:
You'll see a residual file of the merge, which has a ".orig" extension. Don't commit it. Just delete it.
In case your merging went wrong and Git says "You have not concluded your merge (MERGE_HEAD exists)", then just go into the hidden ".git" folder and delete the files named:
MERGE_HEAD, MERGE_MODE and MERGE_MSG.
After deleting those files, you'll be able to do the merging again. Do it carefully this time and save and exit.

All the best! :-)

Aha!

Today is a little turning point for the LOL pages. They are now "Aha's!!!". Laughing Out Loud is not really what happens when one reads the little jokes I put up here. Aha describes the emotion better. Here we go...

Festival Sale

Share with this link

Continued in the next Aha!.

 

 

It's just about using the Hungarian variable naming convention appropriately

"...and when bmeJames oBond pulled the ftrigger, the sivillian jumped in the mwater."

This is what programmers are put through when reading or writing code in companies where somebody, some-day, misunderstood what the Hungarian notation was actually meant for and created a company policy of naming variables as such.

• bBusy : boolean
• chInitial : char
• cApples : count of items
• dwLightYears : double word
• fBusy : float (or flag)

Apps Hungarian is the original Hungarian. Not Systems Hungarian. If your programmers are annoyed with this notation, they are not wrong. See what the creator of C++ and the creator of Linux have to say about Hungarian:

Bjarne Stroustrup:

No I don't recommend 'Hungarian'. I regard 'Hungarian' (embedding an abbreviated version of a type in a variable name) as a technique that can be useful in untyped languages, but is completely unsuitable for a language that supports generic programming and object-oriented programming — both of which emphasize selection of operations based on the type and arguments (known to the language or to the run-time support). In this case, 'building the type of an object into names' simply complicates and minimizes abstraction.

Linus Torvalds:

Encoding the type of a function into the name (so-called Hungarian notation) is brain damaged—the compiler knows the types anyway and can check those, and it only confuses the programmer.

How it all began

It started when Microsoft's chief architect, Dr.Charles Simonyi started it and it came to be known as "Hungarian" because it made variable names look as if they're non-English and also because Dr.Charles is originally from Hungary.
While Microsoft has a respectful article about him, praising how the introduction of the notation helped programmers write better code faster, the adulation could also just be the result of the influence of a powerful person. Given that in the days of the DOS operating system compilers weren't as programmer-friendly, and not being very careful with datatypes could lead to costly bugs when thousands of lines of code were involved, the Hungarian notation could have really helped programmers of that time.


My take on it: The Rudder Notation enhancement

Today's IDE's just need you to hover over a variable to view its type. But inspite of modern IDE's there are people who still find Hungarian useful. It can be useful when maintaining languages which use dynamic typing (JavaScript, for example).

Moreover, although there are various reasons for not using Hungarian, I just need one reason: Readability. We read left to right. Even in the days of DOS OS'es, variables would have been far more readable if the Hungarian notation were used as such:

variableName_typeInformation

Keep the type information away from the variable name with a distinct underscore and keep it on the right side of the camel-case variable. Of course, now that it looks exactly like English, you won't be able to call it the Hungarian notation anymore.

I named it the "Rudder notation" because the type information projects out of the name, pretty much like the rudder of a boat or plane, while also performing the function of guiding the developer or code-reviewer.

Are the variables more readable now?

• busy_b : boolean
• initial_ch : char
• apples_c : count of items
• lightYears_dw : double word
• busy_f : float (or flag)

Some people want to use Hungarian because they may some-day take printouts of their code. Really? Then you're very likely doing something very wrong somewhere. Others have written long posts on Hungarian; but really...

...what you need to do, is identify which variables could mistakenly introduce bugs in your code, and apply the Rudder notation to them. This identification is very much dependent on what kind of application you are building, and not on the language or the datatype.

Forming a policy for your programmers to follow by doing a monkey-see-monkey-do of somebody else's Hungarian policy would not just be unwise, it would create a culture where team leads force ideas onto the team without understanding the idea, and cause disgruntlement within teams who don't see the point or value that the policy adds to their work. Instead, educate them to recognize potential problem areas and create a culture where they share this info with each other. Creates a better sense of ownership.

-----------------------------------------------------------------------------------------

Update: Apparently I'm not the first person to suggest the underscore for Hungarian (but I'm the one who christened it the "Rudder notation"). c2.com pointed me to 'experts' who have already encouraged it: http://www.intentsoft.com/hungarian_notat/