René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Race condition in multithreading environment due to usage of os.chdir","articleBody":"Hi, \r\n\r\nI recently ran into a race condition when using two different instances of `git.Repo` objects in two different threads. \r\n\r\nInside `repo.index.add()`, some functions are decorated with the `git_working_dir` decorator. This decorator changes the process working directory to the one of repository, performs some system calls, then returns the working dir back to the initial value. \r\n\r\nIf two threads perform `repo.index.add()`, even on two independent `Repo()` objects, the working directory of the entire process could be permanently modified. Moreover, system calls done by `index.add()` may fail. For example `lstat()` will be executed with a relative file name assuming a wrong absolute path.\r\n\r\nFor example: \r\n1. working dir (wd) is /home/user\r\n2. git_working_dir is entered in thread 1. (/home/user is registered, wd changed to /repo1)\r\n3. git_working_dir is entered in thread 2. (/repo1 is registered, wd changed to /repo2)\r\n4. git_working_dir is exited in thread 1. (wd restored to /home/user)\r\n5. git_working_dir is exited in thread 2. (wd restored to /repo1)\r\nnow the process wd is /repo1\r\n\r\nI believe I could work around this issue by creating git object directly rather than adding to the index then committing, but I thought you may be interested to know about the issue. \r\n\r\nRadu\r\n\r\n","author":{"url":"https://github.com/rcarpa","@type":"Person","name":"rcarpa"},"datePublished":"2020-09-02T07:15:39.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":4},"url":"https://github.com/1052/GitPython/issues/1052"}