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.
The problem is that you're trying to edit
masterby adding a commit whose job is to change the past, afteranalysis_1has 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_1and then you discover that one line brought over frommasteris wrong, the place to fix that line isanalysis_1, notmaster.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.