On 30/01/2019 20:57, Ævar Arnfjörð Bjarmason wrote:
On Tue, Jan 22 2019, Jeff King wrote:
There's no set agenda; we'll decide what to discuss that day. But if
anybody would like to mention topics they are interested in (whether you
want to present on them, or just have an open discussion), please do so
here. A little advance notice can help people prepare more for the
discussions.
This is definitely a "little" advance seeing as it's tomorrow morning.
Even if you're not coming, please feel free to suggest topics (but bonus
points if you convince somebody who _is_ coming to lead the session).
Things I'd be interested in hearing / talking about about that haven't
yet been mentioned.
These are in descending order of how interesting I think these will be
to a general audience, to the point where maybe only I care about the
bottom of this list...
* "Big repos". We had discussions about this in years past. It's a very
spawly and vague topic. Do we mean big history, big blobs, big (in
size/depth/width) checkouts etc?
But regardless, many of us deal with this in one way or another, and
it would be good to have a top-level overview of how the various
solutions to this that are being integrated into git.git are doing /
what people see on the horizon for scalabiltiy.
I'd also like a bit of discussion about ensuring that the partial clone
& filtering aspects of 'big repos' (if partial is needed /used then it's
big ...) still retain the full 'distributed' nature and capability of git.
Also in some environments the filtering may want to be applied at the
server end (based on it's knowledge of the specific user). Ultimately it
should also pull in some of the sub-module aspects as super projects are
just big repos in disguise.
* "Structured remote logging". We had an RFC spec for turning our trace
format into something more structural with a way to send it to a
remote server. There were both implementation & privacy concernse,
last time at least a couple of users of git reported having in-house
patches for this (not ready for upstream). Where are we on this now?
* "commit graph by default". I had this on my list, but Derrick Stolee
sent out a much better summary:
https://public-inbox.org/git/6d0dc2a2-120c-0d42-1910-14ffed7adaf1@xxxxxxxxx/
* I've been using (but haven't yet re-rolled) my "relative SHA-1
abbreviation" series
(https://public-inbox.org/git/20180608224136.20220-1-avarab@xxxxxxxxx/)
I'm interested in seeing if anyone else is interested in this, and
particularly what the overlap (if any) is between this & midx.
* "Making strict fsck checks on clone the default". I worked a bit on
this in this last year in between a couple of security issues that
needed fsck checks. Has caveats etc., but would give users some more
protections.
* "The CI I set up for git on the GCC Compile Farm". Can be folded into
a general "state of git.git CI" topic:
https://gitlab.com/git-vcs/git-ci/pipelines
* If people care about making the TAP mode in our test suite mandatory
(i.e. require "prove" or a tool like it). See
https://public-inbox.org/git/87zhrj2n2l.fsf@xxxxxxxxxxxxxxxxxxx/
I also had some questions regarding tree walk issues for follower and
friendly fork repos that have lots of deadheads within their tree, such
as previous release versions in Git for Windows. It should be easier to
filter those deadheads (or at least suggest the best way of creating
such sentinels).
--
Philip
