Skip to content

Instantly share code, notes, and snippets.

@avar
Created October 19, 2011 20:16
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 1 You must be signed in to fork a gist
  • Save avar/1299536 to your computer and use it in GitHub Desktop.
Save avar/1299536 to your computer and use it in GitHub Desktop.
Amsterdam Git Hackathon Ideas
These should all be things we can tackle in a day or a weekend with
relatively small knowledge of Git subsystems so someone with general
Unix/C programming knowledge can pick them up, Or a mature existing
patch series that we can help with.
* Is 8 threads optimal for git-grep?
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.
* Let's make git log's -G have a -P or --perl-regexp argument
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.
* Make git-bisect friendler
Currently it prints out full sha1's, doesn't abbreviate commits,
doesn't use color etc.
* Fix up the 31337 patch
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.
Note: Much of this was done by Jeff already, but we could document
it etc.
* Fix up the remote-helper patches
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.
* Make the "ambiguous refname" error less useless
Currently we have:
$ git checkout -b avar/boobs -t origin/trunk
warning: refname 'origin/trunk' is ambiguous.
warning: refname 'origin/trunk' is ambiguous.
fatal: Ambiguous object name: 'origin/trunk'.
Which you have to find like this:
$ git branch -a -l | grep trunk
origin/trunk
* trunk
And fix like this:
$ git branch -D origin/trunk
Deleted branch origin/trunk (was 0021ca7).
It would be much better if the error just listed why the refname
was ambiguous.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment