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

[Matthew Ruffell]

Public bug reported:

[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://launchpad.net/~mruffell/+archive/ubuntu/sf363767-test

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 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.

** Affects: git (Ubuntu)
     Importance: Undecided
         Status: Fix Released

** Affects: git (Ubuntu Jammy)
     Importance: Medium
     Assignee: Matthew Ruffell (mruffell)
         Status: In Progress


** Tags: jammy sts

** Also affects: git (Ubuntu Jammy)
   Importance: Undecided
       Status: New

** Changed in: git (Ubuntu)
       Status: New => Fix Released

** Changed in: git (Ubuntu Jammy)
       Status: New => In Progress

** Changed in: git (Ubuntu Jammy)
   Importance: Undecided => Medium

** Changed in: git (Ubuntu Jammy)
     Assignee: (unassigned) => Matthew Ruffell (mruffell)

** Tags added: jammy sts

-- 
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
  # "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.

  [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