# Re: [PATCH] am: add --check option 3 messages from 2019-06-04 to 2019-06-04. Participants: Johannes Sixt, Johannes Schindelin, Christian Couder. Thread: https://gitlist.dev/t/51236 ## Johannes Sixt, 2019-06-04 05:58 Subject: Re: [PATCH] am: add --check option Message-ID: URL: https://gitlist.dev/e/c1dec466-55ca-8543-8f4e-b5daf1e0eab6%40kdbg.org In-Reply-To: ``` Am 04.06.19 um 00:00 schrieb Drew DeVault: > On Mon Jun 3, 2019 at 11:09 PM Johannes Sixt wrote: >> I have to wonder how --check works when 'am' applies multiple patches. >> >> When the second patch in a patch series depends on that the first patch >> is fully applied, what does --check do? Without the first patch applied, >> then a naive check of the second patch will certainly fail, doesn't it? > > Yeah, this was being discussed in another thread. It'll fail if the > second patch relies on changes from the first. Open to suggestions on > how to improve that, but I think it can be improved in a later patch. > One solution would be to apply all of the patches and then roll back the > head, but that would dirty the reflog and wouldn't work on a read-only > filesystem (which it ought to, imo). We can't just say bugger this for a > lark and ask people to use git-apply, because git-apply chokes on the > typical email which isn't in the one specific format git-apply wants to > see (git-am massages emails into that format before sending them to > git-apply). > You can 'git apply --cached' the patches on a temporary index. This works as long as no merge is necessary, because that would require a worktree. -- Hannes ``` ## Johannes Schindelin, 2019-06-04 13:40 Subject: Re: [PATCH] am: add --check option Message-ID: URL: https://gitlist.dev/e/nycvar.QRO.7.76.6.1906041539090.1775%40tvgsbejvaqbjf.bet In-Reply-To: ``` Hi, On Tue, 4 Jun 2019, Johannes Sixt wrote: > Am 04.06.19 um 00:00 schrieb Drew DeVault: > > On Mon Jun 3, 2019 at 11:09 PM Johannes Sixt wrote: > >> I have to wonder how --check works when 'am' applies multiple patches. > >> > >> When the second patch in a patch series depends on that the first patch > >> is fully applied, what does --check do? Without the first patch applied, > >> then a naive check of the second patch will certainly fail, doesn't it? > > > > Yeah, this was being discussed in another thread. It'll fail if the > > second patch relies on changes from the first. Open to suggestions on > > how to improve that, but I think it can be improved in a later patch. > > One solution would be to apply all of the patches and then roll back the > > head, but that would dirty the reflog and wouldn't work on a read-only > > filesystem (which it ought to, imo). We can't just say bugger this for a > > lark and ask people to use git-apply, because git-apply chokes on the > > typical email which isn't in the one specific format git-apply wants to > > see (git-am massages emails into that format before sending them to > > git-apply). > > > > You can 'git apply --cached' the patches on a temporary index. This > works as long as no merge is necessary, because that would require a > worktree. For extra brownie points, this could be done in-memory, without writing out any files. Of course, while applying diffs should never need any merge, with the `-3` option, merges might be necessary, still... Ciao, Johannes ``` ## Christian Couder, 2019-06-04 14:06 Subject: Re: [PATCH] am: add --check option Message-ID: URL: https://gitlist.dev/e/CAP8UFD0d5ptCpn%2Bu8-p%3Doa3gZFYdbeW%2BKapVcmKgqPQKR4scwA%40mail.gmail.com In-Reply-To: ``` On Tue, Jun 4, 2019 at 8:03 AM Johannes Sixt wrote: > > Am 04.06.19 um 00:00 schrieb Drew DeVault: > > On Mon Jun 3, 2019 at 11:09 PM Johannes Sixt wrote: > >> I have to wonder how --check works when 'am' applies multiple patches. > >> > >> When the second patch in a patch series depends on that the first patch > >> is fully applied, what does --check do? Without the first patch applied, > >> then a naive check of the second patch will certainly fail, doesn't it? > > > > Yeah, this was being discussed in another thread. It'll fail if the > > second patch relies on changes from the first. Open to suggestions on > > how to improve that, but I think it can be improved in a later patch. I think both features could be useful. For example sometimes a maintainer might want to know if applying only a patch that is in the middle of a patch series (for example something security related) could work without having to apply the previous patchs. So maybe both a --check and a --dry-run with different behavior regarding patch series would make sense. ```