Skip to content

repo.index.add() method attempts to chmod files which it should not #2021

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
jrollins opened this issue Apr 7, 2025 · 2 comments
Open

Comments

@jrollins
Copy link

jrollins commented Apr 7, 2025

The behavior of the repo.index.add() method behaves differently than the CLI equivalent git add:

0$ git add *
0$ python3 -c 'import git; git.Repo.init().git.add("*")'
0$ python3 -c 'import git; git.Repo.init().index.add("*")'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/opt/conda/base/envs/cds/lib/python3.10/site-packages/git/index/base.py", line 885, in add
    entries_added.extend(self._entries_for_paths(paths, path_rewriter, fprogress, entries))
  File "/opt/conda/base/envs/cds/lib/python3.10/site-packages/git/util.py", line 176, in wrapper
    return func(self, *args, **kwargs)
  File "/opt/conda/base/envs/cds/lib/python3.10/site-packages/git/index/util.py", line 111, in set_git_working_dir
    return func(self, *args, **kwargs)
  File "/opt/conda/base/envs/cds/lib/python3.10/site-packages/git/index/base.py", line 745, in _entries_for_paths
    entries_added.append(self._store_path(filepath, fprogress))
  File "/opt/conda/base/envs/cds/lib/python3.10/site-packages/git/index/base.py", line 698, in _store_path
    istream = self.repo.odb.store(IStream(Blob.type, st.st_size, stream))
  File "/opt/conda/base/envs/cds/lib/python3.10/site-packages/gitdb/db/loose.py", line 233, in store
    chmod(obj_path, self.new_objects_mode)
PermissionError: [Errno 1] Operation not permitted: '/path/to/repo/.git/objects/02/60b9d2b53981a5ddbe20f3f0aae350b2806d22'
1$ 

I don't see any reason that the python-native methods should be doing anything different than what the CLI does.

@Byron
Copy link
Member

Byron commented Apr 8, 2025

I totally agree - this was from a time when GitPython strived to implement Git independently. In retrospect, this was totally ill-advised, but here we are.
It's probably not too difficult to make this works by doing bare git calls.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

3 participants
@Byron @jrollins and others