sveltekit needs to actually set the cookie headers etc. if credentials is true

I don't know how much workaround is it, but for now I'm using this approach:

This is a blocker for me as well, as I don't really understand how to interact with my backend while it's not implemented within sveltekit and uses cookie-based authentication.

This way I'm able to pass cookie back and forth, so this code kind of works:

'set-cookie': response.headers.get('set-cookie')

That said, third party cookies are subject to privacy concerns and are blocked by both browser extensions and even by some browsers themselves, so they shouldn't be relied upon.

If you do need to passthrough your mydomain.com cookies to a thirdparty.com domain, you can technically already do that now by implementing it as an endpoint and calling fetch('/my-endpoint')

I don't really want to re-implement all of my api endpoints to make this work. Is there a way to "mask" the thirdparty endpoints to pass through the cookies?

We need to be really careful about what's 'same origin' because the server has no idea what host/path the various cookies are associated with. It just has a list of cookies that the browser had determined to be relevant for this SSR'd page, and not for any other subrequests.

If you return a Promise from load, SvelteKit will delay rendering until the promise resolves.

should not reference any API keys or secrets, which will be exposed to the client

should run on the same domain as any upstream API servers requiring credentials

When fetch runs on the server, the resulting response will be serialized and inlined into the rendered HTML. This allows the subsequent client-side load to access identical data immediately without an additional network request.

graphqlSync is a relatively recent addition to GraphQL.js that lets you execute a query that you know is going to return synchronously and get the result right away, rather than getting a promise. Since we know that introspection won’t require calling any asynchronous resources, we can safely use it here.

o help us meet this vision, the frontend should use GraphQL in preference to the REST API for new features.

We want the GraphQL API to be the primary means of interacting programmatically with GitLab. To achieve this, it needs full coverage - anything possible in the REST API should also be possible in the GraphQL API.

shouldn't be a just URL it should be for recourceId

Thanks, @Kapsonfire-DE for better understanding the original issue.

Worth noting that in the case where you're proxying /api/ requests to an external server in nginx you can easily do this in handle today:

I've been thinking more about how to best do this. The preferred way might be to use the same domain and have an application load balancer like nginx split traffic on the URL path (e.g. /api). This is for two reasons. Firstly, you might not necessarily want to cookie the primary/apex domain and have the cookie shared across all subdomains. You also might not want to do CORS because preflight requests add latency and CORS adds complication.

contact the API layer using internal DNS hostname of the API service for better latency. It can go straight to the application load balancer instead of passing through the external load balancer first

would be different depending on whether the fetch is internal or external

A litmus test on whether an option belongs to adapter config or kit config, would be to ask whether the option becomes irrelevant when you switch the adapter to static.

export function get(req, res) { if (req.headers.authorization) { res.writeHead(200); res.end(JSON.stringify({ message: req.headers.authorization })); } else { res.writeHead(200); res.end(JSON.stringify({ message: 'unauthorized' })); } }

Closing as kit will be serverless first!

Allows you to use sapper with an API service residing in another server. This is especially useful if your API server is written in another language

The fetch function passed to load functions is a separate wrapper around the global fetch function that's being discussed here.

There's no need to pass fetch in as it's globally available inside a SvelteKit app (along with Response, Request and Headers).

globalThis.fetch = fetch;
globalThis.Response = Response;
globalThis.Request = Request;
globalThis.Headers = Headers;

Prettier intentionally doesn’t support any kind of global configuration. This is to make sure that when a project is copied to another computer, Prettier’s behavior stays the same. Otherwise, Prettier wouldn’t be able to guarantee that everybody in a team gets the same consistent results.

Almost the same applies to typescript and babel-ts. babel-ts might support JavaScript features (proposals) not yet supported by TypeScript, but it’s less permissive when it comes to invalid code and less battle-tested than the typescript parser.

while (( "$#" )); do case "$1" in -a|--my-boolean-flag) MY_FLAG=0 shift ;; -b|--my-flag-with-argument) if [ -n "$2" ] && [ ${2:0:1} != "-" ]; then MY_FLAG_ARG=$2 shift 2 else echo "Error: Argument for $1 is missing" >&2 exit 1 fi ;; -*|--*=) # unsupported flags echo "Error: Unsupported flag $1" >&2 exit 1 ;; *) # preserve positional arguments PARAMS="$PARAMS $1" shift ;; esacdone# set positional arguments in their proper placeeval set -- "$PARAMS"

