tags:

views:

352

answers:

4

Hi,

I've read a few git questions here, but could not find an answer to this one:

I have a public and a private branches where I want to allow certain files to diverge.

Those are configuration files with passwords and my local customizations.

I do want to be able to merge the branches both ways: from private to public and back, but I do not want to ever have those specific files merged automatically.

Is there a way to set up git this way? I'd love to find an automated solution :) - so that merging could be done as usual.


EDIT: here's the solution that worked for me (Thanks to VonC for the advice on gitattribute)

the only unexpected thing for me was that "merge protection" starts working only after files have diverged in the two branches, not immediately after the following configuration was applied

.gitattributes (track with git if you want to share this) or .git/info/attributes:

file1      merge=keepmine
path/file2     merge=keepmine

keepmine is the named custom merge manager that is just a do-nothing command called instead of the internal merge driver on selected files, which is set up below

When merging from private to public branch I usually do git merge --squash private. That way private edits won't get into the git history on the public branch.

.git/config:

#public repository
[remote "origin"]
    fetch = +refs/heads/*:refs/remotes/origin/*
    url = <public repo git url> 

#private repository
#has to set up with git init and populated with the initial commit to branch mybranch
[remote "private"]
    push = +:
    url = /path/to/local/private/repo 
[merge "keepmine"]
    name = dont_merge_selected_files
    driver = echo %O %A %B 
[branch "master"]
    remote = origin
    merge = refs/heads/master 

#private branch settings
[branch "mybranch"]
    remote = private
    merge = refs/heads/mybranch

if there's a way to improve this please comment

+2  A: 

Keep passwords under version control is the worst idea ever. You need CVS, not git, to work with separate files. Git as many other modern DVCS working with the entire tree, not with separate files.

bialix
sure, but password is the minor point here.
Evgeny
+1  A: 

One way to do this is with git rebase. By keeping your private changes as a few commits off the end of your master, you can commit public stuff to the master branch (or whatever you choose your working branch to be), and then rebase your private branch against master whenever you want to update.

Another way to handle this is to keep template configuration files in Git, such as frobozz.config.template. In your working directory, copy frobozz.config.template to the (unversioned) frobozz.config and modify. Just be sure to back up your working directory too, if you need your local changes to be backed up.

Greg Hewgill
+4  A: 

To be on the safe side, you can add a git attribute (see here for an example) for those private files.

That way, you can define a script (a "merge manager") which will ensure the file including private informations will remain empty (or with a public content) if merged on the public branch, while keeping its local content if merged to the private branch.
It means you can merge/rebase without thinking about that file.

VonC
this works, thanks!
Evgeny
+1  A: 

This only appears to work if there are merge conflicts detected. Merging back and forth between branches the file does get overwritten. Unless I set something up wrong. Of course this in on windows msysgit git version 1.6.5.1.1367.

yoyodyn
@yoyodyn yes, you are right this only works on files with merge conflicts.
Evgeny
you might as well consider merging only one way from public to private, but in this case you'll have to stay disciplined - only develop public features on the public branch/repository
Evgeny
What I have actually got is three clones of the same repo at different geographical locations. Our office works in the master branch, another site works in the test branch so the customer can do QA, and the third is the production branch where the currently running code is located. We have at least one file Macros.h that we include in a lot of the c++ projects that hold different values for the macros depending on if its master, test, or production. I have been trying to find a way to prevent the macros.h file from getting merged between branches.
yoyodyn