On Sun, Oct 25, 2020 at 11:02:03PM +0000, brian m. carlson wrote: > > A script I'm writing performs a succession of porcelain commands to > > create a commit in a bare git repository: > > > > git hash-object > > git mktree > > git commit-tree > > git update-ref > > > > Do I need to manage external locking around these commands to avoid any > > concurrency problems, or will git take care of that? > > I'm almost certain that Git will do the same locking and object creation > semantics that it does in porcelain commands as in the plumbing commands > you're using. For example, I happen to know that all loose object > creation goes through one function, which should gracefully handle > concurrent accesses. Git is in general safe against concurrent accesses > and is designed not to lose or corrupt data in this case. > > However, I will point out that ref updates may conflict and if so, Git > will fail instead of waiting. So while your repository will remain > consistent and won't experience corruption, that doesn't mean that all > operations will complete successfully. Some sort of retry mechanism or > other error handling will probably be warranted. Thanks for your advice. I think in this case it's easier to just use simple locking to make sure that concurrent processes don't step on each-other's toes. Best regards, -K
