Someone asked why does a seemingly possible merge using git have conflicts with code similar to mine, but (1) mine is a little different and (2) I seek a solution to the problem not just an explanation.

edit: this is something I need to do for many files, very often. I also need to train non-technical people to be able to do it. Manually merging each conflict would be a deal-breaker for my use case.

A file on the master branch starts off as:

my name is dennis
i am a dolphin
i fix teeth

I make a branch named analysis_1 and commit these changes:

my name is dennis
analysis of line 1
i am a dolphin
analysis of line 2
i fix teeth
analysis of line 3

Realizing my earlier mistake, I checkout master and commit a fix:

my name is dennis
i am a dentist
i fix teeth

Is there a way (a strategy, algorithm, or GIT_EXTERNAL_DIFF tool) that can merge master into analysis_1 without a conflict so that I get to keep the correction and the analysis like the below?

my name is dennis
analysis of line 1
i am a dentist
analysis of line 2
i fix teeth
analysis of line 3

Thanks!

edit 2: This question pointed out wdiff and led me to try the diff option --word-diff which gives me the desired diff result. Next step is to get it to be used for a merge.

edit 3: Seems like word-based merging has some questions on SO that might bear fruit. I'll update this question if I find a solution in one of those that works for this.

1

There are 1 best solutions below

4
matt On

The problem is that you're trying to edit master by adding a commit whose job is to change the past, after analysis_1 has already branched off. The horse has left the barn and there's nothing you can do about it.

When you have made changes in analysis_1 and then you discover that one line brought over from master is wrong, the place to fix that line is analysis_1, not master.

If you are making such changes after the fact in master, or teaching others to do so, that is a misuse of git and you need to stop doing that.