Module lfs_pointer_scan 

The LFS objects a push introduces, found in process from the commits to be pushed. What: The LFS objects a push introduces, found in process: the pointer blobs that the commits to be pushed add. Why: git-lfs push starts a scanner (git rev-list, git cat-file, git ls-remote) and, when it finds anything, asks the LFS server about it; most pushes add no pointer at all, so the wrapper reads the commits itself with the in-process readers and starts git-lfs only when a pointer is found. The commits are those reachable from the pushed tips and not reached before a known-good tip (the remote’s tracking refs, when they describe the destination). Every commit is compared with each of its parents, so a pointer added in one commit and removed in the next is still found. Anything the readers do not fully understand, and any walk that grows past its limits, returns None, so the caller asks git-lfs.

In TS you’d write (pseudocode):

const oids = newPointerObjects(odb, format, includeTips, stopTips, limits); // undefined: ask git-lfs

Constants

MAX_COMMITS

The most commits one scan visits before it gives the question to git-lfs.

SCAN_BUDGET

The longest one scan runs before it gives the question to git-lfs.

Functions

new_pointer_objects

What: The names of the LFS objects that the commits reachable from include and not from stop introduce, sorted, or None when the readers cannot answer. Why: The walk follows parents from the tips and does not cross a commit named in stop. A pointer counts when its blob is not what a parent holds at the same path, for every parent of a merge, so an object that exists anywhere in the pushed history is found once. A root commit is compared with an empty tree. Every blob read is decoded like git-lfs decodes it (lfs_pointer); a read that fails, a malformed tree, a missing parent (a shallow clone) or a walk past MAX_COMMITS or SCAN_BUDGET declines.