All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Stefan Beller <sbeller@google.com>
Cc: Jonathan Nieder <jrnieder@gmail.com>,
	"git\@vger.kernel.org" <git@vger.kernel.org>,
	Jens Lehmann <Jens.Lehmann@web.de>
Subject: Re: [PATCHv9 0/6] Expose submodule parallelism to the user
Date: Tue, 09 Feb 2016 14:03:13 -0800	[thread overview]
Message-ID: <xmqqziv91qzi.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <CAGZ79kYt9bw9MreiBhA_ZQNjS+1Xi71aNGwkjcfC1hwxkOoyYA@mail.gmail.com> (Stefan Beller's message of "Tue, 9 Feb 2016 13:46:59 -0800")

Stefan Beller <sbeller@google.com> writes:

>>> * This seems to clash with 00/20] refs backend.
>>>> Applied this on top of a merge between the current 'master' and
>>>> 'sb/submodule-parallel-update' topic to untangle the dependency;
>>>> otherwise there is no way for this topic to make progress X-<.
>>>
>>> Anything I can do to help with easing the clash?
>>
>> Perhaps try to rebase the series on top of such a merge (with this
>> updated series) yourself and propose it as a basis for the next
>> reroll for David?  In short, working together with topic(s) that
>> touch the same area?
>
> Ok, I'll see if I can find a better commit to base this series on.

That is not what I meant.  I meant rebasing the refs-backend series
on top of a merge between this one and 'master', just like the way I
queued the refs-backend series on top of a merge between the
previous round of this series and 'master'.

These two topics want to update the same piece of code, so another
possibility is to rebase this series on top of a merge between
refs-backend and 'master', but the current iteration of refs-backend
already depends on the previous round of this topic.  Rebasing this
on top of refs-backend would involve first adjusting parts of
refs-backend that touched the same code as the previous round of
submodule-parallel-update touched so that refs-backend would work
directly on top of 'master', and then including the necessary change
to the refs-backend code while rebuilding submodule-parallel-update
on top of the result.  So I do not think you would go in that
direction.

  reply	other threads:[~2016-02-09 22:03 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-09 20:54 [PATCHv9 0/6] Expose submodule parallelism to the user Stefan Beller
2016-02-09 20:54 ` [PATCHv9 1/6] submodule-config: keep update strategy around Stefan Beller
2016-02-09 21:08   ` Junio C Hamano
2016-02-09 22:19     ` Stefan Beller
2016-02-09 22:29       ` Junio C Hamano
2016-02-09 21:49   ` Jonathan Nieder
2016-02-09 22:32   ` Junio C Hamano
2016-02-11 20:00     ` Junio C Hamano
2016-02-09 20:54 ` [PATCHv9 2/6] submodule-config: drop check against NULL Stefan Beller
2016-02-09 21:50   ` Jonathan Nieder
2016-02-09 20:54 ` [PATCHv9 3/6] fetching submodules: respect `submodule.fetchJobs` config option Stefan Beller
2016-02-09 21:12   ` Junio C Hamano
2016-02-09 22:34   ` Jonathan Nieder
2016-02-10  0:11     ` Stefan Beller
2016-02-10  1:12       ` Junio C Hamano
2016-02-10  2:04         ` Junio C Hamano
2016-02-09 20:54 ` [PATCHv9 4/6] git submodule update: have a dedicated helper for cloning Stefan Beller
2016-02-09 21:24   ` Junio C Hamano
2016-02-10  0:37   ` Jonathan Nieder
2016-02-10  2:26   ` Jacob Keller
2016-02-10 17:49     ` Stefan Beller
2016-02-11  7:46       ` Jacob Keller
2016-02-09 20:54 ` [PATCHv9 5/6] submodule update: expose parallelism to the user Stefan Beller
2016-02-09 20:54 ` [PATCHv9 6/6] clone: allow an explicit argument for parallel submodule clones Stefan Beller
2016-02-09 21:39 ` [PATCHv9 0/6] Expose submodule parallelism to the user Junio C Hamano
2016-02-09 21:46   ` Stefan Beller
2016-02-09 22:03     ` Junio C Hamano [this message]
2016-02-11 20:23       ` Junio C Hamano
2016-02-11 20:28         ` Junio C Hamano
2016-02-11 20:33         ` 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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqziv91qzi.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox.com \
    --cc=Jens.Lehmann@web.de \
    --cc=git@vger.kernel.org \
    --cc=jrnieder@gmail.com \
    --cc=sbeller@google.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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.