From: Elijah Newren <email@example.com>
To: ZheNing Hu <firstname.lastname@example.org>
Cc: "Git List" <email@example.com>,
"Derrick Stolee" <firstname.lastname@example.org>,
"Junio C Hamano" <email@example.com>,
"Ævar Arnfjörð Bjarmason" <firstname.lastname@example.org>,
"Johannes Schindelin" <Johannes.Schindelin@gmx.de>,
"Victoria Dye" <email@example.com>
Subject: Re: Question relate to collaboration on git monorepo
Date: Tue, 20 Sep 2022 18:47:47 -0700 [thread overview]
Message-ID: <CABPp-BHFw_Qw3d=j3awFtm2OD8WFVHSRFqYzm5Z0WQNHf-ECpA@mail.gmail.com> (raw)
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.
> 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
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.
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
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?
next prev parent reply other threads:[~2022-09-21 1:48 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 [this message]
2022-09-21 15:42 ` ZheNing Hu
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).