sjdZddlmZddlZddlZddlZddlZddlmZddl m Z m Z ej e ZdZdZdd Zdd ddZddZdS)u0Stale git lock-file recovery for update/check paths. A crashed or killed ``git fetch`` on a shallow clone can leave ``.git/shallow.lock`` behind. Every later fetch then fails with:: fatal: Unable to create '/path/.git/shallow.lock': File exists. This wedges ``hermes update --check`` (hard failure) and silently degrades the passive banner check in :mod:`hermes_cli.banner` (the fetch is swallowed, the stale refs are compared, and the user can be told an update is available when the checkout already contains the remote tip). Git does not self-heal these lock files — they persist until a human removes them. This module provides two small, defensive helpers used by the update paths: * :func:`clear_stale_git_locks` — remove abandoned ``.git`` lock files (with an age + git-process guard so a live fetch is never yanked). * :func:`is_ancestor_of_head` — ask whether a remote tip is already contained in HEAD. Used by the shallow-clone update check to avoid reporting a false "update available" when local cherry-picks sit on top of the remote tip. ) annotationsN)Path)ListOptionaliX)z shallow.lockz index.lockz HEAD.lockzMERGE_HEAD.lockreturnboolc2 tjdkr5tjgddddj}d|vStjgdddd}|jdkS#t$r t d d Yd SwxYw) aTrue when a ``git`` process is currently running. The conservative answer on any platform we can't probe: if we can't tell, treat a lock as possibly-live and don't remove it. This is the safety check that stops us from yanking a lock a real fetch is holding. nt)tasklistz/FIzIMAGENAME eq git.exez/FOCSVT )capture_outputtexttimeoutzgit.exe)pgrepz-xgitrz1git process probe failed; assuming no git runningexc_infoF) osname subprocessrunstdoutlower returncode Exceptionloggerdebug)outs 6/home/agent/.hermes/hermes-agent/hermes_cli/gitlock.py_git_proc_runningr!0s  7d??.III#$UUWW # #n " " "4dB   ~""  HSW XXXuusAA,$A,,&BB)min_age_seconds repo_rootrr" Optional[int] List[str]cjt|dz }|sgStrtdgSt j||nt z }g}tD]}||z } |rn| j |krQ| | t|td|#t$r td|dYwxYw|S)uRemove abandoned ``.git`` lock files under ``repo_root``. A lock is removed only when BOTH conditions hold: * it is older than :data:`STALE_LOCK_MIN_AGE_SECONDS` (default), and * no ``git`` process is currently running. Returns the list of removed lock file paths. Never raises: a lock we cannot stat or unlink is skipped (a concurrently-held lock may have just been created between our age check and the unlink — the process guard makes that window vanishingly small, and skipping is always safe). z.gitz.git process running; skipping stale-lock sweepNzRemoved stale git lock %szCould not clear %s (skipping)Tr)ris_dirr!rrtimeSTALE_LOCK_MIN_AGE_SECONDS LOCK_NAMESis_filestatst_mtimeunlinkappendstrinfoOSError)r#r"git_dircutoffremovedr lock_paths r clear_stale_git_locksr7Gs?9oo&G >>    EFFF Y[[/JOOPj kFGTTdN  T  "" Dy~~'7'7'@6'I'I  """s9~~... 7CCC T T T LL8)dL S S S S S T NsBD'D0/D0revr0c tjddd|dgt|ddd}|jdkS#t$r!t d |d Yd SwxYw) uTrue when ``rev`` is an ancestor of (or equal to) HEAD. Wraps ``git merge-base --is-ancestor HEAD``. This is the correct question for update checks: a local cherry-pick on top of the remote tip makes HEAD *different* from ``origin/main`` but still *contains* it, so the answer to "is there an update?" is no. Returns False on any probe failure (missing rev, shallow boundary, git error) — callers treat that as "can't prove contained", which is the conservative direction for an update check. rz merge-basez --is-ancestorHEADTr )cwdrrrrz,merge-base --is-ancestor probe failed for %srF)rrr0rrrr)r#r8results r is_ancestor_of_headr=js  L/3 ?IdB     A%%  CSSW XXXuus58'A#"A#)rr)r#rr"r$rr%)r#rr8r0rr)__doc__ __future__rloggingrrr(pathlibrtypingrr getLogger__name__rr)r*r!r7r=r rGs,#"""""  !!!!!!!!  8 $ $ %L .PT      FrF