{"thread":{"id":"51236","subject":"Re: [PATCH] am: add --check option","startedAt":"2019-06-04T05:58:56Z","lastAt":"2019-06-04T14:06:23Z","messageCount":3,"participants":["Johannes Sixt","Johannes Schindelin","Christian Couder"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"376645","messageId":"c1dec466-55ca-8543-8f4e-b5daf1e0eab6@kdbg.org","threadId":"51236","inReplyTo":"BUKFSM2OTJUH.38N6DGWH9KX7H@homura","subject":"Re: [PATCH] am: add --check option","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2019-06-04T05:58:51Z","receivedAt":"2019-06-04T05:58:56Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 04.06.19 um 00:00 schrieb Drew DeVault:\n> On Mon Jun 3, 2019 at 11:09 PM Johannes Sixt wrote:\n>> I have to wonder how --check works when 'am' applies multiple patches.\n>>\n>> When the second patch in a patch series depends on that the first patch\n>> is fully applied, what does --check do? Without the first patch applied,\n>> then a naive check of the second patch will certainly fail, doesn't it?\n> \n> Yeah, this was being discussed in another thread. It'll fail if the\n> second patch relies on changes from the first. Open to suggestions on\n> how to improve that, but I think it can be improved in a later patch.\n> One solution would be to apply all of the patches and then roll back the\n> head, but that would dirty the reflog and wouldn't work on a read-only\n> filesystem (which it ought to, imo). We can't just say bugger this for a\n> lark and ask people to use git-apply, because git-apply chokes on the\n> typical email which isn't in the one specific format git-apply wants to\n> see (git-am massages emails into that format before sending them to\n> git-apply).\n> \n\nYou can 'git apply --cached' the patches on a temporary index. This\nworks as long as no merge is necessary, because that would require a\nworktree.\n\n-- Hannes\n"},{"id":"376655","messageId":"nycvar.QRO.7.76.6.1906041539090.1775@tvgsbejvaqbjf.bet","threadId":"51236","inReplyTo":"c1dec466-55ca-8543-8f4e-b5daf1e0eab6@kdbg.org","subject":"Re: [PATCH] am: add --check option","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2019-06-04T13:40:13Z","receivedAt":"2019-06-04T13:40:35Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 4 Jun 2019, Johannes Sixt wrote:\n\n> Am 04.06.19 um 00:00 schrieb Drew DeVault:\n> > On Mon Jun 3, 2019 at 11:09 PM Johannes Sixt wrote:\n> >> I have to wonder how --check works when 'am' applies multiple patches.\n> >>\n> >> When the second patch in a patch series depends on that the first patch\n> >> is fully applied, what does --check do? Without the first patch applied,\n> >> then a naive check of the second patch will certainly fail, doesn't it?\n> >\n> > Yeah, this was being discussed in another thread. It'll fail if the\n> > second patch relies on changes from the first. Open to suggestions on\n> > how to improve that, but I think it can be improved in a later patch.\n> > One solution would be to apply all of the patches and then roll back the\n> > head, but that would dirty the reflog and wouldn't work on a read-only\n> > filesystem (which it ought to, imo). We can't just say bugger this for a\n> > lark and ask people to use git-apply, because git-apply chokes on the\n> > typical email which isn't in the one specific format git-apply wants to\n> > see (git-am massages emails into that format before sending them to\n> > git-apply).\n> >\n>\n> You can 'git apply --cached' the patches on a temporary index. This\n> works as long as no merge is necessary, because that would require a\n> worktree.\n\nFor extra brownie points, this could be done in-memory, without writing\nout any files.\n\nOf course, while applying diffs should never need any merge, with the `-3`\noption, merges might be necessary, still...\n\nCiao,\nJohannes\n"},{"id":"376659","messageId":"CAP8UFD0d5ptCpn+u8-p=oa3gZFYdbeW+KapVcmKgqPQKR4scwA@mail.gmail.com","threadId":"51236","inReplyTo":"c1dec466-55ca-8543-8f4e-b5daf1e0eab6@kdbg.org","subject":"Re: [PATCH] am: add --check option","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2019-06-04T14:06:07Z","receivedAt":"2019-06-04T14:06:23Z","isPatch":true,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Tue, Jun 4, 2019 at 8:03 AM Johannes Sixt <j6t@kdbg.org> wrote:\n>\n> Am 04.06.19 um 00:00 schrieb Drew DeVault:\n> > On Mon Jun 3, 2019 at 11:09 PM Johannes Sixt wrote:\n> >> I have to wonder how --check works when 'am' applies multiple patches.\n> >>\n> >> When the second patch in a patch series depends on that the first patch\n> >> is fully applied, what does --check do? Without the first patch applied,\n> >> then a naive check of the second patch will certainly fail, doesn't it?\n> >\n> > Yeah, this was being discussed in another thread. It'll fail if the\n> > second patch relies on changes from the first. Open to suggestions on\n> > how to improve that, but I think it can be improved in a later patch.\n\nI think both features could be useful. For example sometimes a\nmaintainer might want to know if applying only a patch that is in the\nmiddle of a patch series (for example something security related)\ncould work without having to apply the previous patchs. So maybe both\na --check and a --dry-run with different behavior regarding patch\nseries would make sense.\n"}]}