From: ZheNing Hu <firstname.lastname@example.org>
To: Elijah Newren <email@example.com>
Cc: "Git List" <firstname.lastname@example.org>,
"Derrick Stolee" <email@example.com>,
"Junio C Hamano" <firstname.lastname@example.org>,
"Ævar Arnfjörð Bjarmason" <email@example.com>,
"Johannes Schindelin" <Johannes.Schindelin@gmx.de>,
"Victoria Dye" <firstname.lastname@example.org>
Subject: Re: Question relate to collaboration on git monorepo
Date: Wed, 21 Sep 2022 23:42:15 +0800 [thread overview]
Message-ID: <CAOLTT8Txre2htohUzdp6+XySkyK3-ovDx=MAbjZxjdOSPBi3Zw@mail.gmail.com> (raw)
Elijah Newren <email@example.com> 于2022年9月21日周三 09:48写道：
> On Tue, Sep 20, 2022 at 5:42 AM ZheNing Hu <firstname.lastname@example.org> wrote:
> > Hey, guys,
> > If two users of git monorepo are working on different sub project
> > /project1 and /project2 by partial-clone and sparse-checkout ,
> > if user one push first, then user two want to push too, he must
> > pull some blob which pushed by user one.
> This is not true. While user two must pull the new commit and any new
> trees pushed by user one (which will mean knowing the hashes of the
> new files), there is no need to download the actual content of the new
> files unless and until some git command is run that attempts to view
> the file's contents.
Yeah, now I understand that git fetch will not download blobs out of
the sparse-checkout pattern, but git merge will. So git pull will
download some missing blobs here.
> > The large number of interruptions in git push may be another
> > problem, if thousands of probjects are in one monorepo, and
> > no one else has any code that would conflict with me in any way,
> > but I need pull everytime? Is there a way to make improvements
> > here?
> No, you only need to pull when attempting to push back to the server.
> Further, if you're worried that the second push will fail, you could
> easily script it and put "pull --rebase && push" in a loop until it
> succeeds (I mean, you did say no one would have any conflicts). In
> fact, you could just make that a common script distributed to your
> users and tell them to run that instead of "git push" if they don't
> want to worry about manually updating.
Ah, This method looks a little funny, but it maybe can work. This
issue may also apply to some Code Review tools, maybe need
a "pull --rebase && git cr" loop.
> Now, if you have thousands of nearly fully independent subprojects and
> lots of developers for each subproject and they all commit & push
> *very* frequently, I guess you might be able to eventually get to the
> scale where you are worried there will be so much contention that the
> script will take too long. I'd be surprised if you got that far, but
> even if you did, you could easily adopt a lieutenant-like workflow
> (somewhat like the linux kernel, but even simpler given the
> independence of your projects). In such a workflow, you'd let people
> in subprojects push to their subproject fork (instead of to the "main"
> or "central" repository), and the lieutenants of the subprojects then
> periodically push work from that subproject to the main project in
Make sense. When this mono-repo really has this kind of scale,
splitting the workflow might be the right thing to do.
> I don't really see much need here for improvements, myself.
> > Here's an example of how two users constrain each other when git push.
> Did you pay attention to warnings you got along the way? In particular...
> > git clone --bare mono-repo
> You missed the following command right after your clone:
> git -C mono-repo.git config uploadpack.allowFilter true
> > # user1
> > rm -rf m1
> > git clone --filter="blob:none" --no-checkout --no-local ./mono-repo.git m1
> Since you forgot to set the important config I mentioned above, your
> command here generates the following line of output, among others:
> warning: filtering not recognized by server, ignoring
> This warning means you weren't testing partial clones, but regular
> full clones. Perhaps that was the cause of your confusion?
Oh, sorry for forget record this, I have config them globally:
Thanks for the answer,
prev parent reply other threads:[~2022-09-21 15:42 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
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 [this message]
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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 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 NNTP newsgroup(s).