These should all be things we can tackle in a day or a weekend with relatively small knowledge of existing Git subsystems.
grep.c has this:
#define THREADS 8
Which was added back in 5b594f457afcf2cdddb3c79de8bcc571c775aa55. Let’s find out if we can’t make this faster by using the method `parallel –number-of-cores` uses to find out the number of cores at runtime. Maybe 8 isn’t optimal for e.g. 2 or 24 core boxes.
git-grep already has this now, but it would be neat to have it for git log.
In the process we could split out the use of regcomp() into its own function which we could use more widely.
Also it would be nice to have e.g.:
git log -G’/foobar/i’
I.e. just declare that arguments matching ^/(.*?)/(?:ism)*$ are regex operators, currently the operators to regcomp are hardcoded in the git source.
Currently it prints out full sha1’s, doesn’t abbreviate commits, doesn’t use color etc.
http://article.gmane.org/gmane.comp.version-control.git/183943 add a –collide option to git-commit and document it. Find out how to make the existing bitmask check efficient for arbitrary strings.
Also try if doing the brute-forcing in N threads is faster.
Starting with the fast export fixes at: https://github.com/SRabbelier/git/tree/fe-fixes we should be able to use 281eee4 (revision: keep track of the end-user input from the command line, 2011-08-25) to fix up the patch series to where Junio will merge it.