Carl Sorensen <carl.d.soren...@gmail.com> writes: >> On 5/14/20, 8:04 AM, "David Kastrup" <d...@gnu.org> wrote: >> >> Patchy, however, is set up in a manner where it picks up work not when >> staging is ahead of master, but rather when staging is ahead of its last >> tested version. >> >> That means that even if the migration to master may proceed with the >> vote of one Patchy, _every_ instance of Patchy will look at whether it >> is satisfied with the current state in a timely manner. >> >> So the diversity of our Patchy setups may not keep something working >> only on some platforms from getting into master, but it will still not >> stay under the radar indefinitely. >> > > I think you have not understood the issue with which I am concerned. > Suppose I have a fix for an issue that contains six commits. The > first 3 result in failure to make doc. The last 3 fix the problem. > So after the set of 6 commits, everything is good. > > Under our past standards, I would be expected to rebase those six > commits into a single commit and push to staging.
Not necessarily. Particularly work where 95% of the work is done by script and 5% of manual cleanup, merging both commits is not a good idea. I usually push those as a merge. Doesn't strictly help against hitting the middle with git bisect, but at least it makes it quite clear what is happening then. > Thus, staging builds. > > Many of the commits I have been verifying from the last year have not > rebased those six commits into a single commit. The six individual > commits are pushed to staging, each with its own commit ID. But since > they are all pushed at one time, Patchy never tests the state after > commit 2. > > Now, a year later, we're trying to find a regression. We're using > git-bisect. git-bisect lands on commit 2 and tries (and fails) to > build. This messes up my git-bisect run, and I have to deal with > things manually. > > My request is that we have some way of preventing this problem by > either (a) having our CI test each of my six commits and finding out > that 3 of them fail, thus requiring me to rebase before the PR is > accepted; or (b) having an automated merge process that combines my > six commits into a single commit and then tests it with CI to > demonstrate that it passes, and only the combined commit gets sent to > master. I think that this involves making decisions that depend on human discretion. -- David Kastrup
