> Le 3 nov. 2017 à 02:10, Gregory Szorc <g...@mozilla.com> a écrit : > > On Thu, Nov 2, 2017 at 5:00 PM, Manish Goregaokar <manishsm...@gmail.com> > wrote: > >> <snip/> > > The Firefox repo has the same dilemma. Ideally history is good down to the > commit level. In reality, we only test on "push heads" (commits that were > heads at time of their push) so this is the only thing we try to claim. > Adding more reality, we have tons of bad push heads and even this guarantee > is weak. (There's a plan to employ the forced use of autoland combined with > history rewriting to tackle this. Bug 1266863 tracks.) > > If you squash commits, you potentially lose a lot of valuable data. Depends > if the squashed-over commits are valuable or not. I agree in not wanting to > lose this important history just to maintain commit-level bisectability.
In my experience, this is very rarely an issue. There is no reason to keep a notably broken commit for "history". > The lack of tools being able to bisect over arbitrary commits is a tooling > problem IMO. `hg bisect --skip <revset>` solves this nicely in Mercurial > land. You can get something similar with Git but Git's commit selection > facilities aren't as powerful, so it is a bit harder to use. Improving > tooling is a solvable problem and I don't think should be used as > justification to throw away useful commit-level data! FWIW, Mercurial 4.4 > supports revsets that read revisions from files or command output. So you > can maintain a list of "known good" or "known bad" bisectable commits in > the repo and feed that into `hg bisect --skip`. How is that different from `git bisect --skip` and `git bisect replay`? But anyway, Servo uses Git. ;) > At repos as large as Servo and Firefox, commit-level bisection would > require a lot of testing resources. Maybe you can do lightweight tests on > every commit. But all the tests is almost certainly prohibitively expensive. > > Instead of imposing a hard or fast rule, mine would be phrased as a goal. > "Attempt to write commits that are all "good." But this property can be a) > intentionally violated if squashing commits would result in loss of > information important to archeology or b) unintentionally violated because > not all commits are actually tested." Or something along those lines. I think that would indeed be the best, as a guideline. I just don't want to hear "shrug, I don't have time for this" (which is something I've already encountered in the past). _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
