Git merge driver problem.

Question

Hi,

I'm trying to get git to allow me very manual merges due the way my code is (long story, it is explained here). I almost got it the way I wanted, just something missing in a specific situation. Shouldn't be too hard: I've got the custom driver to use WinMerge with something likec:/wm/winmerge.exe $1 $2 $3 (into c:/wm/wmrg.sh), git config merge.mnl.driver = "c:/wm/wmrg.sh %B %A %A" and the echo *.xml merge=mnl > $GIT_DIR/info/attirbutes.

Now when I git merge dev, it opens WinMerge an let me do the work - brilliant. It just didnt work in the following situation:

Having my two branches (master and dev) committed with some changes waiting in dev to be merged into production.

1. Go back to master
2. Rename some files unrelated to the changes (lets say, some readme.txt to manual.txt) in dev and commit it
3. Go to dev and merge these changes from master [ the new driver kicks in and asks you if should it pass those configs to the other files in dev. You quit WinMerge without saving thus not migrating the info. After you finish looking the XML's the txt aren't filtered and get renamed in dev ]
4. now back to the master, merge dev

Here I'd expect the driver to kick in again and behave the same about the XML's. For some reason though, when you try to git merge dev it decides to Auto-Merge it all!

Is there any sort of 'per branch' configuration getting me here? maybe after git realizes I did not do any changes after a last merge it can just overwrite files in certain direction.. or even, the sort of merge used is based in some 'newer older' rule which find the situation as 'trivial' and decides which file should be kept regardless it's contents...

please advise..

thanks

Answer 1

Git might consider that:

• since master have been merged to dev (even if some files have been left untouched)
• the merge from dev to master is a trivial one because the only delta left is new files, not modified files.

And since the merge driver would kick-in only for common files, it doesn't in the case of the second merge.

Answer 2

I think I figured it out.. What I have here is actually a conceptual problem. It can't really be done in git, at least not the way I wanted.

This whole effort was to make sure that when my development cycle is done I'd have dev and master branches at the same commit level. Theoretically, differing only by a couple lines which are particular to their environment, but still, all the rest of the code is the same.

If I got that right, each commit in git is identified SHA-1 from that version, so if any file differ by one character it cannot be the same commit.

The problem I'm describing above is will be just git being smart and finding a way to make master and dev exactly the same based on my actions, thus getting it into the final state.

As I commented, I managed to apply specific changes back and forth using cherry-pick, but the only real way to have master and dev properly tracked would be using the keyword expansion filters (as described by VonC here and here, and many others out there)

Thanks for all the help,

f.