Re: Request for adding a "one-shot" rebase strategy where conflicts are only resolved once

From: Alireza <rezaxm@gmail.com>
Date: Oct 3, 2024, 21:10 UTC
Message-ID: <CAD9n_qieu_DNqu-X-gTGua+K-vQysYRoDGzEBgwOhH-w4YU1Bg@mail.gmail.com>
In-Reply-To: <f2ae51a2-95e9-43d4-beba-774d05bfc3e9@app.fastmail.com>

As far as I know, rerere remembera an exact resolution, but with rebase you may have to deal with different conflicts for each commit This makes that completely irrelevant, to elaborate there's basically two possibility: (1) a clean merge is possible but individual commits may conflict (2) a clean merge is not possible which means there may be conflicts at some point onward

This only creates one conflict off of the latest revision (same as git merge) or skip if a clean merge is possible Then each commit is reconstructed based on that resolution so there's no back and forth.

Hope this helps.

Thanks,

On Thu, Oct 3, 2024 at 11:45 PM Kristoffer Haugsbakk <kristofferhaugsbakk@fastmail.com> wrote:

Show 16 quoted lines

>
> On Thu, Oct 3, 2024, at 21:06, Alireza wrote:
> > Sometimes a clean merge is possible but with a rebase, in-between
> > commits may raise conflicts in which case a conflict must be resolved
> > for each commit individually, which is not quite productive and at the
> > end wouldn't add so much in how the resulting history looks like.
> >
> > With a "one-shot" rebase, a conflict (if any) is made based on the
> > latest revision, then in-between commits approximated based on that
> > resolution. This way the history can be roughly preserved with the
> > same amount of effort while still using a rebase rather than merge.
>
> How would this compare to using git-rerere(1)?
>
> --
> Kristoffer Haugsbakk