From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:203:b4db::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms12 with LMTPS id cE/LKTW9aGJUdAAAsNZ9tg (envelope-from ) for ; Wed, 27 Apr 2022 03:49:09 +0000 Received: from out2.migadu.com ([2001:41d0:2:aacc::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id OM0DKTW9aGIGYAEA9RJhRA (envelope-from ) for ; Wed, 27 Apr 2022 05:49:09 +0200 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kyleam.com; s=key1; t=1651031349; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Ox87cGMv/ofNaweSiV/RRk+qn8HIsI/MBM7aNZeK0Uc=; b=FGIhsY+N1E1MNCpSr23v7qwCc6BaRpG9ZKAXTpB2lBT9h9P9aYVKzNEnlryU1AGwVyeqSz edSM+m9jubDBt3IqtHgi2soNNu2LZ+Ihjq9aTy34wAbKvGKODst308YhTANdFAfeY3f4Qd MFLyXcVP+TrOR42sqmCBxPJZT1MhMw/J42Ek5ry1QhVAaKRJIqe5ywmlppvVH3thEivF2X 8fuDZMdEACMBd3uPOgIzKV4d/dvSqomgUz1cpqigOrOTQrS/rXWqlgevjJKLUGaRODWqYC a6upxMN63XRO/soH0joQGAzRbLGqoCKLkIFhWNEX9OasEKYv+JEZexlQMyauOg== From: Kyle Meyer To: Ihor Radchenko Cc: piem@inbox.kyleam.com Subject: Re: Applying the same patch multiple times In-Reply-To: <8735i0urq7.fsf@localhost> References: <87v8uyncpl.fsf@localhost> <87pml6871p.fsf@kyleam.com> <8735i0urq7.fsf@localhost> Date: Tue, 26 Apr 2022 23:49:07 -0400 Message-ID: <8735hzi3t8.fsf@kyleam.com> MIME-Version: 1.0 Content-Type: text/plain X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: kyleam.com X-TUID: AOU6EEvmJLOl Ihor Radchenko writes: > I also noticed one minor annoyance when I return to work on the > previously applied patch. > > My starting point is the patch-containing email. Then, I run piem-am and > use the default automatically generated branch. Interesting, using the email as the staring point for jumping to a branch isn't a use case that I've considered, but, yeah, I can see why that's appealing. > Expected behaviour: Silently switch to the already existing branch > unless that branch had modifications to the patch in the email. In the > latter case, either throw an error or show the changes interactively. Hmm, this makes a strong assumption about the patch to branch name mapping, but the branch name offered in the prompt is just a (hopefully helpful) suggestion/starting point. To implement this feature, I'm not seeing a way around needing to maintain the mapping. The first thing that comes to mind is that the Git configuration for the branch could be a good place to keep it (say branch.$branch.piem-mid). That would allow generating the mid->branch mapping for a coderepo and has the nice feature that it's cleaned up by Git when the branch is deleted. There are other wrinkles here, but I think the overall approach would probably be workable. > Observed behaviour: Because the branch already exists and the patch is > already applied, git am throws an error. Odd. I expected the git-checkout call upstream of git-am to fail (saying something like "fatal: a branch named 'blah' already exists"). Testing quickly, that's what I see on my end. (Either way, that's of course not your desired behavior.) > I think a more useful approach would be something like: > 1. piem creates a throwaway branch and apply the patch in the email > 2. piem rebases the existing branch onto that throwaway branch I'm not quite connecting this (1)... > That way, I can start working on a patch from email, possibly add some > followup commits and still be able to return to this WIP branch starting > from the patch email. ...to this (2). 2 more or less aligns with how I understood the rest of your email, but I don't see where 1 comes in. If you already applied a patch from a particular message, that patch isn't changing, so wouldn't you just want to jump to the associated branch, even if you amended the given commit and/or added commits on top? Perhaps the answer is that these are updated patches from later messages. I'd say those ought to land on a separate branch, though I know that unfortunately some people aren't good about bumping the reroll count of their patches, in which case the suggested branch name won't be different. Thanks for your feedback.