git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Stefan Beller <sbeller@google.com>
To: Jeff King <peff@peff.net>, "git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: What's cooking in git.git (Nov 2015, #02; Fri, 6)
Date: Wed, 11 Nov 2015 10:59:26 -0800	[thread overview]
Message-ID: <CAGZ79kaK==GhD4nUTh4nnd_NPTNsUG15kS61hAhmP=K6MdHmYg@mail.gmail.com> (raw)
In-Reply-To: <xmqq4mgy3dcr.fsf@gitster.mtv.corp.google.com>

On Fri, Nov 6, 2015 at 3:41 PM, Junio C Hamano <gitster@pobox.com> wrote:
> I'll be offline for a few weeks, and Jeff King graciously agreed to
> help shepherd the project forward in the meantime as an interim
> maintainer.  Please be gentle.
>

Jeff,
gently asking where I can find our interims maintainers tree. :)

> * sb/submodule-parallel-update (2015-11-05) 10 commits
>  - clone: allow an explicit argument for parallel submodule clones
>  - submodule update: expose parallelism to the user
>  - git submodule update: have a dedicated helper for cloning
>  - fetching submodules: respect `submodule.jobs` config option
>  - submodule config: update parse_config()
>  - submodule config: remove name_and_item_from_var
>  - submodule config: keep update strategy around
>  - run_processes_parallel: add output to tracing messages
>  - Merge branch 'rs/daemon-plug-child-leak' into sb/submodule-parallel-update
>  - Merge branch 'sb/submodule-parallel-fetch' into sb/submodule-parallel-update
>  (this branch uses sb/submodule-parallel-fetch.)
>
>  Builds on top of the "fetch --recurse-submodules" work to introduce
>  parallel downloading into multiple submodules for "submodule update".
>
>  Waiting for sb/submodule-parallel-fetch to stabilize.
>
>  It would be the cleanest to rebuild sb/submodule-parallel-fetch on
>  top of 2.7.0 once it ships and then build this directly on top;
>  that way, we do not have to have merges in this topic that
>  distracting (besides, some part of the other topic can be updated
>  in-place instead of this follow-up topic tweaking them as past
>  mistakes and inflexibilities).

Ok I can do that. I am stalling on  sb/submodule-parallel-update
until we all agree on  sb/submodule-parallel-fetch being solid.

>
> * sb/submodule-parallel-fetch (2015-11-05) 16 commits
>  - strbuf: update documentation for strbuf_read_once()
>  - run-command: remove set_nonblocking()
>   (merged to 'next' on 2015-10-23 at 8f04bbd)
>  + run-command: fix missing output from late callbacks
>  + test-run-command: increase test coverage
>  + test-run-command: test for gracefully aborting
>  + run-command: initialize the shutdown flag
>  + run-command: clear leftover state from child_process structure
>  + run-command: fix early shutdown
>   (merged to 'next' on 2015-10-15 at df63590)
>  + submodules: allow parallel fetching, add tests and documentation
>  + fetch_populated_submodules: use new parallel job processing
>  + run-command: add an asynchronous parallel child processor
>  + sigchain: add command to pop all common signals
>  + strbuf: add strbuf_read_once to read without blocking
>  + xread_nonblock: add functionality to read from fds without blocking
>  + xread: poll on non blocking fds
>  + submodule.c: write "Fetching submodule <foo>" to stderr
>  (this branch is used by sb/submodule-parallel-update.)
>
>  Add a framework to spawn a group of processes in parallel, and use
>  it to run "git fetch --recurse-submodules" in parallel.
>
>  Still being worked on, but it seems that we are seeing light at the
>  end of the tunnel.
>  ($gmane/280937)
>

 ($gmane/280937) is represented by
  - strbuf: update documentation for strbuf_read_once()
  - run-command: remove set_nonblocking()

So IMHO we're solid as required for  sb/submodule-parallel-update.

I am not sure if the rebuild on top of 2.7.0 expects a complete new
series which doesn't even mention O_NONBLOCK (squashing some
patches or reordering them), or if we want to keep the history around,
such it is easier to follow the development in the future if some bugs
show up.

  parent reply	other threads:[~2015-11-11 18:59 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-06 23:41 What's cooking in git.git (Nov 2015, #02; Fri, 6) Junio C Hamano
2015-11-07  1:15 ` Edmundo Carmona Antoranz
2015-11-11 18:59 ` Stefan Beller [this message]
2015-11-11 19:11   ` Jeff King
2015-11-11 19:21     ` Stefan Beller

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='CAGZ79kaK==GhD4nUTh4nnd_NPTNsUG15kS61hAhmP=K6MdHmYg@mail.gmail.com' \
    --to=sbeller@google.com \
    --cc=git@vger.kernel.org \
    --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).