gravitystorm left a comment (openstreetmap/openstreetmap-website#6393)
Thanks, merged.
> Generally fixing `Gemfile.lock` conflicts just means deleting the conflicts
> and running `bundle install` to fix things I think?
I mean yes, that's how I've done it before (roughly `git merge`, manually fix
conflicts, run `bundle install` again just in case, `git add`, `git merge
--continue`, `git push upstream master`, which means my lockfile fixes are
hidden in the merge commit. But it also means that I push the merge commit to
master without that having gone through CI, and that makes me nervous.
Whereas if there's a way to check out the branch locally, twiddle stuff (e.g.
`git rebase` + lockfile cleanup), and then push the new commit back to the PR,
I could let CI run and then use the Github UI to do the merge when CI is green.
I *think* I've done this before (and managed to preserve the commit
authorship). But I also know it doesn't work if the PR submitter has unticked
the "let maintainers write to this branch" option, and it even if that's ticked
it can be a faff to set up the correct remote to push to since you can't
(afaik) push to the `pull/1234` branch on origin, you have to set up and push
to the `someone` remote, with whatever branch they've used to make the PR. And
I've messed that up too in the past, by pushing the wrong thing to the branch
on someone else's repo, which is a bit embarrassing.
So if there's an easier way to do option 2, with less faffing with the various
`remotes`, or a different way entirely, then that would be great.
--
Reply to this email directly or view it on GitHub:
https://github.com/openstreetmap/openstreetmap-website/pull/6393#issuecomment-3303893868
You are receiving this because you are subscribed to this thread.
Message ID:
<openstreetmap/openstreetmap-website/pull/6393/c3303893...@github.com>
_______________________________________________
rails-dev mailing list
rails-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/rails-dev
