-
Notifications
You must be signed in to change notification settings - Fork 9.1k
fix: correct add logic for all vs specific files and add tests (#2373) #2379
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
Conversation
|
Hello @olaservo, |
| return f"Changes committed successfully with hash {commit.hexsha}" | ||
|
|
||
| def git_add(repo: git.Repo, files: list[str]) -> str: | ||
| repo.index.add(files) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
forgive my ignorance here, but is there a reason we don't just use repo.git.add always? e.g. could we get away with not making . a special case?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
forgive my ignorance here, but is there a reason we don't just use
repo.git.addalways? e.g. could we get away with not making.a special case?
The issue was caused by using repo.index.add(["."]), which doesn't behave like git add . and ends up including .git/ files, corrupting the repo. I added a check to use repo.git.add(".") when ["."] is passed, which correctly mimics Git’s behavior. This keeps things safe and avoids staging internal Git files.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I meant why not just repo.git.add everything (i.e. never use repo.index.add)?
Or @claude if you're around are you able to chime in?
domdomegg
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM - would like to understand why we use repo.index at all (see comment above) before merging.
|
Hey @domdomegg — fixed a small typo ("successfully") that caused the build to fail. Also shared a quick note above on why this approach was used — could you please re-review the PR? |
|
From Claude: Hi @domdomegg, Regarding your question about why not always use Both approaches work, but there are trade-offs:
You could indeed simplify the code to always use
If you prefer consistency over the minor performance benefit, switching everything to To me, this suggests we could simplify the code by always using repo.git.add - I think I'd have a slight preference for this. I don't think performance is what we're optimising for here. But that said it sounds like this PR will work and is an improvement, so I will accept it. |
domdomegg
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approving - will merge in a bit if we don't want to change the add/index thing
Description
This PR updates the
git_addfunction to correctly differentiate between staging all files (["."]) and specific files. Previously, using["."]could unintentionally include the.git/directory, potentially corrupting the repository. This fix ensures only appropriate files are staged.It also includes two additional test cases:
["."]Server Details
Motivation and Context
Fixes #2373
The issue identified that
git_add(files=["."])was tracking files inside the.git/directory. This caused repository integrity issues. This PR corrects the logic to avoid touching internal Git files and ensures safe staging behavior.How Has This Been Tested?
.git/is excluded when staging all filesBreaking Changes
None
Types of changes
Checklist
Additional context
Let me know if there are any changes or improvements you'd like to see. Happy to revise as needed.