On Thu, Mar 02, 2023 at 07:35:30AM -0800, Elijah Newren wrote: > I've got bad news for you and great news for you. > > The bad news: there have not yet been any efforts to build these > optimizations mentioned above. > > The great news: the fact that this affects you means you are using > non-bare clones in your mergeability checks, and being forced with > every merge to first checkout the appropriate branch, and pay for the > penalty of updating both the index and the working tree both in that > checkout and during the merge (and perhaps in doing a hard reset > afterwards) in your mergeability check, despite the fact that a > mergeability check really only needs a boolean: "does it merge > cleanly?". Doing a full worktree-tied merge like this is really > expensive, and while the above Git changes may have made it even more > expensive for you, the real savings comes from switching to a bare > clone and not writing any working tree files or the index. That's > available via running `git merge-tree`; see the documentation for the > --write-tree option in particular. GitHub switched over to it last > year and GitLab should be switching soon (or may have already > completed it; I haven't checked in a bit). > > You are, of course, more than welcome to build the optimizations Junio > alludes to. It'd help out various end users. But for improving > server side operations, I think switching to `git merge-tree` would > provide you _much_ bigger benefits. Many thanks for the detailed reply Elijah; indeed the good news outweighs the bad news! I've started migrating to merge-tree and it looks great. Once complete I might take a look at the other optimizations anyway, as a fun project. Thanks again! Best Regards, Ben Humphreys
