Re: [PATCH v5 00/14] Introduce new `git replay` command

From: Christian Couder <christian.couder@gmail.com>
Date: Nov 2, 2023, 14:44 UTC
Message-ID: <CAP8UFD0iS2za20Mzy2Dy7XLnhHTwN-_=8gV-NCzxzxcfaF-TMQ@mail.gmail.com>
In-Reply-To: <CABPp-BGfsda-8CK7_YPJfhGMfpLqdDeB8X6wnqPAGmhiY4KjDA@mail.gmail.com>

Hi Elijah and Dscho,

On Mon, Oct 30, 2023 at 6:18 PM Elijah Newren <newren@gmail.com> wrote:

> On Sun, Oct 29, 2023 at 7:14 AM Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> > On Sat, 28 Oct 2023, Elijah Newren wrote:

Show 19 quoted lines

> > > I can see why this might sometimes be useful for exclusively linear
> > > history, but it seems to open a can of worms and possibly unfixable
> > > corner cases for non-linear history.  I'd rather not do this, or at
> > > least pull it out of this series and let us discuss it in some follow
> > > up series.  There are some other alternatives that might handle such
> > > usecases better.
> >
> > I find myself wishing for an easy way to reverse commits, if only to
> > switch around the latest two commits while stopped during a rebase.
> >
> > So it would have been nice for me if there had been an easy, worktree-less
> > way to make that happen.
>
> Seems reasonable; we'll definitely want to keep this in mind.
>
> > I guess this would be going in the direction of reordering commits,
> > though, something we deliberately left for later?
>
> Yes, I think that's a good framing for it.

Ok, in the v6 I just sent, a warning() is emitted when `--reverse` is passed and the option has no effect.

I agree that handling such options in a better way should be left for later patch series.

Thanks both!