Stream: committers/git-help
Topic: Resolve conflict on pull-request - need help
Melva Peters (Oct 17 2018 at 22:56):
I just did a pull-request and get a conflict on vscache/snomed.cache. I'm using GitKraken and am not sure how to resolve this conflict. I didn't see it before I did the pull-request. Can anyone tell me how to resolve?
Bryn Rhodes (Oct 17 2018 at 23:22):
@Melva Peters , for conflicts in caches, they'll be regenerated by the build anyway, so you can just resolve them by accepting the merge version. In TortoiseGit, they call that "theirs", not sure what the wording for it is in GitKraken.
Melva Peters (Oct 17 2018 at 23:26):
I don't see the conflicts in GitKraken - only on Github - maybe I have to merge the build changes into my local branch. @Ewout Kramer, is that how I should manage this in GitKraken?
Eric Haas (Oct 17 2018 at 23:27):
you have do the git version of revert.
Ewout Kramer (Oct 18 2018 at 11:20):
Yes, Melva - that's correct. The develop had changes which caused a conflict locally. Remember we solved these on our shared Skype. The same happens now again when you create the PR - the develop has different changes again in these files. This is painful, since whenever you want to integrate changes on the develop branch into your feature branch - you'll get this. And then when you do a PR - you'll get them again. But I don't see a way to avoid this - the root cause is the fact that we check in generated files.
Ewout Kramer (Oct 18 2018 at 11:22):
Now, the solution is not apparent - GitKraken has the "use theirs" option - but this only becomes available after the tool has shown you all the differences first (that's the built-in 3-way merge tool we looked at together). Unfortunately, for these huge files that's way too time consuming and so no option. I'll take a look whether I can get around this in GitKraken.
Josh Mandel (Oct 18 2018 at 12:26):
Thinking about the root cause here, do we expect anyone should ever be making changes to the cache files other than (basically) Grahame? My strong preference would be not to check cached files into the repository at all -- but even if we are not ready to take that step, could we perhaps add these cache files to the .gitignore (while keeping them checked in into git), so at least git wouldn't prompt users to include changes to them in unrelated commits, and we would not see them coming along for the ride in random pull requests?
Lloyd McKenzie (Oct 18 2018 at 13:38):
If something is committed, would having it in gitignore make any difference to git's behavior?
Josh Mandel (Oct 18 2018 at 13:45):
Yes: it wouldn't propose adding changes to that file in new commits. (You can still force add a change, but it is hard to do by accident).
Grahame Grieve (Oct 18 2018 at 22:30):
My strong preference would be not to check cached files into the repository at all
Grahame Grieve (Oct 18 2018 at 22:30):
that would make approx 3 hours difference to build time
Lloyd McKenzie (Oct 18 2018 at 22:49):
Do cache commits need to be done by everyone?
Grahame Grieve (Oct 19 2018 at 02:20):
no. I thought i had got them stable, but apparently not, and I'm not yet ready to spend more time on that. I'm just reverting them for now
Last updated: Apr 12 2022 at 19:14 UTC
