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

["Philip Oakley" <philipoakley@iee.org>]

From: "Jeff King" <peff@peff.net>
> 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
> archive:
>
>  https://public-inbox.org/git/?q=leftoverbits
>
> 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):
>
>
> https://public-inbox.org/git/20170711101942.h2uwxtgzvgguzivu@sigill.intra.peff.net/
>
>   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
>   down-thread):
>
>
> https://public-inbox.org/git/20170711101942.h2uwxtgzvgguzivu@sigill.intra.peff.net/
>
> - 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
>
>   or
>
>     # 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
>   stdout.
>
>
> 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.
>

A few I've seen recently are:

* The provison of a `git resolve -X <ours|theirs> -- <pathspec>` command to
simplify the manual resolution of remaining conflicts.
https://public-inbox.org/git/8737615iu5.fsf@javad.com/  Sergey Organov: How
to re-merge paths differently?

* (Git for Windows/HFS): Detect directory capitalisation changes when
switching branches, and rename them correctly on case preserving, case
insensitive file systems. Optimisation: If the underlying tree is identical
then do not update the modified dates.
https://github.com/git-for-windows/git/issues/1333 Chuck Lu: Folder name
should be case sensitive when switch branches.

* (Git for Windows/HFS) (long standing):
detect branch name capitalisation issues
- may need a struct to carry both the filename and pathname down the
different parts of the code base so that the FS name of the requested
ref/heads/ can be checked and warned.
e.g. https://github.com/git-for-windows/git/issues/852 "`git checkout head`
inconsistent behavior"
- ('head' finds 'HEAD', but also 'branch' finds 'Branch');
https://github.com/git-for-windows/git/issues/852#issuecomment-239675187 ->
"rambling notes" for partial analysis.

https://github.com/git-for-windows/git/issues/752 "git checkout creating
tracking branch using case-insensitive match?"
- Is this part of the same problem?

* Documentation:

There's always the newby role at the hackathon of collating
all the "what does this command do/mean?" questions that could be resolved
by simple updates, or capturing locally written explanations to improve the
manual pages. (easy patch practice)

Perhaps see how `git rerere` could be better explained and integrated onto
the other man pages so that more folk naturally know of it and use it. (see
also the `git resolve` question above)

Also for case sensitivity documentation
https://github.com/git-for-windows/git/issues/908#issuecomment-325116189

--
Philip