From: Junio C Hamano <gitster@pobox.com>
To: Derrick Stolee <derrickstolee@github.com>
Cc: "Elijah Newren" <newren@gmail.com>,
"ZheNing Hu" <adlternative@gmail.com>,
"Emily Shaffer" <emilyshaffer@google.com>,
"Git List" <git@vger.kernel.org>,
"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
"Johannes Schindelin" <Johannes.Schindelin@gmx.de>,
"Victoria Dye" <vdye@github.com>
Subject: Re: Question relate to collaboration on git monorepo
Date: Fri, 23 Sep 2022 08:46:53 -0700 [thread overview]
Message-ID: <xmqqzgeqw0sy.fsf@gitster.g> (raw)
In-Reply-To: <1c2f6cfe-a6db-c06e-5313-f5b31be42c8d@github.com> (Derrick Stolee's message of "Thu, 22 Sep 2022 10:24:57 -0400")
Derrick Stolee <derrickstolee@github.com> writes:
> On 9/21/2022 7:36 PM, Elijah Newren wrote:
>> On Wed, Sep 21, 2022 at 8:22 AM ZheNing Hu <adlternative@gmail.com> wrote:
>
>> Here, we do have an object download, which occurred after the merge
>> completed, so there must be something happening after the merge which
>> needs the extra blob; if we keep reading...
>>
>>> project1/file1 | 10 ++++++++++
>>> 1 file changed, 10 insertions(+)
>>
>> Ah, the 'helpful' diffstat. It downloads blobs from a promisor remote
>> just so we can see what has changed, including in the area of the
>> project we don't care about.
>> ...
> This is an interesting find! I wonder how many people are hitting this
> in the wild. Perhaps merge.stat should be added to the optional, but
> recommended config options in scalar.c.
Hmph. It somehow sounds like throwing the baby out with the
bathwater, doesn't it.
You are only interested in a few directories in the project. You
pull from somebody else (or the central repository), and end up
getting updates to both inside and outside the areas of your
interest.
As a project gets larger and better modularized, does it become more
likely that such an update will happen more often?
I am very tempted to suggest that the diffstat after a merge in such
a project should use the sparse cone(s) as pathspec. Disabling the
"what happened in this merge" report altogether is a way too blunt
instrument, isn't it?
next prev parent reply other threads:[~2022-09-23 15:47 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-20 12:42 Question relate to collaboration on git monorepo ZheNing Hu
2022-09-20 18:53 ` Emily Shaffer
2022-09-21 15:22 ` ZheNing Hu
2022-09-21 23:36 ` Elijah Newren
2022-09-22 14:24 ` Derrick Stolee
2022-09-22 15:20 ` Emily Shaffer
2022-09-23 2:08 ` Elijah Newren
2022-09-23 15:46 ` Junio C Hamano [this message]
2022-09-23 18:11 ` Derrick Stolee
2022-09-23 14:31 ` ZheNing Hu
2022-09-21 1:47 ` Elijah Newren
2022-09-21 15:42 ` ZheNing Hu
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=xmqqzgeqw0sy.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=adlternative@gmail.com \
--cc=avarab@gmail.com \
--cc=derrickstolee@github.com \
--cc=emilyshaffer@google.com \
--cc=git@vger.kernel.org \
--cc=newren@gmail.com \
--cc=vdye@github.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.