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
Be careful about left-over files from git add --edit
runs
#107
Conversation
Welcome to GitGitGadgetHi @dscho, and welcome to GitGitGadget, the GitHub App to send patch series to the Git mailing list from GitHub Pull Requests. Please make sure that this Pull Request has a good description, as it will be used as cover letter. Also, it is a good idea to review the commit messages one last time, as the Git project expects them in a quite specific form:
It is in general a good idea to await the automated test ("Checks") in this Pull Request before contributing the patches, e.g. to avoid trivial issues such as unportable code. Contributing the patchesBefore you can contribute the patches, your GitHub username needs to be added to the list of permitted users. Any already-permitted user can do that, by adding a PR comment of the form Once on the list of permitted usernames, you can contribute the patches to the Git mailing list by adding a PR comment After you submit, GitGitGadget will respond with another comment that contains the link to the cover letter mail in the Git mailing list archive. Please make sure to monitor the discussion in that thread and to address comments and suggestions. If you do not want to subscribe to the Git mailing list just to be able to respond to a mail, you can download the mbox ("raw") file corresponding to the mail you want to reply to from the Git mailing list. If you use GMail, you can upload that raw mbox file via: curl -g --user "<EMailAddress>:<Password>" --url "imaps://imap.gmail.com/INBOX" -T /path/to/raw.txt |
If there is already a .git/ADD_EDIT.patch file, we fail to truncate it properly, which could result in very funny errors. Of course, this file should not be left lying around. But at least in one case, there was a stale copy, larger than the current diff. So the result was a corrupt diff. Let's just truncate the file when we write it and not worry about it too much. Reported by J Wyman. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
/submit |
Submitted as pull.107.git.gitgitgadget@gmail.com |
This actually already made it to |
And it got the name |
7fa92ba merged it into |
J Wyman reported almost a year ago (and I fixed this issue in Git for Windows around that time) that the
.git/ADD_EDIT.patch
file might still lie around at the beginning ofgit add --edit
from previous runs, and if the new patch is smaller than the old one, the resulting diff is obviously corrupt.This is yet another Git for Windows patch finally making it to the Git mailing list.