When adding files to repo.index with GitPython SublimeMerge is showing additional bytes in the diff

[brupelo]

Hi,

consider this initial Working Directory in SublimeMerge:

If I run $ git add -- src/version.js I'd get this Staged Files diff

So far so good, the diff is correct... if we look at the hex content of that file:

you can see crlf bytes at the end.

Now, let's unstage that file and repeat the same operation but this time using GitPython commands, if we do:

$ python
Python 3.10.1 (tags/v3.10.1:2cd268a, Dec  6 2021, 18:54:59) [MSC v.1929 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.environ["GIT_PYTHON_TRACE"] = "full"
>>> import logging
>>> logging.basicConfig(level=logging.INFO)
>>> import git
INFO:git.cmd:git version -> 0; stdout: 'git version 2.34.1.windows.1'
INFO:git.cmd:git version -> 0; stdout: 'git version 2.34.1.windows.1'
>>> repo = git.Repo(os.getcwd())
>>> reader = repo.config_reader()
>>> repo.index.add(['src\\version.js'])
[(100644, ac3cbe8dabe6dde800e2cec55763cacdcb88a918, 0, src/version.js)]
>>>

and we look now to SublimeMerge we'll see the diff of the Staged Files looks different now 🤨

What's the reason of this? I don't get it.

Could you please explain what'd be way to have the same behaviour than when doing $ git add -- src/version.js? Problem is
using this repo.index.add calls will create "wrong staged diffs".

Is this related with GitPython not being able to use the existing git config maybe?

Hope you can clarify :)

Thanks in advance!

[Byron]

Thanks for the report!

The index implementation of GitPython isn't anything I'd recommend using. It's OK to try and see if it works for a particular usecase and has any advantages over invoking git commands, but if it gives any trouble, drop it and don't look back.

There won't be a fix for this issue unless it's contributed, and I am closing this issue pre-emptively.
If a conversation happens and a path forward is discovered to produce a fix, I'd be happy to reopen and use it as tracking issue though. Thanks for your understanding.

[brupelo]

@Byron First of all, thanks for the fast response and clarification... No problem, so, just to make sure I fully understand here.

What'd be your suggestion to accomplish this desired behaviour with GitPython? Or when you say "invoking git commands" you mean just using builtin python subprocess module skipping completely GitPython package?

[Byron]

Yes, either that or repo.git.add(…) as a slightly more convenient frontend.

[brupelo]

@Byron Fantastic, thank you very much, that's exactly what I was looking for!

One last question from me (do you guys have any discord/forum channel for GitPython btw?). How would you create a commit that uses an author/committer now? Ie, before by using the index antipattern I'd use something similar to:

git_bot = Actor(
   settings_variables["bot_name"], settings_variables["bot_mail"]
)
index.add(staged_files)
index.commit(f"chore: {new_version}", author=git_bot, committer=git_bot)

But now, how can I specify the author/committer when using directly the repo.git frontend?

>>> repo.git.commit(["-q", "-m", "My commit message"])
INFO:git.cmd:git commit -q -m foo -> 0
'' 

How would I use my Actor on that command repo.git.commit command?

[brupelo]

Never mind, solved... I hadn't seen in the docs that you could use env when using these repo.git.commands lambda functions