Yikes! "Bring changes to new branch" -- lost tons of uncommitted code

Describe the bug

Steps:

• Made many uncommitted changes to my own “master” fork of an upstream “master” repo: changed and added many files, changed many directory names
• Decided to bring the changes to a new “feature” branch, on my own repo.
• Clicked New Branch in GitHub Desktop, created the “feature” branch
• Clicked “Bring my changes to the new branch” not “Stash changes on current branch”
• New branch was automatically re-based on an upstream master, not my working “master” forked repo.
• Many merge conflicts, obviously
• Tried to commit changes to new branch, but not possible (thankfully!) - merge conflicts reported unresolvable

Then i noticed the missing directories and hundreds of missing changed/added files

Version & OS

GitHub Desktop 2.4.3 MacOS 10.14.6 Mojave

This seems to parallel issues #9140, #9038, and #8084

Please advise. I would like to switch to my former working “master” branch to find out if changes were stashed, but it seems i am blocked from switching branches until i resolve merge conflicts in the new “feature” branch.

I don’t actually want these changes going to the new branch because of the missing files/directories - I would like to first commit my uncommitted changes to the previous “master” branch for safekeeping.

It’s 3 days work that seems to have vanished.

More detail

I’m aware that from the point of viee of the upstream master, these were untracked files, but here is an outline of what was lost or updated. Losing untracked files would be of course expected, if i were not trying to bring the changes to the new branch.

Let’s say these are some of the files i worked on, from my working “master” branch:

/old-folder1
--old-file-name1
/old-folder2
--old-file-name2
/old-folder3
--old-file-name3

And all the files had uncommitted changes, with some directories and filenames changed:

/old-folder-rename1
--old-file-rename1
/old-folder-2
--old-file-rename2
/old-folder3
--old-file-name3
/new-folder4
--new-file-name4

New branch only has these changes:

/old-folder-rename1 = IGNORED, VANISHED FROM REPO
--old-file-rename1 = IGNORED, VANISHED FROM REPO
/old-folder1 = UNCHANGED
--old-file-name1 = UNCHANGED
/old-folder2
--old-file-rename2 = NOTICED, REQUIRES COMMAND LINE ADD
/old-folder3
--old-file-name3 = OK, CHANGES DIFFED IN GITHUB DESKTOP
/new-folder4 = IGNORED, VANISHED FROM REPO
--new-file-name4 = IGNORED, VANISHED FROM REPO

Again, I haven’t committed anything, so maybe unstaging the changes to the new branch (via a soft reset) will work, and then i can switch branches and see what’s going on.

[nimmolo]

Hahaha - Hi Tiernan, thanks for replying.

To answer the first question. No, i did not rename the branch with the stashes.

It’s way too late to save that commit, but the lesson I learned by losing 3 days work was “Never ever bring uncommitted work to a new branch”. I do feel the option should be probably disabled in Desktop until it’s working right.

I can dig up the logs.

On 1 Jun 2020, at 18:27, Tiernan L [e-mail] wrote:

@nimmolo Apologies for the late reply! I hope it is not too late to help you.

By any chance did you rename the branch with the stashes? This will cause your stash to be hidden (not intentional). If so, once you change the name of the branch back to the original name and the stash should reappear.

If this was not the case, I can investigate further as you may be correct in your comment about those parallel issues.

If you could share your logs from that day, it would helpful. See the Help menu in Desktop to access the logs. Let us know and again, apologies for the delay.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[thecyman]

I had noticed that GitHub Desktop did not detect some uncommitted file changes I had just made in my local branch on my Mac. Another Git app- VSCode did correctly detect them. It was a 4000 file repo. I don’t think it was a “slow detection” thing, but its possible. I assumed it was a one-off issue. Later, I merged into master but some lost changes that were not detected. A somewhat similar issue to @S364 as a consequence.