Re: [PATCH RFC 00/11] Introduce git-history(1) command for easy history editing

>
> On Wed, Dec 10, 2025 at 10:27 AM Elijah Newren <newren@gmail.com> wrote:
> >
> > On Wed, Dec 10, 2025 at 8:52 AM Martin von Zweigbergk
> > <martinvonz@gmail.com> wrote:
> > >
> > > On Wed, Dec 10, 2025 at 2:38 AM Matthias Beyer <mail@beyermatthias.de> wrote:
> > > >
> > > > Am Wed, Dec 10, 2025 at 09:58:13AM +0000, schrieb Phillip Wood:
> > > > > Hi Matthias
> > > > >
> > > > > 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?
> > >
> > > I think that's a common reason even if it's not Matthias's reason.
> > > Perhaps one way of doing it would be to have a configurable set of ref
> > > patterns that are considered immutable. That's similar to what jj
> > > does, though we use a more general language for selecting revisions
> > > for it (https://docs.jj-vcs.dev/latest/config/#set-of-immutable-commits).
> > > I think that has been well received. As you might expect, the set of
> > > immutable revisions are respected by all commands.
> >
> > I like the idea of a set of immutable revisions...but wouldn't that
> > result in the request to drop commit B in the graph above being met
> > with an error rather than with a single branch being rewritten?
>
> If branch1 (or any of those branches, really) is configured as
> immutable, then yes. But it's desirable to prevent rewriting or
> dropping B in that case, right?