Tips on speeding up in linux.git?

[troglobit]

Hi, awseome little extension this! 😎👍

We (me and @wkz) are playing around with it for stacking patch-sets (in the form of stacked git branches) in the Linux kernel tree. Works great ... except for the time to run git stack ... in particular git stack --repair after cherry-picking a few commits to an intermediate branch. Commands take up to a minute to complete.

Any tips on how to speed this up?

[epage]

What version are you running? On the 16th, I released 0.7 which has massive speed improvements. git stack on gecko-dev went from ~25s to less than 1s.

If you are on on 0.7 or newer, could you provide a repo I could clone with reproduction steps so I can profile it and see how we can improve it?

[epage]

Ok, hadn't realized Eden was providing all of that functionality.

[epage]

#220 is merged

v0.8.2 will automatically split off these old branches before building the graph, speeding things up.

git stack is still about 6s in my use cases, so the gain were significant but not enough for frequent use. I'm assuming we'd need on-disk caching for that.

[troglobit]

Amazing, will try it out tomorrow @ $DAYJOB \o/

[arxanas]

@epage for an on-disk merge-base cache, feel free to copy https://github.com/arxanas/git-branchless/blob/b48ed600777f73e410732e613b199a09e6dafaf2/src/core/mergebase.rs if it helps.

[epage]

I've created #222 to split out conversations on how to go about this

[arxanas]

@troglobit Can you try installing git-branchless and running git move on the same rebase? (Or install the latest version from source and try git sync. If it completes substantially faster, then it's probably libgit2/libgit2#6036.

EDIT: oops, I misunderstood which operation was slow, so I think the above doesn't apply.

@epage assuming that it's the above issue, I would love to get git-branchless's implementations of cherry-picking, etc. into git2-ext. That being said, the stated goals of the project are to 'Provide "good enough" implementations'. Should we expand the scope of the project to provide high-performance/production-ready implementations?

PS: the "about" text for the git2-ext repository on the Github page is broken, it just says "git Exte" and is cut off.

Reference on git-branchless's cherry_pick_fast: https://github.com/arxanas/git-branchless/blob/a4bc3c0c31b7be5cdd95ed8cfe4385e384482a99/src/git/repo.rs#L914-L924

[epage]

@epage assuming that it's the above issue, I would love to get git-branchless's implementations of cherry-picking, etc. into git2-ext. That being said, the stated goals of the project are to 'Provide "good enough" implementations'. Should we expand the scope of the project to provide high-performance/production-ready implementations?

Yes, just haven't gotten to this yet.

The "good enough" just means we're not going to try to support every single use case possible,. that it serves as a common case and documentation for customization. If you have better ideas on conveying that, I'm game.

PS: the "about" text for the git2-ext repository on the Github page is broken, it just says "git Exte" and is cut off.

I've updated that but for some reason the settings app isn't working

Oh right, forgot to install it in the new org.

[epage]

Broke the git2-ext conversations out into gitext-rs/git2-ext#7