Manual merge on GIT

Question

I develop in a proprietary script language with very resumed code in which most configurations are contained inside the code itself.

The obvious problem would be the differences in the code itself between test and production environments and that's exactly what I'm trying to manage with GIT.

As my test env is quite volatile I figured I could create a branch in GIT for it while there are changes being made (and keep the code with test configurations in there) and after the code has been accepted I'd merge it into production.

Well, when I ask git to merge my branches it does a wonderful job with the code.. but the configs are migrated as well and than I have to open file-by-file, changing it back to what it was.

Is there anyway I could disable the automatic merge from GIT and threat everything as code conflicts to be manually merged with WinMerge or something later? The code is short, really. And since I'm gonna have to edit it anyway to apply the configurations...

ps.: please notice, I'm not asking how to configure WinMerge on git. I have these tools working. My question is how to always perform manual merges between branches.

thanks!

f.

Answer 1

disable the automatic merge

That could be achieve by writing a small merge driver, set in a .gitattributes file.
A policy like unset might be what you are looking for.

Unset

Take the version from the current branch as the tentative merge result, and declare that the merge has conflicts. This is suitable for binary files that does not have a well-defined merge semantics.

But another interesting gitattribute driver would be a clean filer:

That would automatically execute a 'clean' script of your choice just before committing the "cleaned" content to the repo.
Such a 'clean' script could help you automate the changes you have to make to your code to keep or modify the config values embedded in it.

Answer 2

You say "most configurations are contained within the code itself" but hopefully all configuration is isolated in files specific to configuration. If that is the case, you could keep both test and release cases of the configuration code in the same branch. You could then use a command line switch to use the test config instead of the normal one.

If your program can read a configuration selection from the command line (or environment variable, registry key, text file or whatever), then you won't have to merge at all. The program can ignore the test configuration files when the command line switch is not present, and ignore the release configuration when the command line switch is present.

This saves you from the possible mistakes during the merge as well as the time it takes to do the merge.