Team, On Fri, 24 Aug 2018, Johannes Schindelin wrote:
> while this mail talks about Git for Windows, please keep in mind that we > try *very* hard to keep Git for Windows' master working correctly not only > on Windows but also on macOS and Linux. > > I, for one, run Git built from Git for Windows' `master` branch in my > Linux VMs all the time. > > As all of you know by now, the fact that Git was pretty much designed to > work well on Linux is not exactly helping Git for Windows. (Or for that > matter, macOS: Git is substantially slower on macOS than on Linux when > running on the same hardware.) The quickest pay-off comes from converting > Unix shell scripts (which are designed to spawn processes, whereas Windows > is more optimized for multi-threaded applications). > > For that reason, I was delighted to see that our Google Summer of Code > pushed pretty hard in that direction. And I could not help myself so I had > to test how much faster things got. Here is the result of my first, really > quick and dirty test: > > without builtin stash/rebase with builtin stash/rebase > t3400 (rebase) 1m27s 32s > t3404 (rebase -i) 13m15s 3m59s > t3903 (stash) 8m37s 1m18s > > What can I say? Even if the numbers are off by as much as 10%, these are > impressive improvements: keep in mind that there is a lot of churn going > on in the test suite because it is itself implemented in Unix shell > scripts (and hence I won't even bother to try more correct performance > benchmarking because that is simply not possible when Unix shell scripts > are in the equation). So the speed improvements of the stash/rebase > commands are *even higher* than this. > > So I really, really, really want those builtins in Git for Windows > v2.19.0. At *least* as an option. > > Therefore, after creating a pre-release of Git for Windows corresponding > to Git v2.19.0-rc0, I created another one (note the .2 at the end), *with* > those new builtins: > https://github.com/git-for-windows/git/releases/tag/v2.19.0-rc0.windows.2 > > I would like to ask you for help in dog-fooding this. In particular if you > are a heavy stash/rebase user (like I am), it would be helpful to really > kick those tires. > > Of course, those are only Windows binaries on that web page, but it should > be easy to compile from that tag on Linux and macOS. I could also build a > macOS installer and add it to that pre-release, is there interest in that? > > Currently I am uncertain whether I should spend the time to reinstate the > old scripted `git stash` guarded by `stash.useBuiltin` and the old > scripted `git rebase -i` (guarded by the same `rebase.useBuiltin` that > guards the scripted `git rebase`), as a fall-back (or make the new > builtins opt-ins instead of opt-outs). > > So far, I have not encountered any serious bug, but then, I did not really > have a chance to use it yet (I installed it, of course, but I have not > done any serious rebasing yet). So your help will be crucial in > determining where I need to spend time. Thomas Gummerer pointed out just how dangerously I want to live, so I did implement the `stash.useBuiltin` option (and extended the `rebase.useBuiltin` option to also cover `rebase -i`), and made the use of those builtins an opt-in, i.e. still default to the scripted versions. You can see my progress in this PR (which I mainly opened to have this tested on Windows, macOS and Linux): https://github.com/git-for-windows/git/pull/1800 Ciao, Johannes
