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.

Foredate

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.

Ridden

Hm.. that is pretty interesting, but I'm not so familiar with GIT drivers. I have added to my .gitconfig the following: [merge "manual"] name = manual merge driver = Unset and then added to the .gitattribute: * merge=manual (picked these up from git help merge) didn't work though. could you be more specific with the git driver? thanks! f. – Foredate

@flpgdt: that would be a custom merge driver (defined in the .gitconfig file indeed). I was referring just to the merge attribute (see kernel.org/pub/software/scm/git/docs/gitattributes.html). A simple: echo *.xxx merge=unset > dirWithConfgFiles\.gitattributes should be enough (with 'xxx' being the extension for the code files including config values) – Ridden

hey mate. It didn't actually work. I had my .gitattributes (tried both, in my root folder and in my folder containing the exact files) like *.xml merge=Unset. I'll keep on trying, but thanks anyway. I was also taking a look in how to create the clean driver, and although I think i managed to create it, I'm not sure how to tell GIT to use it :( thanks! f. – Foredate

@flpgdt: you have a concrete example of merge driver here: stackoverflow.com/questions/928646/…. The 2 key things: a/ it is a sh script (not a DOS script); b/ the script is referenced in the $PATH. – Ridden

Hey, Thanks again! I had seen that post before but managed to use it to create my driver this time. It actually pretty simple how to use WinMerge the way I want with it! However, the manual merge still seems only to kick in when conflicts are found... I wish I could use it for all the merges... – Foredate

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.

Ovolo

hnf.. I wish it was like that. Unfortunately it is a bit worse, the configurations are embedded in the code itself. Well technically the "code" is a complex config file where some of its contents deal with the environment where its executed (the sort of connections, ids and paths). It cant be so difficult... I just wish I could do something like git diff master dev and when I hit save for each file, the changes are stored in the current branch... – Foredate