Stream: committers
Topic: Ugh..null.cache merge conflicts...
Jean Duteau (Mar 01 2021 at 22:23):
Does everyone else hate it when null.cache gets merge conflicts? I still don't know the proper way to merge these in. Is there some reason why we've included a cache file in the repository?
Grahame Grieve (Mar 01 2021 at 22:28):
they make a massive difference to performance - hours of difference
Grahame Grieve (Mar 01 2021 at 22:29):
but you can always revert your files and ignore your local changes
Rik Smithies (Mar 01 2021 at 23:51):
I never check this in (or snomed.cache or tools/.../snomed.xml) because they seem to change when I made no changes.
Grahame Grieve (Mar 02 2021 at 00:03):
that's cause someone else didn't commit it
Lloyd McKenzie (Mar 02 2021 at 01:03):
null.cache changes every time you build - it has a bunch of expansion timestamps in it that change when you build
Jean Duteau (Mar 02 2021 at 01:10):
Hmm, just did some searching and we could this:
git update-index --skip-worktree FILENAME
and then it will never commit that file to the repository but will get any changes to it that are checked in.
Mark Iantorno (Mar 02 2021 at 01:31):
Can we jsut add it to the gitignore?
Mark Iantorno (Mar 02 2021 at 01:32):
if someone wants to actually update it, they still can, but this way it won't affect other peoples builds
Lloyd McKenzie (Mar 02 2021 at 03:40):
The desire is that it gets kept up-to-date. If it's ignored, no one will commit it and all builds will slow down as a consequence.
Jean Duteau (Mar 02 2021 at 05:53):
no, if you add it to .gitignore then it doesn't get committed and it also doesn't get checked out. The main problem with the file is that it doesn't merge nicely. In my latest merge failure, it was just a bunch of dates that were different. I really don't understand why git can't merge it. Maybe it's not treating it as a text file?
Lloyd McKenzie (Mar 02 2021 at 06:26):
The issue is you download with one set of dates. Someone else merges with a different set of dates, then you try to merge with your dates and Git doesn't know which dates you want. Your only chance to succeed is to create your pull request and get your test build to completion between your initial pull and your merge. If anyone else gets in there, you'll get a conflict. I think the solution is for the build to hardcode the dates and expansion ids to something so they never change (unless Grahame uses them somehow?) Similar issue in the SNOMED CT expansions.
There's a tougher issue in that some of the changes appear to be date-related content that manifests in the narrative. Not sure how easy that will be to lock and not change.
Grahame Grieve (Mar 02 2021 at 06:35):
it shouldn't have dates in it. I'll investigate at some time
Lloyd McKenzie (Mar 02 2021 at 07:06):
The SNOMED cache changes dates too.
Yunwei Wang (Mar 04 2021 at 20:16):
Just curious, doesn't the build process in github rebuild every PR? If so, what is the point to check-in build generated/updated files? I have never checked in any cache files (null.cache, snomed.cache, etc). Maybe I should do that?
Mark Iantorno (Mar 04 2021 at 20:28):
the CI pipeline only checks the build, and then generates the webpage for the branch/master
Mark Iantorno (Mar 04 2021 at 20:28):
the pipeline doesn't commit anything back to the repo iteself
Mark Iantorno (Mar 04 2021 at 20:29):
it onlygenerates the website code and pushes it to build.fhir.org or build.fhir.org/branches/<your fancy branch name here>
Last updated: Apr 12 2022 at 19:14 UTC
