Hi Phillip, On Thu, Apr 2, 2020 at 2:39 AM Phillip Wood <phillip.wood123@xxxxxxxxx> wrote: > > On 02/04/2020 06:15, Elijah Newren wrote: > > As a heads up, though, my personal plans for rebase (subject to buy-in > > from other stakeholders) is to make it do a lot more in-memory work. > > In particular, this means for common cases there will be no subprocess > > invocations, no writing of any state unless/until you hit a conflict, > > no updating of any files in the working tree until all commits have > > been created (or a conflict is hit), > > I'm with you up to here - it sounds fantastic > > > and no updating of the branch > > until after all the commits have been created. > > We only update the branch reflog at the end of the rebase now. > > > Thus, for the common > > cases with no conflicts, there would only be 1 entry in the reflog of > > HEAD the entire operation, rather than approximately 1 per commit. > > This I'm not so sure about. In the past where I've messed up a rebase > and not noticed until after a subsequent rebase it has been really > useful to be able to go through HEAD's reflog and find out where exactly > I messed up by looking at the sequence of picks for the first rebase. > Specifically it shows which commits where squashed together which you > cannot get by running git log on the result of the rebase. Interesting. Hmm.... > > I > > have a proof-of-concept showing these ideas work for basic cases. > > Sounds exciting Feel free to take a look: See https://github.com/newren/git/blob/git-merge-2020-demo/README.md and https://github.com/newren/git/blob/git-merge-2020-demo/builtin/fast-rebase.c Sadly, between sparse-checkout, expoential slowdown in dir.c, and various reports about rebase for 2.26, I haven't been able to work on that stuff since the morning of March 4. And I've been ignoring some non-git stuff that I really need to work on. But hopefully I'll get to start cleaning things up soon and sending them on to the list for review. I keep hoping...
