Web lists-archives.com

Re: Git Open Source Weekend London 11th/12th November

On Wed, Nov 01, 2017 at 04:36:24PM +0000, Thomas Gummerer wrote:

> Normally attendees work in small groups on a specific task to
> prevent anyone from getting stuck. Per usual, Bloomberg will
> provide the venue, mentors, snacks and drinks.  Bring your
> enthusiasm (and your laptop!) and come share in the fun!  The
> event is also open to everyone, so feel free to pass on the
> invite!

I think it will help if the experienced members of the community (both
those who will be at the event and not) can come up with some possible
topics to work on (though of course I'd be glad for participants to come
with their own itch to scratch).

We've started using the #leftoverbits tag to allow searching in the


Some of those have since been completed, but others are left open.
There's not really a master list, but it's a potential source for
digging for gold (well, if you want to call leftover bugs gold :) ).

I started a list over the summer of larger items that people might want
to pick up. Here it is in no particular order:

 - the pager.<cmd> config is mis-designed, because our config keys
   cannot represent all possible command names (e.g., case folding and
   illegal characters). This should be pager.<cmd>.enable or similar.
   Some discussion in (this message and the surrounding thread):


   But I think you could find more by searching the archive.

 - ditto for alias.* config, which has the same syntax problems.

 - auto-gc is sometimes over-anxious to run if you have a lot of
   unreachable loose objects. We should pack unreachables into a single
   pack. That solves the --auto problem, and is also way more efficient.
   The catch is expiration. Some discussion here (and especially


 - git-config's "--get-color" is unlike all the other types in that it
   takes a "default" value if the config key isn't set. This makes it annoyingly
   inconsistent, but there's also no way to ask Git to interpret other
   values (e.g., you might want it to expand "--path" or an "--int"). It
   would be nice to have a general "--default" option so you could do:

     # same as git config --get-color color.diff.old red
     git config --default red --color color.diff.old


     # not currently possible to ask git to interpret "10k"
     git config --default 10k --int some.integer.key

 - git's internal config can parse expiration dates (see
   parse_expiry_date()), but you can't do so from git-config. It should
   probably have a type for "--expiry-date" (which would of course be
   more useful with the --default option above).

 - there's no efficient way to ask git-config for several keys with a
   specific type (or even multiple different types).  You can use
   "--list" to get their strings, but you can't get any interpretation
   (like colors, integers, etc). Invoking git-config many times can have
   a noticeable speed impact for a script. There should probably be a
   "--stdin" mode (or maybe "--get-stdin" if we would one day want to
   have a "--set-stdin") that takes a list of keys, optional types, and
   optional defaults (that "--default" again!) and outputs them to

Those were just sitting on my ideas list. I'm happy to go into more
detail if anybody's interested in discussing any of them. Some of them
may be half-baked.

And of course I'd be happy if people wanted to contribute more items to
the list.