[Bug 2026319] Re: stash: git does not recover untracked files during a pop/apply on conflict

[Richard Laager]

I am able to confirm that the test package,
1:2.34.1-1ubuntu1.9+sf363767v20230707b1, fixes the issue.

I installed the test package, confirmed it was fixed, downgraded to git
1:2.34.1-1ubuntu1.9 git-man=1:2.34.1-1ubuntu1.9 (the normal jammy
package), confirmed it was broken, upgraded again to the test package,
and re-confirmed it was fixed.

I also reviewed the debdiff. Everything appears in order to me.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to git in Ubuntu.
https://bugs.launchpad.net/bugs/2026319

Title:
  stash: git does not recover untracked files during a pop/apply on
  conflict

Status in git package in Ubuntu:
  Fix Released
Status in git source package in Jammy:
  In Progress

Bug description:
  [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
  cat: new-file.txt: No such file or directory
  # "new-file.txt" is expected to exist, but is gone

  There is a test package available in the following ppa:

  https://launchpad.net/~mruffell/+archive/ubuntu/sf363767-test

  When installed, "new-file.txt" exists and is able to be read.

  $ git stash pop
  Auto-merging original-file.txt
  CONFLICT (content): Merge conflict in original-file.txt
  On branch master
  Unmerged paths:
    (use "git restore --staged <file>..." to unstage)
    (use "git add <file>..." to mark resolution)
  	both modified:   original-file.txt

  Untracked files:
    (use "git add <file>..." to include in what will be committed)
  	new-file.txt

  no changes added to commit (use "git add" and/or "git commit -a")
  The stash entry is kept in case you need it again.
  $ cat new-file.txt
  foo

  [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 71cade5a0b172ece7edf0ccb4420dd5b9a07e71a
  Author: Elijah Newren <newren at gmail.com>
  Date: Tue, 4 Jan 2022 23:04:58 +0000
  Subject: stash: do not return before restoring untracked files
  Link: https://github.com/git/git/commit/71cade5a0b172ece7edf0ccb4420dd5b9a07e71a

  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/git/+bug/2026319/+subscriptions