On 28.09.2018 20:07, Ralph Lange wrote:
Isn't that what we do large style in base by calling all local
configuration files *.local and excluding them from SCM via .gitignore?
But I want to track them in my git repo of course.
You could also try to play with different .gitignore files in different
branches to have the local files under version control in "your" branches.
But then I have the same problem with the different versions of
.gitignore. Merging would overwrite with my local .gitignore. Right?
Also I found that git ignores the .gitignore patterns for files that are
already in git. Thus I think it will not help.
Dirk
Cheers,
~Ralph
On Fri, 28 Sep 2018 at 12:16, Dirk Zimoch <[email protected]
<mailto:[email protected]>> 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
- Replies:
- Re: A question for the git experts Hill, Bruce
- References:
- A question for the git experts Dirk Zimoch
- Re: A question for the git experts Ralph Lange
- Navigate by Date:
- Prev:
Build failed in Jenkins: EPICS-7 #114 Jenkins Epics PSI
- Next:
Re: A question for the git experts Dirk Zimoch
- 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: A question for the git experts Ralph Lange
- Next:
Re: A question for the git experts Hill, Bruce
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
<2018>
2019
2020
2021
2022
2023
2024
|