As it turns out, it’s pretty easy to write your own arg parser once you understand the mechanics of the language. Doing so affords you the ability to cast all manner of spells to bend arguments to your will.

As a general rule: You should quote everything (that may be quoted).

Normally, git diff looks for non-printable characters in the files and if it looks like the file is likely to be a binary file, it refuses to show the difference. The rationale for that is binary file diffs are not likely to be human readable and will probably mess up your terminal if displayed. However, you can instruct git diff to always treat files as text using the --text option. You can specify this for one diff command: git diff --text HEAD HEAD^ file.txt You can make Git always use this option by setting up a .gitattributes file that contains: file.txt diff

What is that npx thing? npx ships with npm and lets you run locally installed tools. We’ll leave off the npx part for brevity throughout the rest of this file! Note: If you forget to install Prettier first, npx will temporarily download the latest version. That’s not a good idea when using Prettier, because we change how code is formatted in each release! It’s important to have a locked down version of Prettier in your package.json. And it’s faster, too.

fetch: fetcher

if (parsed.protocol) { // external fetch response = await fetch(parsed.href, /** @type {import('node-fetch').RequestInit} */ (opts)); } else { // otherwise we're dealing with an internal fetch const resolved = resolve(request.path, parsed.pathname);

We implemented isomorphic fetching (i.e. fetching with the browser's implementation on the client and node-fetch on the server)

we can detect if the user is making a call with only the path specified or if they have a fully specified URL with domain name.

wanted to surface to the user during SSR if the client-side call would likely fail due to cross-origin fetching, credentials, etc.

You can see the implementation here: https://github.com/sveltejs/sapper/blob/339c417b24e8429d3adc9c9f196bf159a5fce874/runtime/src/server/middleware/get_page_handler.ts#L137

fetch: (url: string, opts?: any)

No it doesn't. I've simply told SvelteKit to ignore the type error from credentials missing. If there's some other issue or missing feature it's not blocked by this. That being said, I wouldn't mind getting this change in

If you are working on a codebase within which you lint non-TypeScript code (i.e. .js/.jsx), you should ensure that you should use ESLint overrides to only enable the rule on .ts/.tsx files. If you don't, then you will get unfixable lint errors reported within .js/.jsx files.

Consider using this rule in place of no-untyped-public-signature which has been deprecated.

Explicit types for function return values and arguments makes it clear to any calling code what is the module boundary's input and output.

To set multiple cookies in a single set of response headers, you can return an array:

The job of this function is to return a { status, headers, body } object representing the response, where status is an HTTP status code: 2xx — successful response (default is 200) 3xx — redirection (should be accompanied by a location header) 4xx — client error 5xx — server error

For dynamic routes, such as our src/routes/blog/[slug].svelte example, that's not enough. In order to render the blog post, we need to fetch the data for it, and we can't do that until we know what slug is. In the worst case, that could cause lag as the browser waits for the data to come back from the server. We can mitigate that by prefetching the data. Adding a sveltekit:prefetch attribute to a link... <a sveltekit:prefetch href="blog/what-is-sveltekit">What is SvelteKit?</a> ...will cause SvelteKit to run the page's load function as soon as the user hovers over the link (on a desktop) or touches it (on mobile), rather than waiting for the click event to trigger navigation. Typically, this buys us an extra couple of hundred milliseconds, which is the difference between a user interface that feels laggy, and one that feels snappy.

By default, the SvelteKit runtime intercepts clicks on <a> elements and bypasses the normal browser navigation for relative (same-origin) URLs that match one of your page routes. We sometimes need to tell SvelteKit that certain links need to be handled by normal browser navigation.

This function runs on every request, for both pages and endpoints, and determines the response. It receives the request object and a function called resolve, which invokes SvelteKit's router and generates a response accordingly.

This allows you to modify response headers or bodies, or bypass SvelteKit entirely

plus authorization if it's not explicitly provided, to a fetch request that happens inside load to an internal endpoint

import '@sveltejs/kit/install-fetch';

Adapters are required to make Request globally available if it isn't already part of the target platform. It's part of the (currently undocumented) contract — see e.g. adapter-node

for internal case you can have endpoint call instead true request. Basically, it's has sense only for external API.

CSR asking my Python backed directly (over nginx). Basically, in my particular situation, I want to use most shorter paths for SSR or CSR cases when I have a separate API server under the same domain and nginx frontend.

on CSR it connects to the svelte-kit endpoint which just use a localhost connection. and to optimize this you can use unix sockets in your endpoints to connect to backend server

I don't want to use an extra proxy, it's the wrong architecture design that killed performance.

ah you are talking about a external api endpoint server? then you could use the svelte-kit endpoints as proxy handler

I want to avoid nginx overhead (especially if they have tons of alias and rewrites) for in-server communication. Basically, you can have sveltekit server, backend server and nginx server, in that case, communicate inside your internal network will be very expensive like: browser->nginx server(10.0.0.1)->sveltekit server(10.0.0.3)->nginx server(10.0.0.1)->backend server(10.0.0.2) instead just: browser->nginx server(10.0.0.1)->sveltekit server(10.0.0.3)->backend server(10.0.0.2)

(name subject to bikeshedding)

We certainly wouldn't want to add non-standard appendages to the fetch API, partly because it's confusing but mostly because it would be repetitious; you would need to include that logic in every load function that used the API in question.

Stay engaged. As mentioned above, you are expected to check your GVSU email twice daily, read new posts on CampusWire twice daily, contribute to the discussion board daily, and make at least two significant contributions to CampusWire per week. Make daily engagement with the course a habit, and don’t take days off (unless it’s a weekend and you have all your work done).

Budget your time. MTH 124 is a 5-credit course with no meetings, so you will need to plan on spending about 15-20 hours per week doing mindful work. That’s 3-4 hours per weekday if you choose not to work on weekends. If you are taking other courses or have job of family responsibilities, you’ll need to think about where to put these hours in your daily and weekly schedules. In my experience, the #1 reason students don’t succeed in online courses is overcommitment and not managing time well.

First of all, I would start off presenting yourself: Dear XYZ support team I am the web developer in charge of example.com website. By presenting you this way, you are establishing the frame to treat you, hinting that you should be presupposed to be somewhat proficient, so they could choose to answer in a more technical detail.

Consider that many customers are rude or arrogant, so you can safely brag a little and still come off as comparatively wonderful! Help them help you with that short brag and they'll only be appreciative. And remember: be nice and it's ok to lose the modesty for a sentence or two! Source: I'm a CS rep at a tech company, and I appreciate it when savvy customers clue me into it!

No need to apologize. The bold "be nice" and 'limit your bragging to a sentence or two' clarifies your tone perfectly

Feel free to hint, brag, or both! The best CS reps should easily take a hint from clear language and a signature like John Appleseed, JavaScript/Ruby Developer, but any will catch on with a simple line like "I know what I'm doing, so I'd appreciate an extra-technical explanation!"

any will catch on with a simple line like "I know what I'm doing, so I'd appreciate an extra-technical explanation!"

One solution that fixed this issue with my ISP was that when I went through the first and second line and got in touch with the people that fixed my problem, I asked them if they could give me one of their personal numbers in case the same problem happened again. The problem did occur a couple more times, and I just directly called the same guy.

If you're already an admin for the zone in question, then the proper way to get that information is to log on to the DNS server or DNS control console and read it right from there. If you're not an admin for the zone, you're not supposed to have that information. Note that the person you are talking to on the phone is almost certainly not a DNS zone admin, so they also should not have that information. If they somehow did have it, they definitely shouldn't give it out over the phone. This is for your protection.

DNS zone information is sensitive. Many years ago it was possible for anyone to query a DNS server and literally get back all the records at once, but that was a security issue. Now you have to be an admin for the zone to get that info.

One way to look at your current situation is that you're not paying them enough to tell you the gory details, not that you're not knowledgeable enough.

If the hosting company (or any organization that you're trying to get support from) wanted you to know something, they would have already told you or made that information available.

If you choose to say 'I already told you that' {4} then your tone of voice is critical. If you say the above in a snarky/belittling tone the rep isn't going to want to help you. And that does matter. Smile between each response - especially if you are tired or annoyed.

Hey, I'm a PhD in [field] and do [whatever] professionally. Before calling you, I've narrowed down the problem to [something on their end], so that's what needs to be addressed. If I could speak to an engineer about [specific problem], that'd be great; but if we've gotta walk through the script, let's just knock it out quickly. If they end up requiring the script, then the best way to use your expertise is to run through it quickly. Keep the chit-chat to a minimum and just do the stuff efficiently. If they start describing how to perform some step, you might interrupt them with, "Got it, just a sec.", then let them know once you're ready for the next step.

With experience you would get to have an idea about how knowledgeable the customer was just by talking to them for a few seconds, but you have to be careful not to assume things.

Nowadays when I want technical support I will email my web host and give them all the necessary information, i.e. what I have tried to do to resolve, what I think the problem is etc and usually it is fixed first time within a few hours. If I need urgent assistance I will ring them but 99% of the time email is sufficient and less stressful, rarely do I need to send a second email.

Companies do tend to use scripts but the good ones will allow their staff to stray off the script once they are experienced enough to do so as long as it benefits the customer and the company, usually this involves fixing the problem more quickly.

My advice is if you are looking for a quick and accurate answer ask to have the trouble ticket elevated immediately and to speak with an engineer that will recognize your knowledge and speak with you on your level.

Stack-exchange is not teaching or education. It's just giving out answers for upvotes. Just like some tech support is about closing tickets.

Some people, regardless of their experience level are horrible as teachers. A school teacher gets asked the same question every year. Every year they answer them, even if it seems redundant, and the answers are simple to THEM. Teaching requires patience and the acceptance of being asked "dumb questions" repeatedly. If they cannot handle that, then they should simply not teach or pretend to be a teacher.

You must understand that tech support constantly gets bombarded by calls from people who refuse to learn or accept genuine solutions.

Furthermore many of them are paid or rated by the number of tickets they close, not solutions. It's a bad recipe and unfortunately it has become the norm.

I typically request to speak with an engineer when I find myself detecting an inexperienced support person.

I find most tech support is filled with inexperienced and frustrated staff who just run off a script. They're not paid well. They are Tier One support to filter out most of the incoming calls. Tech support is designed in tiers.

However, what speaks against just straight up telling them that you're working as [Insert title of your position] and you know what you're talking about?

tweet at them. This has multiple effects: If they don't respond, it's bad PR

And asking them if they think they know what they are doing will not help, because many people will overestimate their knowledge, making the support even more complicated as the tech guy may at first believe them and only find out later that they told wrong things because they do not actually know what they are pretending to know.

Of course, if you're too successful with migrating all your clients and friends to your friendly small provider it grows into a big provider and needs to hire cheap first level support to deal with all the customers ;-)

Heisenberg for customer support quality ;-)

The best advice I can give you is: Seek a smaller provider which often are less formal and more approachable. When you found one where you have a good support, request your friends and family to move to this. You are doing something for them, then it can only happen on your terms.

If the person answering the call misses something, nothing prevents them from asking you to repeat something. I think the key point that should be added to this answer is to not sound or act annoyed if the support tech asks for something you've already rattled off. To accept that you gave them a whole bunch of information at once, and that they might legitimately have missed or forgot one bit of it. Or, especially if you know the order in which they ask these questions, to take it slower; don't say it all in five seconds, take half a minute. Give them time to click!

Tech support works with scripts. Just get to know these scripts by heart and answer all questions from the script you can in one long sentence, before they ask it. Like in "Hi I have a problem with this and that...I have restarted the router, I have checked the cables, the red light is on, the green light is off, not other lights are blinking......etc.etc.etc. That way the person at the other end of the line can just go click-click-click and you'll be 10 steps further in their script in 5 seconds.

So what can you do to demonstrate your technical knowledge? Well, you are doing the right thing by using the correct technical terms. That will give an indication to the person handling the ticket. Explicitly explaining your role as the administrator or developer should also help.

From experience I can say that professionals will be more forgiving if you go through things at a basic level than amateurs who have no idea what you're talking about, so people will probably err on the side of caution and not assume the customer has a high level of expertise.

"Put as much information about the problem itself into the email". This is where you show your ability to know what is important and relevant and establish your technical level. Don't be brief, don't imply, and break it down Barney style so the person receiving it knows to escalate your ticket.

Look for certain questions that have been asked every time, and put those answers into the initial email you send about the new problem. Try to add things that make the potential problem sound local. The more information you give them that you know they will be asking for in their script, the faster you will get someone who can help you. And they will thank you for it.

If you email helpdesk (us specifically), if you use appropriate technical detail you will probably get someone who knows what they're doing, and will greatly appreciate it. If you call, you will get me only. I will ask you lots of questions, with awkward pauses in between while I write my notes, and at the end of it I probably won't be able to help you. Technical detail is still welcome, but there are some questions I will ask you anyway even if they sound useless to you

Put as much information about the problem itself into the email, within reason. No need to write a paragraph, that takes time away from you and from us. Bullet points are perfect (preferred).

And if your answers tell me it's something too advanced for me, only then would I escalate it.

e-mailing

Calling over e-mailing has a number of advantages, you're able to empathize with the person and they're able to hear how comfortable you are with the topic over the phone.

because you display knowledge of the field naturally and you also show them you know how system administration in general works

So, +1 for play ball. Level 1 is supposed to filter out all simple issues (and once upon a time, you'll have forgotten something, happens to all of us), and they are not supposed to be creative. They get a script that has been refined over and over. Learn the scripts, prepare the answers, and you'll get to Level 2 more quickly than with any other method.

In one of my internship, I got to befriend a level 2 tech support, so learned a couple thing of how it worked (in that company). Level 1 was out-sourced, and they had a script to go from, regularly updated. From statistics, this took care of 90% of issues. Level 2 was a double handful of tech people, they had basic troubleshooting tools and knowledge and would solve 90% of the remaining issues. Level 3 was the engineering department (where I was), and as a result of level 1 and 2 efficiency less than 1% of issues ever got escalated. The process worked!

OP is referring to letting people know they can speak like proper adults when talking about technical terms, without going through the usual nanny-like discourse that tech support has to provide to non-techies. For instance, it happened to me with Amazon support. The speaker told me exactly where to touch in order to clear the cache of the Android Amazon App Store. Given that I work as an app developer the guy could have just said "please clear the cache". No need to go through "tap here, then here, now you should see this, tap that"...

the problem is that I write a lot of these emails and they are a waste of my and everyone elses time

Please don't write answers in comments; we have a policy against this. If you have an answer to the question, write it up as an answer. Thanks.

If possible I'd like to avoid writing my academic and professional titles in my email signature as this might be seen as "showing off".

I have tried different tactics of showing the tech support that I am proficient in their field of work (I work as a web developer). Specifically: using accurate terms and technologies to show my knowledge of them and telling the support that I am the "administrator" of the website in question.

How to let tech support subtly know that I am proficient without showing off?

Unfortunately the tech support people you are speaking to are probably as frustrated as you are at having to go through the basic stuff with you.

Large companies especially deal with the massive volume of tech support calls they receive by employing some staff on lower pay as a "buffer," dealing with simple or "known" issues so that they don't need to employ as many higher paid "second line" support staff.

Very often the first people you get through to on tech support lines are reading from a script.

They have to ask you the dumb questions, either because their employer demands they do, or sometimes because their computer system doesn't let them get to the next part of the script unless they play ball.

Which is not to say that people employed on first line support are not knowledgeable; in my experience lots of over-qualified people have to take less advanced jobs in IT just to get into the industry.

Another will employ smart people who apologise to you profusely for having to go through all the pointless steps, but that's just what they have to do!

However I appreciate that price and functionality often dictates who we deal with.

So my best advice if you need to stick with them is just to expect the treatment you have become used to and 'play along'. Actually, I find some things often run smoother when you act dumber than you are.

Historically, the uncertainty principle has been confused[5][6] with a related effect in physics, called the observer effect, which notes that measurements of certain systems cannot be made without affecting the system, that is, without changing something in a system.

the uncertainty principle actually states a fundamental property of quantum systems and is not a statement about the observational success of current technology.

Such variable pairs are known as complementary variables or canonically conjugate variables

I would argue though that crashing is better than quietly providing unexpected behavior.

Non-solutions Start replacing process.env[ with ({})[ if you're sadistic

This looks cool but right now, let's say i have an external api which depends on users cookies, the cookies only gets send through internal sk endpoints while ssr even if its the same domain. Couldn't we pass the 'server' request to the serverFetch hook? I would currently have to patch package svelte kit to pass request headers to the external api or create an sk endpoint which proxies the request.

also it's can be helpful for geo deploying when your browser should get access to closest API by GeoDNS but server part can touch neighborhood server or same server.

Skirmish mode, where the original game did great, this version lacks a bit of content. For instance, in the original game you could give your CPU (AI) players a name, so you could for instance relive the Avernii vs the XII Legion or anything for that matter. In the remasterd version you can't name any CPU players, which in my opinion is a loss. A lot of the skirmish fun was with the immersion of the factions.

Due to the cost and complexity of VAT/GST, Frozen Soul Games won't be able to register within each country. VAT/GST will be due upon pick-up after we ship to you. Thank you for your understanding.

Unfortunately one can only buy the standard or the soundtrack version, without any chance to upgrade, to buy the DLC extra. In this case I can only say if you get the game on a good sale (75 percent or more) and collect music, or if you want to support the developer, you might want the soundtrack edition.

I cherry-picked the first commit into #872, we can add .erb support later if we find we need it.

Although I don't use it much, I certainly don't plan to break it!

Because constants in Ruby aren't meant to be changed, Ruby discourages you from assigning to them in parts of code which might get executed more than once, such as inside methods.

It doesn't say that the constant is dynamic. It says that the assignment is dynamic.

git diff --relative will print paths from the dir you are in.

I've been using (and recently, contributing slightly to) Git for well over a decade. I don't have any single thing I'd specifically recommend at this point, but if you're looking for a decent book on Git, the Pro Git book has a bunch of plus-es: it's on line and kept up to date, it's free, and it's correct (unlike far too many online tutorials). There is also Think Like (a) Git, which covers most of what's missing from Pro Git.

$ ed - var.c << end > 0a > xxx > . > wq > end

If you would like to make a code change, go ahead. Fork the repository, open a pull request. Do this early, and talk about the change you want to make. Maybe we can work together on it.

Local development and testing has huge advantages, but sometimes one needs to test web applications against their real-world domain name. Editing /etc/hosts is a pain however, and error prone. Node Foreman can start up an HTTP forward proxy which your browser can route requests through. The forward proxy will intercept requests based on domain name, and route them to the local application.

For users with Google Chrome, this can be paired with FelisCatus SwitchyOmega for great results.

nf start -j Procfile.dev

this is incomplete. Yes you get a load of commits, but they no longer refer to the right paths. git log dir-B/somefile won't show anything except the one merge. See Greg Hewgill's answer references this important issue.

kdiff3 can be used solely with keyboard, so 5 conflict file takes when reading the code just few minutes.

If you're wondering, to insert a <tab> in osx, you need to Ctrl-V <tab>

I think so...I actually can't remember. I've used this script quite a bit.

Thanks. Worked for me. I needed to move the merged directory into a sub-folder so after following the above steps I simply used git mv source-dir/ dest/new-source-dir

--ignore-unmatch

https://github.com/reaxis/mu µ

Are you also tired and fed up with the bulkiness of jQuery, but also don't want to have to type document.querySelector("div").appendChild(document.createTextNode("hello")); just to add some text to an element?

µ

Before we dive into the details of the actual migration, let’s discuss the theory behind it.

Seamless transitions; changes made to the old repositories after they were migrated must be imported to the new monorepository.

Preserving history; we often find ourselves using the git blame tool to discover why a certain change was made.

Our requirements:

A transition period rather than Stop-The-World migration; we want to merge in a few repositories per day, with minimal disruption to work-flow.

The implicit dependencies between different versions of different services were not expressed anywhere, which led to various problems in building, continuous integration, and, notably, repeatable builds.

Preserving commit hashes; we use commit hashes in binary names and our issue tracker; ideally, these references remain intact.

You may want to try putting the one-liner (everything in the single quotes) in an actual script, with a bash shebang line. I think filter-branch is probably trying to run this in sh, not bash.

git push -b

       git push [--all | --mirror | --tags] [--follow-tags] [--atomic] [-n | --dry-run] [--receive-pack=<git-receive-pack>]
                  [--repo=<repository>] [-f | --force] [-d | --delete] [--prune] [-v | --verbose]
                  [-u | --set-upstream] [-o <string> | --push-option=<string>]
                  [--[no-]signed|--signed=(true|false|if-asked)]
                  [--force-with-lease[=<refname>[:<expect>]] [--force-if-includes]]
                  [--no-verify] [<repository> [<refspec>...]]

New changes to the old repositories can be imported into the monorepo and merged in. For example, in the above example, say repository one had a branch my_branch which continued to be developed after the migration. To pull those changes in:

Don't Stop The World: keep working in your other repositories during the migration and pull the changes into the monorepo as you go.

Maybe the source code was originally thought to be independent but was later discovered to be “rightly coupled”.

#blogumentation