Skip to main content

Module pull_isolation

Module pull_isolation 

Source
Expand description

A pull that merges, read as its fetch and its merge of FETCH_HEAD. What: A git pull that merges, turned into the fetch it starts with and the git merge FETCH_HEAD it ends with, so the merge half goes through the same isolated merge as a typed git merge. Why: Native Git’s git pull runs its merge as a child of Git (builtin/pull.c, run_merge, cmd.git_cmd = 1), so the wrapper never saw it and the merge kept native Git’s failures: a staged index, a held index.lock, a late ref update. The owner’s rules are “Auto merging should never fail.” and “Manual merge should never fail too.”; the pull’s own decisions (which options, whether it rebases, whether HEAD moved under the fetch, how many heads FETCH_HEAD holds) are mirrored here only where they can be mirrored exactly, and every other pull is left to native Git.

In TS you’d write (pseudocode):

const plan = planPull(region); // undefined for anything not read exactly
if (plan && mergeIsStated(plan, config)) { await fetch(plan); return merge(['--no-edit', 'FETCH_HEAD']); }
return nativePull();

Structs§

PullPlan
What: What a pull reads from its command line: the arguments of its fetch, of its merge, and where the choice of merging was stated. Why: The two halves of a pull take different options, and a pull merges only when the command line or the settings say so.

Enums§

PullStep
What: How a pull is handled: native Git’s whole, already ended, or the merge that follows its fetch. Why: The caller either forwards the pull unchanged, returns the end, or runs the merge forward it is given.

Functions§

merge_is_stated
What: Whether the command line and the settings state that this pull merges and mirror nothing else the pull would do. Why: Git’s pull merges when --no-rebase is typed or pull.rebase / branch.<name>.rebase say no, or, with neither set, when a way of reconciling is typed (--ff, --no-ff); with nothing stated it refuses divergent branches with its advice, and that refusal stays native Git’s. pull.ff is left to Git, because with --no-rebase it is rewritten by rules of its own.
plan_pull
What: Read the arguments after pull, by exact spelling, or nothing when any of them is not read exactly. Why: Git accepts unambiguous abbreviations and options this does not mirror (--rebase, --ff-only, -s, -X, --autostash, --dry-run, --recurse-submodules); a pull with one of them is native Git’s whole, and so is a refspec that could move the checked-out branch (it holds a colon).
pull_step
What: Decide what to do with a git pull, and run its fetch when the merge half can be completed here; real_index is the index the working tree update waits on. Why: Everything before the fetch decides from the command line, the settings and the repository’s state, so a pull this cannot mirror starts nothing; after the fetch, a FETCH_HEAD that does not list exactly one head goes back to native Git’s whole pull, which fetches again and words the refusal itself.