Stream: committers/git-help
Topic: is there a new improved way to look at spreadsheet conflicts
Eric Haas (Oct 13 2018 at 00:43):
I thought the reason for having to close the spreadsheet prior to each commit was so the conflicts would be easier to resolve. as in a conflict in a single line or lines instead the entire file as I see it now before me in my text editor...
Grahame Grieve (Oct 13 2018 at 03:21):
it should indeed work that way. not sure what work flow lead you to that point
Eric Haas (Oct 13 2018 at 04:06):
Right now I looking for any workflow that works for me...I'm running these huge commits in a the fhir-clone and when and if it is successful I'll stash it to a new branch and then commit. But after a git pull, I got a conflict that was the whole spreadsheet.
Grahame Grieve (Oct 13 2018 at 19:15):
so if you do a local stash without letting the build update the spreadsheet first, you can get this problem, because the build hasn't canonicalised the spreadsheet first
Lloyd McKenzie (Oct 13 2018 at 22:28):
@Grahame Grieve I thought the CI-build was going to check that the spreadsheets had been processed before allowing them to be merged - so if your stash messes things up, that should still get caught before a merge to master?
Grahame Grieve (Oct 13 2018 at 22:44):
It does. But your stash has nothing to do with the ci-build. You can stash an uncorrected spreadsheet, and end up in this place
Last updated: Apr 12 2022 at 19:14 UTC
