2

I am trying to have the same config file in two different branches. I want to have the file in develop branch under revision control and on the production branch out of the revision control. So I am trying what is suggested here.

http://cogniton-mind.tumblr.com/post/63560840467/howto-gitignore-for-different-branches-update

I have the file config/config.php git rm and then added it on my .gitignore I add and commit and push to branch production. I put a copy of the file back to the original place and on my git status I see,as expected, that nothing need to be commited I checkout my develop branch and make some changes on that file. Add, commit and push to develop. I checkout production I then try to merge develop to production and I get the following.

CONFLICT (modify/delete): config/config.php deleted in HEAD and modified in develop. Version develop of config/config.php left in tree.

Is there to avoid this and have the file in develop under revision control and on production not in revision control?

Dimos Karagiannis
  • 546
  • 3
  • 12
  • I think it's a flawed workflow, unfortunately. Git uses the one project folder that the .git folder is in for all its work. If you version the file on one branch, then when you checkout that branch, it necessarily has to overwrite the file with the versioned one. When you check out the other branch, where the file shouldn't be versioned, git has no way to replace the versioned one with the non-versioned one, because it had nowhere to store it. All it knows is that in the other branch that file doesn't exist, so it deletes it when you get there. – Gary Fixler Dec 05 '13 at 22:07
  • I'll put it a different way. When you check out the branch where the file is versioned, it has to overwrite any existing version of that file with the versioned one, but git wouldn't want to, because that's destructive. If you're on that branch anyway, and you check out the one where it isn't versioned, what should it do? Should it just leave the file there? That would mean that as you hopped from other branches back to this one, whatever its state was in the branch you just left would be what was left behind in your tree when you got to the branch where it shouldn't be versioned. – Gary Fixler Dec 05 '13 at 22:11
  • So I guess the best approach would be to have the config file out of version control, right? – Dimos Karagiannis Dec 05 '13 at 22:25
  • I don't know enough to choose a best approach. Why do you want the config file in the production branch, but not under revision control there? Is it just a development aid that you don't want in the published product? – Gary Fixler Dec 06 '13 at 02:12

1 Answers1

1

Another way would be to not play with gitignore file, and use a content filter driver (a smudge script executed automatically on checkout) to generate automatically the right config file (which would not be versioned)

smudge

What you version is:

  • a template file
  • a dev config file
  • a script able to detect which branch is checked out:
    • if it is the dev branch, it generates the config file from the dev config values and the template files
    • if it is the prod branch, it generates the prod config file from a prod config value fetched outside the git repo and the template file

That way, you don't risk to push by mistake any "secret" values (they are stored "elsewhere"), and you always get the right config file.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • should this script be a git hook? What do you mean that the prod config value should be stored outside the git repo? On a different file which the script will be calling to get the values and with some sed/awk replaces the values on template file or the dev config file? – Dimos Karagiannis Dec 06 '13 at 23:30
  • @DimosKaragiannis no the smudge script is declared in a `.gitattributes` file, as in http://stackoverflow.com/a/2316728/6309. – VonC Dec 06 '13 at 23:33