What changes about a build context when it is supplied as an archive stream or a remote location instead of a local directory?
answer
- the set's author changes, not the model
- a stream is exactly what was packed
- filtering can move upstream of the builder
- fetched state excludes local edits
- some builds need no context at all
basics
~20 sThe set stops being a walk of your disk. Whoever produces the stream or whatever the builder fetches decides the contents, so local uncommitted files never participate and the ignore-rules file becomes just another file that may or may not be applied.
solid answer
~50 sWith a local directory, the set is a recursive walk of your working tree filtered by ignore rules. With a stream, the set is exactly the bytes the sender packed — the filter moved upstream to whoever produced the archive, and a rules file inside the stream is only honoured if something applies it. With a remote location, the builder assembles the context itself from what it fetches, so the set reflects the committed state and not your machine: a file you have locally but never committed is absent, which is why a build that works locally can fail remotely and vice versa. A context can also be effectively empty when a build needs no local files at all. The scoping question is the same in all three cases — who decided what crossed — and only the answer to it changes.
go deeper
The thing to hold on to is that a build always works against a fixed set of files decided up front — pointing it at a folder is just the most common way of producing that set.
Explain who authors the set in each form: the walk plus rules for a directory, the producer for a stream, the fetch for a remote location — and what that does to local uncommitted files.
Use it diagnostically. When the same build behaves differently in two places, ask which form of context each one used and what state it reflects, before suspecting the instructions.
The lever worth standardising is auditability: prefer context forms whose contents can be enumerated and justified, so that what crosses into a build is a decision on record rather than a side effect of someone's working directory.
## The invariant, and what varies The invariant is worth stating first because it survives every variation: **a build runs against a fixed set of files that was decided before the first instruction, and instructions can read only from that set.** What changes with a non-directory context is not the model but the *author* of the set. | context form | who decides the set | ignore rules | what is in it | |---|---|---|---| | a local directory | the walk, filtered by rules at that root | applied during the walk | your working tree, committed or not | | an archive stream | whoever packed the stream | only if the sender or receiver applies them | exactly the entries that were packed | | a remote location | the builder, from what it fetches | applied to what was fetched, if at all | the fetched state, never your local edits | ## An archive stream When the context arrives as a single archive stream, the builder receives entries rather than performing a walk. The consequences are direct: - **The filtering moved upstream.** Whatever produced the stream chose its contents. If that producer packed the whole tree, the fact that a rules file is sitting inside the stream does not retroactively remove anything — the rules file is just another entry unless something applies it. - **There is no "outside the path" to reach for.** The stream is the whole universe for that build, which makes the set very explicit and very easy to audit: you can enumerate it. - **It is the honest form for generated contexts.** When a process assembles exactly the files a build needs and hands them over, the set is the smallest it can be and nobody has to trust a filter. ## A remote location When the build is given a location to fetch from rather than a directory, the builder produces the context itself. The practical effects are the ones that surprise people: - **Local edits do not participate.** A file you created or changed but never published is simply not there. The classic symptom is a build that succeeds on your machine and fails elsewhere with a missing file, or the reverse — a build that succeeds remotely and fails locally because a stale local file was masking a missing one. - **The set reflects a published state**, which is usually what you want for anything reproducible, and is exactly wrong for the edit-and-try loop. - **The builder now depends on reaching that location.** That dependency has its own discipline around what a build may reach out to, which is a separate subject; here it is enough to note that the set is produced by a fetch rather than by a walk. ## An empty or near-empty context A build whose instructions need no local files at all — it starts from a base and runs steps that produce everything — has no reason to send anything. Pointing such a build at a full working tree is pure cost with no benefit, and it is one of the easiest wins available: the set goes to nothing and the packaging step disappears. ## Why an interviewer likes this question Because it separates people who learned one invocation from people who understand the model. If your mental picture is "the builder reads my folder", a streamed or fetched context is inexplicable. If your picture is "a set of files is decided, then transferred, then built against", every form is the same mechanism with a different author — and you can reason about a build you have never run, on a platform you have never used. The practical rule falls out of that: for any build, be able to answer **who decided what crossed, and can I see it?** With a local directory the answer is "the walk and the rules, and yes, by inspecting the packaged set". With a stream it is "the producer, and yes, by enumerating the entries". With a remote location it is "the fetch, and yes, by looking at what was fetched". A build whose answer is "I am not sure" is the one that is slow, leaky, or both.
- Why does a build that succeeds locally fail when the context is fetched from a remote location?Because the fetched context contains only the published state. A file that exists on your disk but was never committed is absent, so a copy instruction that worked locally has nothing to read. The reverse also happens: a stale local file can mask a deletion that the fetched context correctly reflects.
- Does shipping an ignore-rules file inside an archive stream exclude anything?Not by itself. The entries in the stream are the set; a rules file among them is just another entry unless the producer applied it while packing, or the receiver applies it on arrival. With a stream the filtering decision belongs to whoever assembled it.
saying these in an interview costs you the question
- The builder always walks a local directory; other forms do not exist.
- A rules file inside a streamed context filters it automatically.
- A fetched context still picks up your uncommitted local changes.
- Every build must be given some files, so an empty context is impossible.