From: Kristoffer Haugsbakk Date: Mon, 15 Dec 2025 23:50:12 GMT Subject: Re: [PATCH RFC 00/11] Introduce git-history(1) command for easy history editing Message-ID: In-Reply-To: On Wed, Dec 10, 2025, at 11:37, Matthias Beyer wrote: >>[snip] >> >> 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. That the first thing here is not magic but the other thing is seems arbitrary: 1. Change these commits, i.e. make new commits and all their descendants 2. Update all branches that point at the commits that have now been replaced These two feel conceptually similar to me in terms of complexity, and neither of them are magical. > > 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.