Menu
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.
224
With --no-commit perform the merge and stop just before creating a merge commit, to give the user a chance to inspect and further tweak the merge result before committing. Note that fast-forward updates do not create a merge commit and therefore there is no way to stop those merges with --no-commit.
In Conclusion. We can use git checkout for far more than simply changing branches. If we supply it with a branch name and a file, we can replace a corrupted or broken file. Instead, if we want to pass some of the changed content we can use the --patch flag to manually merge an individual file.
To do a merge (locally), git checkout the branch you want to merge INTO. Then type git merge <branch> where <branch> is the branch you want to merge FROM.
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.
160
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.
40
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
