Module mergestate

Expand description

What state a merge is really in, for land --onto / --queue.

Two facts land must never guess at:

index.lock. git takes it to write the index and removes it when done. A git process that is killed leaves it behind, and every later index write (a merge, a commit) fails on it. A lock is stale only when no running process has the file open — checked, not assumed, on Linux through /proc/*/fd and elsewhere through lsof; when neither can tell, the lock counts as held.
Whose merge is in progress. MERGE_HEAD alone does not say that a merge was applied: git 2.39 writes MERGE_HEAD even when it could not write the merge into the index (index.lock held), leaving the index and the working tree at HEAD. Taken as “the person’s resolution”, that is a merge whose tree is ours — every change only theirs made, gone. So land records each merge it starts in <git-dir>/weave-land-merge (in-flight until it is committed; refused once land has handed it to the person to resolve). A merge in progress that land started and never finished is aborted and merged again, never judged as a resolution.

Structs§

clear_record
clear_stale_lock: Make sure no stale index.lock stands in the way. Ok(None): there is none now (a stale one was removed, and that said in out). Ok(Some(why)): a lock is held, or its holder could not be told — the caller refuses.
index_lock: The index.lock of the git dir gd.
lock_state: Look at index.lock in gd: three looks 150 ms apart, all of them with no holder and the same file, before it counts as stale.
merge_not_written: Whether git’s output from git merge says it could not write the merge (the index, the working tree): such a merge was not applied, whatever MERGE_HEAD says.
read_record
write_record