Experimental Physics and
Industrial Control System

"Hill, Bruce" <[email protected]> · Tue, 2 Oct 2018 22:34:10 +0000

I like to use git's cherry-pick and rebase commands to help manage SLAC specific changes to either base or modules.

We'll start from a tag on the master branch and create a SLAC specific branch.
Then we'll apply our changes either manually or via patch files, resulting in
one or more commits on our SLAC branch relative to the original master tag.

When there's a new tag on the master branch from the collaboration, I'll
create a new SLAC branch as a copy of our old SLAC branch.   We include
the collaboration tag in the branch names so we know it's derivation.
Example: R2.1.7-0.branch, R2.2-0.branch

Then use git branch --set-upstream-to to make the collab master the upstream
for the new branch.   Now a git rebase will apply all the master changes, then
reapply my SLAC specific changes using the same conflict resolution from
our prior branch.

When we do a bug fix or a feature, we create a new SLAC branch.
Example: R2.2-1.branch, where our convention is 0.branch for no src changes, 1.branch for a few src changes, and 
2.branch for many src changes.

Once it's tested, debugged, and working, we'll create a feature branch from
the HEAD of master, and cherry-pick the required commits to the feature
branch where it can be submitted as a pull request.

Unless you're one of the owners of the master branch, you really shouldn't try
to merge your work to master as your pull request may not be accepted as is.

Hope this helps!
Cheers,
- Bruce

On 10/01/2018 12:44 AM, Dirk Zimoch wrote:
>
>
> 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
>>

-- 
Bruce Hill
Member Technical Staff
SLAC National Accelerator Lab
2575 Sand Hill Road M/S 10
Menlo Park, CA  94025

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System