From: Phillip Wood Date: Wed, 10 Dec 2025 11:34:20 GMT Subject: Re: [PATCH RFC 00/11] Introduce git-history(1) command for easy history editing Message-ID: In-Reply-To: On 10/12/2025 10:37, Matthias Beyer wrote: > Am Wed, Dec 10, 2025 at 09:58:13AM +0000, schrieb Phillip Wood: >> On 03/12/2025 18:18, Matthias Beyer wrote: >>> Am Wed, Sep 17, 2025 at 10:12:31PM +0200, schrieb SZEDER Gábor: >>> >>>> Let's suppose I have this piece of history, I'm on 'branch2', and I >>>> drop commit B. Which commits will be rewritten and which branches >>>> will be repointed? >>>> >>>> A---B---C---D branch1 >>>> \ \ >>>> \ E---F branch2 >>>> \ \ >>>> \ G---H---I branch3 >>>> \ >>>> J---K---L branch4 >>>> >>> >>> Just speaking as a user here, but my expectation in this scenario would >>> be that rewriting B would be denied by default here, as branch{1..4} >>> would be rewritten although I am at branch2. >>> >>> In the scenario at hand, I would expect that I can only rewrite G, H, I >>> while on branch 3 and J, K, L while on branch4 (without passing some >>> extra flags for "yes, please also rewrite the other branches"). >> >> Is that because you have branches that you don't want to rewrite because >> they've been merged upstream or is there another reason? If we start >> rewriting multiple branches we should probably check that we're not >> rewriting something that has been merged upstream but if I rewrite a commits >> that's an ancestor of several branches it would be very helpful to rewrite >> them all at the same time to keep them in sync. > > Its mostly because I don't like too much magic and because I think being > explicit is always better than not. > > So from my POV, I would expect "the simple case" to be "the simple CLI > call" and if I want the tool to do magic and "rewrite all the > things"^tm, that I would need to specify a flag for that. Thanks, that's useful to know. I'd assumed rewriting all the branches descended from the rewritten commit was the natural thing do do but clearly not everyone thinks it is. Phillip