git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Elijah Newren <newren@gmail.com>
To: Jakub Narebski <jnareb@gmail.com>
Cc: Jeff King <peff@peff.net>, Git Mailing List <git@vger.kernel.org>
Subject: Re: Contributor Summit Topics and Logistics
Date: Mon, 4 Feb 2019 11:30:09 -0800	[thread overview]
Message-ID: <CABPp-BGfSRy-NT+f39gSumD9haYZPAnpNPY-VnanioCbdYFoEQ@mail.gmail.com> (raw)
In-Reply-To: <86va22qsj1.fsf@gmail.com>

Hi Jakub,

On Sat, Feb 2, 2019 at 4:39 AM Jakub Narebski <jnareb@gmail.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.

  reply	other threads:[~2019-02-04 19:30 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-22  7:50 Contributor Summit Topics and Logistics 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 \
    --to=newren@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=jnareb@gmail.com \
    --cc=peff@peff.net \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).