On 2024/03/27 11:17:32 +0100, Stefan Sperling <stsp@stsp.name> wrote:
> On Tue, Mar 26, 2024 at 03:02:54PM +0100, Stefan Sperling wrote:
> > On Tue, Mar 26, 2024 at 02:53:22PM +0100, Stefan Sperling wrote:
> > > On Wed, Jan 31, 2024 at 07:27:10PM +0100, Christian Weisgerber wrote:
> > > > Stefan Sperling:
> > > > 
> > > > > > That merge commit de0fe38 prevents rebasing "master" on "origin/master".
> > > > > 
> > > > > Does "master" above mean commit 9cd4661 (HEAD -> master)?
> > > > 
> > > > Yes.
> > > 
> > > Below is a series of 3 patches which fix this problem by teaching the
> > > commit graph about topological sort order.
> > 
> > The changes I sent were not nicely split up, mixing unrelated got.c
> > and regression test changes into the first commit.
> > 
> > This version should be easier to review:
> 
> Here is another version which avoids the need to add a new option
> to 'got rebase'. Instead 'got rebase' checks whether a merge commit
> is present in the new base branch and then searches for a better
> youngest common ancestor using toposort, taking the merged commits
> into account. This means running 'got rebase' should "just work".
> 
> The price we pay is some additional run-time overhead. But I am happy
> to let rebase run a bit slower if this means we can avoid needless
> conflicts the user will have to figure out what to do with.

yeah, that's better even in the short term.

> The 'got log' command still gets the new -t option however.
> 
> ok?

ok op@