© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
1b1ed1a
(Get the code!)
[Impact]
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.
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.
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.
[Testcase]
On a Jammy system:
$ git init
$ echo contents > original-file.txt
$ git add original-file.txt
$ git commit -m "Creating the file"
# Create a new file, modify an old one, stash
$ echo foo > new-file.txt
$ echo contents2 > original-file.txt
$ git stash push -u
# Modify the old file in a different way, commit
$ echo contents3 > original-file.txt
$ git commit -am "Altering the file"
# Apply the stash, see conflict, but what about the new file?
$ git stash pop
$ cat new-file.txt
# "new-file.txt" is expected to exist, but is gone
There is a test package available in the following ppa:
https:/
When installed, "new-file.txt" exists and is able to be read.
[Where problems could occur]
We are changing how git restores untracked files during a pop/apply operation during a stash. Currently, these untracked files are "lost" i.e. they vanish from the user's working directory. 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.
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 is unlikely any users have built workflows that depend on untracked files being removed on a stash pop/apply, versus users who intentionally put untracked files in their working directory only to find they have lost them forever upon stashing.
If a regression were to occur, it could break worldwide development workflows, due to git being the most popular revision control system, and as such, any changes are high risk.
[Other info]
This was fixed upstream by the following commit in 2.35.0:
commit 71cade5a0b172ec
Author: Elijah Newren <email address hidden>
Date: Tue, 4 Jan 2022 23:04:58 +0000
Subject: stash: do not return before restoring untracked files
Link: https:/
The issue was introduced in commit bee8691 ("stash: restore untracked files AFTER restoring tracked files" in version 2.33.1, so Focal is not affected. Since the fix is in 2.35.0, kinetic is already fixed.