Sparse Index: integrate with reset #1048
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Welcome to GitGitGadgetHi @vdye, and welcome to GitGitGadget, the GitHub App to send patch series to the Git mailing list from GitHub Pull Requests. Please make sure that your Pull Request has a good description, as it will be used as cover letter. Also, it is a good idea to review the commit messages one last time, as the Git project expects them in a quite specific form:
It is in general a good idea to await the automated test ("Checks") in this Pull Request before contributing the patches, e.g. to avoid trivial issues such as unportable code. Contributing the patchesBefore you can contribute the patches, your GitHub username needs to be added to the list of permitted users. Any already-permitted user can do that, by adding a comment to your PR of the form Both the person who commented An alternative is the channel Once on the list of permitted usernames, you can contribute the patches to the Git mailing list by adding a PR comment If you want to see what email(s) would be sent for a After you submit, GitGitGadget will respond with another comment that contains the link to the cover letter mail in the Git mailing list archive. Please make sure to monitor the discussion in that thread and to address comments and suggestions (while the comments and suggestions will be mirrored into the PR by GitGitGadget, you will still want to reply via mail). If you do not want to subscribe to the Git mailing list just to be able to respond to a mail, you can download the mbox from the Git mailing list archive (click the curl -g --user "<EMailAddress>:<Password>" \
--url "imaps://imap.gmail.com/INBOX" -T /path/to/raw.txtTo iterate on your change, i.e. send a revised patch or patch series, you will first want to (force-)push to the same branch. You probably also want to modify your Pull Request description (or title). It is a good idea to summarize the revision by adding something like this to the cover letter (read: by editing the first comment on the PR, i.e. the PR description): To send a new iteration, just add another PR comment with the contents: Need help?New contributors who want advice are encouraged to join git-mentoring@googlegroups.com, where volunteers who regularly contribute to Git are willing to answer newbie questions, give advice, or otherwise provide mentoring to interested contributors. You must join in order to post or view messages, but anyone can join. You may also be able to find help in real time in the developer IRC channel, |
|
/allow |
|
User vdye is now allowed to use GitGitGadget. WARNING: vdye has no public email address set on GitHub |
|
@vdye: have you considered taking only the Just a thought. If you're comfortable going with a big series right away, then ignore me. |
derrickstolee
changed the title
|
I changed the title so you didn't forget (it becomes the subject of your cover letter). |
vdye
changed the title
|
/submit |
|
Submitted as pull.1048.git.1633013461.gitgitgadget@gmail.com To fetch this version into To fetch this version to local tag |
![gitgitgadget[bot]](https://avatars.githubusercontent.com/in/12836?s=60&v=4){kind=small}
| @@ -459,9 +459,7 @@ test_expect_failure 'blame with pathspec outside sparse definition' ' | |||
| test_all_match git blame deep/deeper2/deepest/a | |||
There was a problem hiding this comment.
On the Git mailing list, Taylor Blau wrote (reply to this):
On Thu, Sep 30, 2021 at 02:50:56PM +0000, Victoria Dye via GitGitGadget wrote:
> From: Victoria Dye <vdye@github.com>
>
> In anticipation of multiple commands being fully integrated with sparse
> index, update the test for index expand and collapse for non-sparse index
> integrated commands to use `mv`.
>
> Signed-off-by: Victoria Dye <vdye@github.com>
> ---
> t/t1092-sparse-checkout-compatibility.sh | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/t/t1092-sparse-checkout-compatibility.sh b/t/t1092-sparse-checkout-compatibility.sh
> index c5977152661..aed8683e629 100755
> --- a/t/t1092-sparse-checkout-compatibility.sh
> +++ b/t/t1092-sparse-checkout-compatibility.sh
> @@ -642,7 +642,7 @@ test_expect_success 'sparse-index is expanded and converted back' '
> init_repos &&
>
> GIT_TRACE2_EVENT="$(pwd)/trace2.txt" GIT_TRACE2_EVENT_NESTING=10 \
> - git -C sparse-index -c core.fsmonitor="" reset --hard &&
> + git -C sparse-index -c core.fsmonitor="" mv a b &&
Double-checking my understanding as somebody who is not so familiar with
t1092: this test is to ensure that commands which don't yet understand
the sparse index can temporarily expand it in order to do their work?
If so, makes sense to me. And renaming 'a' to 'b' is arbitrary and fine
to do since we end up recreating the sparse-index repository each time
via init_repos.
Looks good to me.
Thanks,
Taylor
There was a problem hiding this comment.
On the Git mailing list, Victoria Dye wrote (reply to this):
Taylor Blau wrote:
> On Thu, Sep 30, 2021 at 02:50:56PM +0000, Victoria Dye via GitGitGadget wrote:
>> From: Victoria Dye <vdye@github.com>
>>
>> In anticipation of multiple commands being fully integrated with sparse
>> index, update the test for index expand and collapse for non-sparse index
>> integrated commands to use `mv`.
>>
>> Signed-off-by: Victoria Dye <vdye@github.com>
>> ---
>> t/t1092-sparse-checkout-compatibility.sh | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/t/t1092-sparse-checkout-compatibility.sh b/t/t1092-sparse-checkout-compatibility.sh
>> index c5977152661..aed8683e629 100755
>> --- a/t/t1092-sparse-checkout-compatibility.sh
>> +++ b/t/t1092-sparse-checkout-compatibility.sh
>> @@ -642,7 +642,7 @@ test_expect_success 'sparse-index is expanded and converted back' '
>> init_repos &&
>>
>> GIT_TRACE2_EVENT="$(pwd)/trace2.txt" GIT_TRACE2_EVENT_NESTING=10 \
>> - git -C sparse-index -c core.fsmonitor="" reset --hard &&
>> + git -C sparse-index -c core.fsmonitor="" mv a b &&
>
> Double-checking my understanding as somebody who is not so familiar with
> t1092: this test is to ensure that commands which don't yet understand
> the sparse index can temporarily expand it in order to do their work?
Exactly - if a command doesn't explicitly enable use of the sparse index by
setting `command_requires_full_index` to 0, the index is expanded if/when it
is first read during the command's execution and collapsed if/when it is
written to disk. This test makes sure that mechanism works as intended.
-Victoria
There was a problem hiding this comment.
On the Git mailing list, Junio C Hamano wrote (reply to this):
Victoria Dye <vdye@github.com> writes:
> Taylor Blau wrote:
>> On Thu, Sep 30, 2021 at 02:50:56PM +0000, Victoria Dye via GitGitGadget wrote:
>>> From: Victoria Dye <vdye@github.com>
>>>
>>> In anticipation of multiple commands being fully integrated with sparse
>>> index, update the test for index expand and collapse for non-sparse index
>>> integrated commands to use `mv`.
>>> ...
>>> GIT_TRACE2_EVENT="$(pwd)/trace2.txt" GIT_TRACE2_EVENT_NESTING=10 \
>>> - git -C sparse-index -c core.fsmonitor="" reset --hard &&
>>> + git -C sparse-index -c core.fsmonitor="" mv a b &&
>>
>> Double-checking my understanding as somebody who is not so familiar with
>> t1092: this test is to ensure that commands which don't yet understand
>> the sparse index can temporarily expand it in order to do their work?
>
> Exactly - if a command doesn't explicitly enable use of the sparse index by
> setting `command_requires_full_index` to 0, the index is expanded if/when it
> is first read during the command's execution and collapsed if/when it is
> written to disk. This test makes sure that mechanism works as intended.
Sorry, I do not quite follow.
So is this "before this series of patches, 'reset --hard' can be
used to as a sample of a command that expands and then collapses,
but because it no longer is a good sample of a command so we replace
it with 'mv a b'"? Do we need to update this further when "mv a b"
learns to expand and then collapse?
There was a problem hiding this comment.
On the Git mailing list, Victoria Dye wrote (reply to this):
Junio C Hamano wrote:
> Victoria Dye <vdye@github.com> writes:
>
>> Taylor Blau wrote:
>>> On Thu, Sep 30, 2021 at 02:50:56PM +0000, Victoria Dye via GitGitGadget wrote:
>>>> From: Victoria Dye <vdye@github.com>
>>>>
>>>> In anticipation of multiple commands being fully integrated with sparse
>>>> index, update the test for index expand and collapse for non-sparse index
>>>> integrated commands to use `mv`.
>>>> ...
>>>> GIT_TRACE2_EVENT="$(pwd)/trace2.txt" GIT_TRACE2_EVENT_NESTING=10 \
>>>> - git -C sparse-index -c core.fsmonitor="" reset --hard &&
>>>> + git -C sparse-index -c core.fsmonitor="" mv a b &&
>>>
>>> Double-checking my understanding as somebody who is not so familiar with
>>> t1092: this test is to ensure that commands which don't yet understand
>>> the sparse index can temporarily expand it in order to do their work?
>>
>> Exactly - if a command doesn't explicitly enable use of the sparse index by
>> setting `command_requires_full_index` to 0, the index is expanded if/when it
>> is first read during the command's execution and collapsed if/when it is
>> written to disk. This test makes sure that mechanism works as intended.
>
> Sorry, I do not quite follow.
>
> So is this "before this series of patches, 'reset --hard' can be
> used to as a sample of a command that expands and then collapses,
> but because it no longer is a good sample of a command so we replace
> it with 'mv a b'"?
Yes, because this series enables sparse index integration in `git reset`,
the test no longer applies to that command (but it does apply to `git mv`).
> Do we need to update this further when "mv a b"
> learns to expand and then collapse?
Unfortunately, yes. `git mv` was picked more-or-less at random from the set
of commands that read the index and don't already have sparse index
integrations (excluding those I know are planned for sparse index
integration in the near future). If `git mv` were to be updated to disable
`command_requires_full_index`, the command in the test would need to change
again.
For what it's worth, I do think the test itself is valuable, since it makes
sure a command's capability to use the sparse index is always the result of
an intentional update to (and review of) the code.
There was a problem hiding this comment.
On the Git mailing list, Junio C Hamano wrote (reply to this):
Victoria Dye <vdye@github.com> writes:
>> Do we need to update this further when "mv a b"
>> learns to expand and then collapse?
>
> Unfortunately, yes. `git mv` was picked more-or-less at random from the set
> of commands that read the index and don't already have sparse index
> integrations (excluding those I know are planned for sparse index
> integration in the near future). If `git mv` were to be updated to disable
> `command_requires_full_index`, the command in the test would need to change
> again.
>
> For what it's worth, I do think the test itself is valuable, since it makes
> sure a command's capability to use the sparse index is always the result of
> an intentional update to (and review of) the code.
Oh, of course.
I was actually wondering if it woudl be a good idea to leave a
command that will never be "converted" so that we can keep using it
for testing.
Perhaps a new option that is invented exactly for the purpose added
to a plumbing e.g. "git update-index --expand-collapse"?
There was a problem hiding this comment.
On the Git mailing list, Victoria Dye wrote (reply to this):
Junio C Hamano wrote:
> Victoria Dye <vdye@github.com> writes:
>
>>> Do we need to update this further when "mv a b"
>>> learns to expand and then collapse?
>>
>> Unfortunately, yes. `git mv` was picked more-or-less at random from the set
>> of commands that read the index and don't already have sparse index
>> integrations (excluding those I know are planned for sparse index
>> integration in the near future). If `git mv` were to be updated to disable
>> `command_requires_full_index`, the command in the test would need to change
>> again.
>>
>> For what it's worth, I do think the test itself is valuable, since it makes
>> sure a command's capability to use the sparse index is always the result of
>> an intentional update to (and review of) the code.
>
> Oh, of course.
>
> I was actually wondering if it woudl be a good idea to leave a
> command that will never be "converted" so that we can keep using it
> for testing.
>
> Perhaps a new option that is invented exactly for the purpose added
> to a plumbing e.g. "git update-index --expand-collapse"?
>
That sounds good to me! I'll add an `update-index --expand-collapse`
implementation and update the test in v2 of this series.
|
User |
| @@ -459,9 +459,7 @@ test_expect_failure 'blame with pathspec outside sparse definition' ' | |||
| test_all_match git blame deep/deeper2/deepest/a | |||
There was a problem hiding this comment.
On the Git mailing list, Bagas Sanjaya wrote (reply to this):
On 30/09/21 21.50, Victoria Dye via GitGitGadget wrote:
> From: Victoria Dye <vdye@github.com>
>
> In anticipation of multiple commands being fully integrated with sparse
> index, update the test for index expand and collapse for non-sparse index
> integrated commands to use `mv`.
>
We can say "use git sparse-index mv instead of git sparse-index reset".
Why is mv used for this case?
--
An old man doll... just what I always wanted! - Clara
|
User |
| @@ -25,6 +25,8 @@ | |||
| #include "cache-tree.h" | |||
There was a problem hiding this comment.
On the Git mailing list, Victoria Dye wrote (reply to this):
Victoria Dye via GitGitGadget wrote:
> diff --git a/t/t1092-sparse-checkout-compatibility.sh b/t/t1092-sparse-checkout-compatibility.sh
> index 0b6ff0de17d..c9b9ef4992c 100755
> --- a/t/t1092-sparse-checkout-compatibility.sh
> +++ b/t/t1092-sparse-checkout-compatibility.sh
> @@ -801,14 +801,25 @@ test_expect_success 'sparse-index is not expanded' '
> for ref in update-deep update-folder1 update-folder2 update-deep
> do
> echo >>sparse-index/README.md &&
> + ensure_not_expanded reset --mixed $ref
> ensure_not_expanded reset --hard $ref || return 1
> done &&
This is a bug - it's missing `&&` at the end of the line (and adding it will
cause the test to fail). The index is expanded if a mixed reset modifies an
entry outside the sparse cone, so I'll update the test in V2 to verify reset
between two refs with only in-cone files changed between them.
|
/submit |
|
Submitted as pull.1048.v2.git.1633440057.gitgitgadget@gmail.com To fetch this version into To fetch this version to local tag |
|
On the Git mailing list, Ævar Arnfjörð Bjarmason wrote (reply to this): |
|
User |
|
On the Git mailing list, Victoria Dye wrote (reply to this): |
|
On the Git mailing list, Elijah Newren wrote (reply to this): |
Rename and invert value of `is_missing` to `is_in_reset_tree` to make the variable more descriptive of what it represents. Signed-off-by: Victoria Dye <vdye@github.com>
|
/submit |
|
Submitted as pull.1048.v3.git.1633641339.gitgitgadget@gmail.com To fetch this version into To fetch this version to local tag |
Documentation/git-update-index.txt
Outdated
| @@ -24,6 +24,7 @@ SYNOPSIS | |||
| [--[no-]fsmonitor] | |||
There was a problem hiding this comment.
On the Git mailing list, Bagas Sanjaya wrote (reply to this):
On 08/10/21 04.15, Victoria Dye via GitGitGadget wrote:
> From: Victoria Dye <vdye@github.com>
>
> Add a new `--force-full-index` option to `git update-index`, which skips
> explicitly setting `command_requires_full_index`. This option, intended for
> use in internal testing purposes only, lets `git update-index` run as a
> command without sparse index compatibility implemented, even after it
> receives updates to otherwise use the sparse index.
>
> The specific test `--force-full-index` is intended for - `t1092 -
> sparse-index is expanded and converted back` - verifies index compatibility
> in commands that do not change the default (enabled)
> `command_requires_full_index` repo setting. In the past, the test used `git
> reset`. However, as `reset` and other commands are integrated with the
> sparse index, the command used in the test would need to keep changing.
> Conversely, the `--force-full-index` option makes `git update-index` behave
> like a not-yet-sparse-aware command, and can be used in the test
> indefinitely without interfering with future sparse index integrations.
>
> Helped-by: Junio C Hamano <gitster@pobox.com>
> Signed-off-by: Victoria Dye <vdye@github.com>
Grammar looks OK.
Reviewed-by: Bagas Sanjaya <bagasdotme@gmail.com>
--
An old man doll... just what I always wanted! - Clara
Disable `command_requires_full_index` repo setting and add `ensure_full_index` guards around code paths that cannot yet use sparse directory index entries. `reset --soft` does not modify the index, so no compatibility changes are needed for it to function without expanding the index. For all other reset modes (`--mixed`, `--hard`, `--keep`, `--merge`), the full index is expanded to prevent cache tree corruption and invalid variable accesses. Additionally, the `read_cache()` check verifying an uncorrupted index is moved after argument parsing and preparing the repo settings. The index is not used by the preceding argument handling, but `read_cache()` must be run *after* enabling sparse index for the command (so that the index is not expanded unnecessarily) and *before* using the index for reset (so that it is verified as uncorrupted). Signed-off-by: Victoria Dye <vdye@github.com>
Remove `ensure_full_index` guard on `prime_cache_tree` and update `prime_cache_tree_rec` to correctly reconstruct sparse directory entries in the cache tree. While processing a tree's entries, `prime_cache_tree_rec` must determine whether a directory entry is sparse or not by searching for it in the index (*without* expanding the index). If a matching sparse directory index entry is found, no subtrees are added to the cache tree entry and the entry count is set to 1 (representing the sparse directory itself). Otherwise, the tree is assumed to not be sparse and its subtrees are recursively added to the cache tree. Helped-by: Elijah Newren <newren@gmail.com> Signed-off-by: Victoria Dye <vdye@github.com>
|
There is an issue in commit 1b3631a: |
Remove the `ensure_full_index` guard on `read_from_tree` and update `git reset --mixed` to ensure it can use sparse directory index entries wherever possible. Sparse directory entries are reset using `diff_tree_oid`, which requires `change` and `add_remove` functions to process the internal contents of the sparse directory. The `recursive` diff option handles cases in which `reset --mixed` must diff/merge files that are nested multiple levels deep in a sparse directory. The use of pathspecs with `git reset --mixed` introduces scenarios in which internal contents of sparse directories may be matched by the pathspec. In order to reset *all* files in the repo that may match the pathspec, the following conditions on the pathspec require index expansion before performing the reset: * "magic" pathspecs * wildcard pathspecs that do not match only in-cone files or entire sparse directories * literal pathspecs matching something outside the sparse checkout definition Helped-by: Elijah Newren <newren@gmail.com> Signed-off-by: Victoria Dye <vdye@github.com>
To find the first non-unpacked cache entry, `next_cache_entry` iterates through index, starting at `cache_bottom`. The performance of this in full indexes is helped by `cache_bottom` advancing with each invocation of `mark_ce_used` (called by `unpack_index_entry`). However, the presence of sparse directories can prevent the `cache_bottom` from advancing in a sparse index case, effectively forcing `next_cache_entry` to search from the beginning of the index each time it is called. The `cache_bottom` must be preserved for the sparse index (see 17a1bb5 (unpack-trees: preserve cache_bottom, 2021-07-14)). Therefore, to retain the benefit `cache_bottom` provides in non-sparse index cases, a separate `hint` position indicates the first position `next_cache_entry` should search, updated each execution with a new position. Signed-off-by: Victoria Dye <vdye@github.com>
|
There is an issue in commit 1b3631a: |
|
/preview |
|
Preview email sent as pull.1048.v6.git.1638200459.gitgitgadget@gmail.com |
|
/submit |
|
Submitted as pull.1048.v6.git.1638201164.gitgitgadget@gmail.com To fetch this version into To fetch this version to local tag |
|
On the Git mailing list, Elijah Newren wrote (reply to this): |
|
On the Git mailing list, Victoria Dye wrote (reply to this): |
|
This patch series was integrated into seen via git@7484d84. |
|
This patch series was integrated into seen via git@dcb05a1. |
|
There was a status update in the "Cooking" section about the branch Various operating modes of "git reset" have been made to work better with the sparse index. Will merge to 'next'. |
|
On the Git mailing list, Elijah Newren wrote (reply to this): |
|
On the Git mailing list, Ævar Arnfjörð Bjarmason wrote (reply to this): |
|
This patch series was integrated into seen via git@434cd01. |
|
This patch series was integrated into seen via git@c8099ad. |
|
This patch series was integrated into seen via git@2f9cc17. |
|
This patch series was integrated into next via git@47b1095. |
|
This patch series was integrated into seen via git@d595dbd. |
|
There was a status update in the "Cooking" section about the branch Various operating modes of "git reset" have been made to work better with the sparse index. Will merge to 'master'. source: <pull.1048.v6.git.1638201164.gitgitgadget@gmail.com> |
|
This patch series was integrated into seen via git@3c82291. |
|
This patch series was integrated into seen via git@8ca2776. |
|
There was a status update in the "Cooking" section about the branch Various operating modes of "git reset" have been made to work better with the sparse index. Will merge to 'master'. source: <pull.1048.v6.git.1638201164.gitgitgadget@gmail.com> |
|
This patch series was integrated into seen via git@55ef6d4. |
|
There was a status update in the "Graduated to 'master'" section about the branch Various operating modes of "git reset" have been made to work better with the sparse index. source: <pull.1048.v6.git.1638201164.gitgitgadget@gmail.com> |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This series integrates the sparse index with
git resetand provides miscellaneous fixes and improvements to the command in sparse checkouts. This includes:t1092andp2000to establish the baseline functionality of the commandensure_full_indexguarding any code paths that break tests without other compatibility updates.ensure_full_indexmust be called.The sparse index updates are predicated on a fix originating from the microsoft/git fork [1], correcting how
git reset --mixedhandles resetting entries outside the sparse checkout definition. Additionally, a performance "bug" innext_cache_entrywith sparse index is corrected, preventing repeatedly looping over already-searched entries.The
p2000tests demonstrate a ~70% execution time reduction ingit resetusing a sparse index, and no change (within expected variability [2]) using a full index. Results summarized below [3, 4]:Changes since V1
--force-full-indexoption toupdate-index. The option is used circumvent changingcommand_requires_full_indexfrom its default value - right now this is effectively a no-op, but will change onceupdate-indexis integrated with sparse index. By using this option in thet1092expand/collapse test, the command used to test will not need to be updated with subsequent sparse index integrations.skip-worktreeenabled and a reset would change the file, check it out".update_index_from_diffwith renames, found that the diff used byresetdoes not produce diff queue entries with different pathnames foroneandtwo. Because of this, and that nothing in the implementation seems to rely on identical path names, noBUGcheck is added.sparse index is not expandedtests int1092where failure of agit reset --mixedtest was not being reported. Test now verifies an appropriate scenario with corrected failure-checking.Changes since V2
git reset --mixedwith sparse checkout with preserving theskip-worktreeflag (including a new test forgit reset --mixedand update tot1092 - checkout and reset (mixed))is_missinginto its own patcht1092tests and remove unnecessary commands/tests where possibleensure_full_indexingit reset --mixed, add relatedensure_not_expandedtestsindex_search_modeenum toindex_name_stage_possubtree_pathinprime_cache_tree_recChanges since V3
git update-index --force-full-indexwithgit reset update-folder1 -- folder1/a, remove introduction of new--force-full-indexoption entirely, and add comment clarifying the intent ofsparse-index is expanded and converted backtestreset: preserve skip-worktree bit in mixed reset(current patch fully replaces original patch, but metadata of the original wasn't properly replaced)Changes since V4
t1092test 'checkout and reset (mixed)' to explicitly verify differences between sparse and full checkoutsChanges since V5
t1092test 'reset with wildcard pathspec' with more cases and better checksChanges since V6
t1092test 'reset with pathspecs outside sparse definition' to verify index contentsThanks!
-Victoria
[1] microsoft/git@6b8a074
[2] https://lore.kernel.org/git/8b9fe3f8-f0e3-4567-b20b-17c92bd1a5c5@github.com/
[3] If a test and/or commit is not mentioned, there is no significant change to performance
[4] Pathspec "does-not-exist" is changed to "missing" to save space in performance report
cc: stolee@gmail.com
cc: gitster@pobox.com
cc: newren@gmail.com
cc: Taylor Blau me@ttaylorr.com
cc: Bagas Sanjaya bagasdotme@gmail.com
cc: Ævar Arnfjörð Bjarmason avarab@gmail.com
cc: Phillip Wood phillip.wood123@gmail.com
cc: Emily Shaffer emilyshaffer@google.com