Re: A question for the git experts

[Ralph Lange <ralph.lange@gmx.de>]

Isn't that what we do large style in base by calling all local configuration files *.local and excluding them from SCM via .gitignore?

You could also try to play with different .gitignore files in different branches to have the local files under version control in "your" branches.

Cheers,
~Ralph

On Fri, 28 Sep 2018 at 12:16, Dirk Zimoch <dirk.zimoch@psi.ch> wrote:

Hi folks,

I have a question about the preferred work flow with git when having
"private" files.

In order to compile for all our architectures, I have many CONFIG files
that are PSI specific. So I keep them on my "PSI-7.0" branch, which is
based in the "7.0" branch. Whenever there are changes in the "7.0"
branch, I merge them in. No problem.

When I develop something, I need my CONFIG files of course to actually
compile anything. Thus I need to work on the "PSI-7.0" branch or better
on a feature branch based in "PSI-7.0".

Now the problem starts: When merging the feature back, I do not want to
pollute the "7.0" branch with my CONFIG* files.

So how to do this? How to tell git "during a merge, ignore those files"?

My workaround so far: I develop on the "PSI-7.0" branch but never
commit. Instead I stash the changes, then check out the feature branch
which is based in "7.0" and apply the stash. Then I can commit and push.

The disadvantage is that I have to delay the commit to a time when I
have already forgotten what the idea was. Also I may have other local
changes which should not go into the feature branch, but stash copies
them all.

Is there a better way to do this?

Dirk