From: Elijah Newren <firstname.lastname@example.org> To: Jakub Narebski <email@example.com> Cc: Jeff King <firstname.lastname@example.org>, Git Mailing List <email@example.com> Subject: Re: Contributor Summit Topics and Logistics Date: Mon, 4 Feb 2019 11:30:09 -0800 Message-ID: <CABPp-BGfSRy-NT+f39gSumD9haYZPAnpNPY-VnanioCbdYFoEQ@mail.gmail.com> (raw) In-Reply-To: <firstname.lastname@example.org> Hi Jakub, On Sat, Feb 2, 2019 at 4:39 AM Jakub Narebski <email@example.com> wrote: > I have noticed a little 'recording' indicator; would recorded session > (video or audio only) be made available at some point in time? Did > anyone take minutes, or take notes (for example of the Summit agenda > created at the start of the meeting -- when the audio was muted)? I > would be very interested in your impressions. I took some notes. I'm not sure how useful they'll be given that they were meant just for my own memory (my company said I either had to give a talk at the conference or come back and give a talk to my coworkers about the conference in order for them to pay for it, so I'm doing the latter). But, I'll provide them here in case they're useful to anyone. Discussion points: * Fetch response CDN offloading (Jonathan Tan) * allows resumable cloning * does load balancing * gets the static part of history (e.g. until a week ago) from CDN, and last bits from "main" server * questions about whether to do multiple bits offloaded (e.g. almost full clone, only stuff from last month, etc.); can server keep track of manifest and direct client to necessary subset of pack on a CDN? * A review of "Big" * references, history, wide-checkout, deep-checkout, lots to gc, etc. * newer stuff: partial clones, worktrees, commit-graph * plan to do a breakout session later * NewHash * sha1 -> sha256 * have sha256 repo locally talking to a server using sha1? * as of yesterday, binary that can create either sha1 or sha256 repos * will be using fixed length listing of shas in packfile; if given sha1 is fourth in list, then the corresponding sha256 will be fourth * next: interoperation; fetch & push coming up next * done a fair amount of work so moving to a new hash in the future with a different length should be much less work * no automatic translation of commit messages, but maintenance of dual-mapping of hashes * (Comments on sha1dc & its performance) * Submodules is the biggest issue right now * Poll: prove vs. jumbled output * some people didn't set up prove; some attempts to avoid perl on windows * nearly everyone using prove; could switch to it as the default * Poll: where should Git Merge be next year? * will bring up on list, but Canada is at least an option * North America is more likely to get Junio to come * I tried to push for North America... * Using mailmap by default in git log? * People change names for lots of reasons (including transliteration differences) * Keep an option to not use mailmap * People generally positive on the idea <Lunch> * fetch response sideband-all * sidebands for progress messages and errors * sideband currently limited to when sending packfile * proposal: expand sideband for whole response, not just packfile. * particularly useful given ideas to do CDN * also needed for keep-alive messages * this will be a negotiated new capability (can't do it backward-compatibly) * protocol v2 for push * ref advertisement the main issue * would like to be able to modify the commit message (?!?) * rebase-on-push * reformat-on-push * discussion of how to split messages up into sub-commands * a way to retry pushes without re-pushing everything (e.g. someone else updated the branch, you then re-merged or rebased locally and want to push again, meaning the server already has _most_ the objects but just needs a few new ones) * partial clones * doing work to have multiple remotes (also ties in to CDN usage) * still very tied to having a server around to request additional objects * we need to have a way to keep upload-pack open and do multiple requests * has some ability to filter trees, but we need them for now for index * Matthew Devore doing some work in this area right now, but it appears to be based on depth rather than width? * connection with sparse checkout is kind of hacky right now * there are reachability enforcement issues in V2, which becomes even more of an issue with partial clones (now need to worry about blobs not just commits) * in a partial clone world, server can't gc * sidenote: dumb http support * no major hosting provider supports it * some people like it due to resumability (e.g. Joey Hess & git annex) * cgit provides dumb http support natively * questions I had in area: getting list of initial files of interest... gluing together with sparse checkout partial indexes <break; talked with Michael H. & Thomas G.: filter-repo, checkout overlay> * breakouts: merge, GSoc, structured logging, windows big files; I was in "merge" * merge-recursive rewrite * questions and basic explanation of how the algorithm works * want incremental updates on merge-recursive rewrite * make merge-recursive code part of libgit.a ? * people are very happy about idea to not touch the working tree * make rebase --merge the default * use performance tests to see how well it compares (p3400-rebase.sh) * may later also reimplement the am-specific flags on top of interactive * make use of best merge bases in more places (e.g. git diff A...B uses a suboptimal one) * rebase --rebase-merges: * doing a five-way merge rewriting xdiff to handle five instead of three file versions * M merges A & B * M' should like like a merge of A' and B', but really involved in a five way merge of A', A, M, B, B' -- and that is necessary in order to get evil merge represented * overview of "Big" * git-sizer (funny: git-lab asks users to run it and return results; github runs it for user and shows them the results) * large blobs, partial clones * partial or hierarchical indexes * CI * Dscho has a lot of machinery built up around Azure Pipelines * PRs to github.com:gitgitgadget/git will automatically be built on Windows, MacOS X, and linux * Interest in getting emails for failures that their topic branch caused (note: get topic author from tip commit author if not Junio) * This may be able to move to github.com:git/git after Dscho's patches merge down Stuff that had been mentioned but we didn't get to: state-of-the-union, commit-graph, evolve (we had the developer of the feature in mercurial present, but not the folks who had worked on the feature in git), git filter-repo, maybe a few others I'm forgetting.
next prev parent reply index Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-01-22 7:50 Jeff King 2019-01-22 8:26 ` Jeff King 2019-01-22 9:17 ` GSoC 2019 (was: Contributor Summit Topics and Logistics) Christian Couder 2019-01-31 2:02 ` SZEDER Gábor 2019-01-31 6:11 ` Christian Couder 2019-01-22 18:21 ` Contributor Summit Topics and Logistics Stefan Beller 2019-01-22 20:53 ` Jeff King 2019-01-22 18:23 ` Derrick Stolee 2019-01-24 8:57 ` Ævar Arnfjörð Bjarmason 2019-01-29 18:22 ` Derrick Stolee 2019-01-22 20:30 ` Elijah Newren 2019-01-30 20:57 ` Ævar Arnfjörð Bjarmason 2019-01-30 22:26 ` Jeff Hostetler 2019-01-30 22:51 ` Philip Oakley 2019-01-30 23:13 ` Christian Couder 2019-01-30 23:07 ` Jeff King 2019-02-02 12:33 ` Jakub Narebski 2019-02-04 19:30 ` Elijah Newren [this message] 2019-04-23 3:45 ` Jeff King
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: http://vger.kernel.org/majordomo-info.html * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CABPp-BGfSRy-NT+f39gSumD9haYZPAnpNPY-VnanioCbdYFoEQ@mail.gmail.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
firstname.lastname@example.org list mirror (unofficial, one of many) Archives are clonable: git clone --mirror https://public-inbox.org/git git clone --mirror http://ou63pmih66umazou.onion/git git clone --mirror http://czquwvybam4bgbro.onion/git git clone --mirror http://hjrcffqmbrq6wope.onion/git Example config snippet for mirrors Newsgroups are available over NNTP: nntp://news.public-inbox.org/inbox.comp.version-control.git nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git nntp://news.gmane.io/gmane.comp.version-control.git note: .onion URLs require Tor: https://www.torproject.org/ AGPL code for this site: git clone https://public-inbox.org/public-inbox.git