Hacker News Reader

Comment by chusk3 | Hacker News Reader

For me the right way is never to allow non-ff merges and instead require all changes to be integrated into your branch (either via rebase or merge from base into your branch) before merging. GitLab supports this flow nicely and it has been wonderful for ensuring that the resulting product passes tests.

View on HN

what happens if I am waiting for my PR to merged.

I have to keep merging upstream whenever upstream changes?

Some PRs are open for days.

See my comment above: a cool feature I am implementing into fire.ci now is that it will trigger a new build every time the main branch moves forward until the safe merge happens. If you have fast builds I don't expect this to take more than 2 builds each time (or you have a huuuuge team working on the repo).

Right now I have a one button rebase operation in gitlab, and if that does work (due to conflicts) then I'm at a situation I want to be in: verifying that my changes integrate cleanly.

I am not too familar with gitlab. But I am assuming that button click triggers another build ?

So its not just 'one button rebase operation' its 'one button rebase and wait for build to finish operation' before it can be reviewed again.

Yes, that's the case. However there's also the 'merge this when the build successfully completes' that means you can push one button and walk away. They are also developing features around MRs that 'ripple' in this way, so that when you have several going the rest will continue rebasing+building until they either fail the build (due to changes that are no longer correct), can't be rebased (due to a need for conflict resolution), or finally merge successfully.

Reply on news.ycombinator.com