#GIT STASH RESTORE PATCH#
With the patch applied, user's untracked files will no longer vanish on stash pop/apply, and while I don't think user's would be surprised to find files they intentionally placed in the working directory safely restored, there is a change in behaviour that these files are now restored, instead of being "deleted" or lost forever. It currently is possible to get them back, but you need to dig around in orphaned commits, and since they no longer have any references anymore, even finding their commit hashes is difficult. they vanish from the user's working directory. Currently, these untracked files are "lost" i.e. We are changing how git restores untracked files during a pop/apply operation during a stash. The stash entry is kept in case you need it again. No changes added to commit (use "git add" and/or "git commit -a") When installed, "new-file.txt" exists and is able to be read.ĬONFLICT (content): Merge conflict in original-file.txt net/~mruffell/ +archive/ ubuntu/ sf363767- test There is a test package available in the following ppa: # "new-file.txt" is expected to exist, but is gone # Apply the stash, see conflict, but what about the new file?Ĭat: new-file.txt: No such file or directory # Modify the old file in a different way, commit # Create a new file, modify an old one, stash The only workaround is to ensure that doing a pop/apply will not cause any merge conflicts, or to ensure that all of your files are added and committed. This is a problem because files users intentionally place in their working directories are lost, which could lead to user's losing their data or recent development effort. On jammy, untracked files in a working directory are not recovered if you have previously stashed them, if there happens to be a merge conflict when it comes to pop/apply the stash during rebasing operations.
0 kommentar(er)
