ndbroadbent/scm_breeze — pull request #132 by LFDM (2014-01-29 22:48:22+00:00)
Title: Refactor of git status script

Hello there, I wanted to use the niced up git status but it was a little sluggish, so I took a look at it.
It appears that the original implementation queried git too much, which leads to bad performance - and to the `$gs_max_changes` variable.

I rewrote the script completely. Still works and looks the same though of course!
Looking at the benchmark results the effort was worth it:

```
# querying a repo with lots of submodules on an older laptop
git status # => 0.233
status_shortcuts.rb-NEW # => 0.270 | + 0.037
status_shortcuts.rb-OLD # => 0.567 | + 0.334

# same repo on a faster desktop
git status # => 0.104
status_shortcuts.rb-NEW # => 0.129 | + 0.025
status_shortcuts.rb-OLD # => 0.246 | + 0.142
```

Interpreting these results a bit: The old implementation needs to query the git status twice, extrapolating these numbers (0.233 * 2 = 0.466) tell that the actual Ruby code adds roughly an overhead of 100ms, while the new implementation has only a Ruby overhead of 37ms.
So the actual Ruby code runs faster, git runs faster and I think the script looks a little nicer :)

There are two issues that need to be addressed if you are interested in merging:
- Two tests
- 1) `test_git_status_shortcuts_max_changes` obviously fails, as `$gs_max_changes` is not implemented. I think the script is fast enough now to deprecate the variable altogether.
- 2) `test_adding_files_with_spaces` also fails, but I would be in favor of the new script here: The old implementation quotes `"files with spaces.txt"`, `git status` itself doesn't do it, the new script also just shows `files with spaces.txt` in plain text.
- Typechanged files
- You handled these files differently in your script (using only a relative path instead of an absolute). I fail to see the reasoning right now. Can you clarify? I'll happily add modifications to the PR then.

That's it, hope you can use it!