|
|
|
|
|
|
by mehrdadn
2594 days ago
|
|
|
> If it's good enough to run remote tests on, it's compiling and presumably working locally. To you "he pushed his commit and tests got triggered" implies "his commit is compiling and working fine locally" and therefore implies "ready to build on top of"? You never push incomplete work while intending to continue it the next day... maybe on another machine? You never run across build failures on other machines when everything builds fine locally? You never see bugs that don't repro locally? You never trigger or re-trigger tests to narrow down bugs you can't repro locally but know to exist? Every single commit you push can be assumed to build on everyone's machines, pass all tests, and provide a proper foundation to branch from? And these are all true for everyone you work with too? > You didn't explain anything! I explained a heck of a lot?? I explained that force-push is useful on commits that you're not intending others to build on top of; I gave at least 5 common examples of why people push code despite it not being in a proper state to build on top of; I explained that rebasing on a gently-pushed commit is exactly the same as rebasing on a force-pushed commit; I explained how your teammates can force-push if you didn't somehow insist on saving the 5 seconds it would take you to communicate with them that you're going to build on top of their branch and maybe find out if you should be doing that in the first place (both of which you often should be doing anyway); I explained that if you took the few seconds to communicate then mistaken pushes would be rare and you could just resolve them by reverting or resolving commits like you normally would; I explained how git has specifically provided multiple features and documentation to support and explain both workflows because both of them have their own benefits and neither is superior... and yet somehow I "never explained anything" and "went straight from arguing about terminology to accusing me of dogmatism"? Seriously? You don't feel even you're slightly misrepresenting things? I almost didn't even write this comment, but now I'm definitely done with this. |
|
|
Nope. I wouldn't want to switch machines halfway through a change that left the code broken. I'd either get to a point where it was working, or just not push. (Being able to break changes down into small pieces while keeping the codebase working at all times helps, but that's a good skill to develop anyway - it makes automated bisection in the future much more effective).
> You never run across build failures on other machines when everything builds fine locally? You never see bugs that don't repro locally? You never trigger or re-trigger tests to narrow down bugs you can't repro locally but know to exist? Every single commit you push can be assumed to build on everyone's machines, pass all tests, and provide a proper foundation to branch from? And these are all true for everyone you work with too?
Occasionally you'll hit a transient or machine-dependent bug, sure. (That can happen in master too, though it's less of a risk). But again, it's not a big deal when that happens. If you discover a bug in someone's branch then that is a situation that's worth interrupting them to talk about. You coordinate, they fix it and you pull their branch again - or you fix it and they pull your branch. Most likely you need to communicate and collaborate on the fix in any case, since you know what the bug is while they know what their changes were.
There's a cost and a risk associated with working with code that hasn't yet passed all of the master gates. But there's also a cost and a risk to working on a particular code area without seeing your coworker's changes in that area, even if they haven't gone into master yet. Most of the time the tradeoff works in favour of pulling their branch, IME.