Re: Crave patch optimization

Hi, Just to add my +1 to Michael's analysis. It does seem crave is doing a lot of extra work determining the list of correct changes as patches, when a single patch file would be sufficient to run the build. not completely sure if you need that entire metadata for any reason. I ran a quick test

Re: Crave patch optimization

I realized that although I had responded on Aug. 24, the response was sent only to Uv, not to the list. The commits on the PR referenced have changed now, since I went ahead and rebased for this PR in order to be able to merge it. But the response should be applicable to other PRs as well. And in

Re: Crave patch optimization

Thanks Eric. That's exactly what we were hoping to achieve: "shift-left" . In fact, the next step is to give users the ability to run the full test suite directly from their laptops, and not have to wait for Github to run an Action. I think that

Re: Crave patch optimization

Thank you for this work. I have found Crave to be really effective in letting me know when small commits have odd side effects. My laptop is older, so I generally can’t run the full test suite the way I want, and seeing the list of green checks from Crave running the tests is always very

Re: Crave patch optimization

Sorry for the delay, I had to collect this information from the team. As you said: Crave doesn't need to know the commit history, it just needs enough information from git to be able to reproduce the filesystem state on to the remote side without having to do a full rsync. We have to account

Crave patch optimization

Hi Uv: regarding https://lists.apache.org/thread/l8hgqwkm9vt8yhygoo2blw5j4n5gh121 Would it be possible for Crave, instead of using `git format-patch` / `git am`, to instead generate/apply a simple single diff/patch, via `git diff .. > file.patch` / `git apply file.patch`? This would address a