Experimental Physics and Industrial Control System
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
- Replies:
- Re: A question for the git experts Ralph Lange
- Navigate by Date:
- Prev:
Build failed in Jenkins: EPICS-7 #112 Jenkins Epics PSI
- Next:
Re: compiler problem in pvData/testApp Marty Kraimer
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
<2018>
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: compiler problem in pvData/testApp Marty Kraimer
- Next:
Re: A question for the git experts Ralph Lange
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
<2018>
2019
2020
2021
2022
2023
2024