4 ms·
> No we can't, because what do people do in this scenario? They make a new commit that fixes the tests, but leaves a long chain of previous commits broken. Sam
by patrec 6y ago
> No we can't, because what do people do in this scenario? They make a new commit that fixes the tests, but leaves a long chain of previous commits broken.
Same thing will happen with merges -- one can try to argue (as you have done) that with merges it will be less bad, because you may on average end up with fewer broken commits -- and I don't think that is implausible. But that is basically just saying your existing way to bisect is not fully reliable and you fear using rebase would make it quantitatively noticeably worse. What I am saying is it can and should be fully reliable, and this is not theoretical either.
I enjoy discussing different workflows with people with a different outlook and experience and who have put a decent amount of thought into it, as you clearly have. But I still have to note that there is a certain irony here: you have something which by your own admission is not completely reliable; i.e. not all your merges in master have passed CI and you will have some (hopefully small) proportion of commits that you'll need to manually bisect skip because they are bad for one reason or other and you won't know in advance. You are adamant that rebase-based workflows are bad (partly) because you fear that they will greatly exacerbate such problems and you don't seem to think it's practically possible to completely avoid them to start with.
But I am arguing from plenty of real-life experience with a workflow, which is incidentally rebase-based (but the same guarantees would hold just as well if I moved it to a purely merge based approach) where I a) know that every "merge" to master has been fully tested before it lands b) can reliably bisect over ~years of commits with a simple git alias, without having to ever manually bisect skip bad commits[+]. And by construction, not because I hope that devs will generally have tested their commits sufficiently manually or are diligent about fixing merge conflicts in a way that does not result in intermittent broken commits. So whilst several of your other reasons are perfectly valid (long-lived branches), you can maybe see why this one is a bit amusing to me.
> (Also in a big enough codebase with enough collaborators it becomes impractical to require CI to pass against the absolute tip of your shared development branch before merging, because in the time it takes to run CI there will always have been more changes landing in that shared branch).
It's not impractical at all, in fact if your company pays me for it I'm more than happy to set it up for you :)
Alternatively shoot me an email and I'll be happy to explain the gist of it (including how to completely avoid the problem you mention above).
[+] Of course assuming nothing was broken at the meta level, e.g. no one accidentally temporarily misconfigured CI, so some stuff that should have been didn't get tested.
- lmm 6y ago> But that is basically just saying your existing way to bisect is not fully reliable and you fear using rebase would make it quantitatively noticeably worse. What I am saying is it can and should be fully reliable, and this is not theoretical either. What you're proposing doesn't actually improve matters; you don't gain anything (other than saving a bit of machine time) by only testing known-compiling commits. At the end of the day the bisect lands you on either a single commit or a string of commits (in the case where some commits don't compile), and that's the diff that you have to go through manually; the whole point of bisect is to make that diff as small as possible. If you limit your bisect to testing changes from the history of master (one way or another), you guarantee that you'll land a diff that's a complete feature branch; if you allow the bisect to go through every commits then you have a decent chance of landing on a much smaller diff. > But I am arguing from plenty of real-life experience with a workflow, which is incidentally rebase-based (but the same guarantees would hold just as well if I moved it to a purely merge based approach) where I a) know that every "merge" to master has been fully tested before it lands b) can reliably bisect over ~years of commits with a simple git alias, without having to ever manually bisect skip bad commits[+]. And by construction, not because I hope that devs will generally have tested their commits sufficiently manually or are diligent about fixing merge conflicts in a way that does not result in intermittent broken commits. So whilst several of your other reasons are perfectly valid (long-lived branches), you can maybe see why this one is a bit amusing to me. I've got plenty of real-life experience with plenty of different workflows, thank you very much. If you decide you want a history-of-master history, there are plenty of ways to get that (I'd argue squash-merging is the lowest-overhead way to do it). But the result of that is you get a much less useful bisect than a workflow where you have small commits on feature branches and use merges. > It's not impractical at all, in fact if your company pays me for it I'm more than happy to set it up for you :) I don't work for that company any more, but bear in mind this was for a codebase with 500 developers where builds took around 1.5 hours. We looked at building speculative batches of PRs together but decided the costs were higher than the benefits; master occasionally got broken and we fixed it when it happened. Fundamentally a broken master is always a problem you can have, because flaky tests happen (and, as you mention, meta-level problems can happen). It's good to minimise the times when master is broken, but it's not realistic to assume you can avoid it entirely, so your workflow should be able to handle having the occasional isolated broken commit in the history of master.