Atom: Atom doesn't update file buffers correctly when switching branches.

[AustP]

Steps to reproduce.

1. git checkout master
2. git checkout -b new_feature
3. Open Atom with no files loaded.
4. Open an existing file and modify it. Keep it open.
5. git commit -am "Modifying file"
6. git checkout master

At this point you'd expect to see that the edits which you made would be gone since you are now viewing a different branch. However, the edits show up and git diff even highlights them.

Also PR #1271 supposedly fixed #693 (Closing file buffers when a file gets removed via git i.e. switching branches, deleting, etc.) but that is not happening for me. When I switch branches and a file gets removed, it stays open in Atom with no indication that it's not supposed to be there.

Edit: Personally I think a file getting removed via git should automatically close the buffer, while a file getting removed in another way should prompt you. "This file no longer exists, do you want to keep it open?". This is how Notepad++ handles the situation and I think that is the best way.

[lee-dohm]

Could you include the following information?

• Which version of Atom are you using?
• What OS and version are you running?
• Can you reproduce the issue after completely exiting Atom and restarting using atom --safe?

[AustP]

@lee-dohm Using atom --safe fixed the issue temporarily. After step 6 I switched back and forth between new_feature and master a few more times and the issue occurred after switching for the 5th time. I'm running Windows 7 with Atom v 0.169.0

[AustP]

@benogle What more information do you need?

[benogle]

We need whatever information can help us reproduce it, at which point we could consider it a bug. I am sadly not able to reproduce this issue

Personally I think a file getting removed via git should automatically close the buffer, while a file getting removed in another way should prompt you.

This does happen for me. Steps for this: a file on master but not on your branch, and you switch from master to the branch, it should close.

[AustP]

@benogle Hmm are you trying this in Windows? I've updated to 0.172.0 and still seeing the issue.

[AustP]

@benogle Do you need any more information?

[AustP]

I don't know if this will help but I submitted a ticket on the git-utils repo.
Specs failing on Windows

The issue may be stemming back to libgit2 but I'm unsure.

[samtechie]

I experienced a similar issue. Am using Atom 1.0 on OpenSuse 13.2 and when i switched to a different branch. The old files which I created on the other branch were still there. When I tried to close them . It asked if i should save the changes. I also think they should just disappear from the buffer.

[alexcreasy]

I'm having the same problem on Fedora 20 using Atom 1.0. When switching branches I have to manually close windows and select don't save for each file that doesn't exist on the newly switched branch. I think the files should just disappear from the buffer also.

[ghost]

I've experienced the same problem. Personally I would like to be informed when ever files change outside atom..

Atom 1.0.0..
Ubuntu 15.04..
git version 2.1.4

[lpommers]

Just thought I would say that I've only ever experienced this when switching branches from a tool other than the command line i.e. sourceTree atom 1.0.7 OSX 10.10.5 git 2.3.2

if I switch from terminal or iterm then everything works as expected

[ghost]

I have the same problem. I change a file and save it, then I run ' git checkout the file' command in git bash, the file do not restore in atom.

Atom 1.0 window7 and git 2.5

[crlang44]

I am getting this same bug on Ubuntu 14.04 LTS and Atom 1.0.0

[snird]

Same here with Atom 1.0.7 on Ubuntu 15.04
This is somewhat frustrating -
When working with multiple files open, I must close all of them whenever I switch branch.

Because take this scenario:

1. Switch to branch b
2. edit file example.txt
3. Switch to branch a
4. do some more work on example.txt

If I won't close example.txt between branches, the changes from branch b will come to branch a.

[spitzer]

Same: files from prior branch are still open and available in tree. have to restart atom. really undermines use of this amazing editor. Windows 7, Atom 1.0.19, Github for Windows.

[GabrielDelepine]

I also experience this issue.

Ubuntu 12.04
Atom 1.2.3
Git in console mode

[diamond-darrell]

Any news about this issue? I have same problem.
Linux Mint 17
Atom 1.1.0
Git 1.9.1

[dtabares]

Same issue here.
Ubuntu 12.04
Atom 1.2.4
git 1.7.9.5

[thanhtuong]

Same issue here:
Ubuntu: 12.04
Atom: 1.2.4

Using sublime not got the same problem.

[jrschmidt]

This happens to me so often I wasn't aware that it didn't happen for other people. I am currently on Ubuntu 15.10, Git 2.5.0, and Atom 1.3.0.

[wlgrd]

Atom 1.3.3, git version 2.6.4.windows.1 with MSYSGIT, Windows 7 x64. Same problem

[wlgrd]

It will update the file buffer if you after git checkout branch do git checkout -- .

[DustinD2]

I'm also running into this issue with files open over SMB from a ubuntu 14.04 host running git 2.6.4 and atom 1.3.3 on OSX.

The result varies between git checkouts, sometimes the file contains the old contents from the previous branch / state. Other times the file is empty and shows that it needs to be saved.

Saving the empty file, then performing a git checkout -- <file> closing and reopening the file will show the correct contents though.

[joshaber]

It looks like there are a couple different issues being reported in this thread:

1. Files that exist in branch A aren't closed when switching to branch B which doesn't have those files.
2. Changes to files are brought from branch A to branch B after switching branches.

I haven't been able to reproduce (1), so for those of you who are experiencing it, I'd love to know if you still see it on 1.4.0.

For (2), it sounds a lot like this is just How Git Works®. For example:

git branch a
git branch b
git checkout a
touch new-file.txt
git checkout b
git status

On branch b
Untracked files:
  (use "git add <file>..." to include in what will be committed)

    new-file.txt

Unless that change is committed or conflicts with changes in branch b, git keeps those changes. They persist across branch checkouts.

Does that make sense of what some of you are seeing? Am I misunderstanding?

[wlgrd]

For me it happens for files that is common in both branches. The file is modified and changes are commited to branch b. When checking out branch a, the file is still in the state from state b, until I explicitly do a checkout of the file if atom has the file open when I switch between the branches.

[dtabares]

I'm having the same behavior than @chrwi .

[joshaber]

Awesome, thanks for the clarification! What OS are you on, and how do you normally switch branches?

[wlgrd]

git version 2.6.4.windows.1 with MSYSGIT, Windows 7 x64. Switch branches with git checkout

[davide-targa]

I'm also having this issue.
Ubuntu 14.04.3 LTS x86_64 - Atom 1.4.1

[AustP]

@joshaber

1. Files that exist in branch A aren't closed when switching to branch B which doesn't have those files.

I am still experiencing this issue. I am on Atom 1.4.0 on Linux. Here are my steps:

1. git checkout -b new
2. create file named 'haha' using tree-view
3. using Atom, add the text '1234' and save 'haha'
4. git add .
5. git commit -m "test"
6. git checkout master

Now the 'haha' file is still open in Atom, even though it should be closed. But the worst part is that when I manually close the file, this prompt pops up:

The reason I think that's so bad is because sometimes I will have multiple files in one branch and after merging them back in, they will still be open in the editor. Then if I close the editor, I will get 3, 4, maybe 5 prompts all saying I have unsaved changes. Now if I merge the commits and close Atom in the same time period, it's fine and I know that it's just this issue cropping up. But if I get interrupted in the process (a phone call, coworker, etc) and then get these prompts about unsaved changes, I have to take the time to figure out if I _really_ have unsaved changes because if I just hit save, Atom will then write these files into the wrong branch.

[joshaber]

@AustP Thanks for that! This is on our radar.

As best as I can tell this bug is on Linux and Windows, but not OS X.

[ajkamel]

Just experienced this on Ubuntu 15.10. Almost committed stale code...

[brainrape]

Atom 1.5.4
NixOS unstable

Happens every time I switch branches. Open files don't load the new state from disk. Especially annoying with autosave since it overwrites the open files with the contents from the other branch.

Seems related to https://github.com/atom/atom/issues/9257

[kgagnon]

Any of you fixed the problem with a package that would bring a better integration of git ?

[wlgrd]

@Kuwshi this issue has nothing to do with git (and github did not create git). I guess it's just the most common use case for when this problem occurs
@Kuwshi Sorry, apparently I must have read another response when writing this. Some guy complaining that this should be better being that it derives from github.

[kgagnon]

@chrwi I know that has nothing with git and I know github did not create git. I don't know why you mention this.

If Atom does not refresh its buffer when a branch changes, what's the point ? I'm on branch X, I modify file Y and then checkout to master. Y changes would be applied to master if I left the tab of Y open and I ctrl+S.

This is really dangerous.

Edit : What I meant is : Is there a package for atom that helps with git integration and that would offer the behavior we are expecting in this thread. It should be in the core packages, which is why we have this thread but in the mean time, is there a package that could fix this ?

[gaui]

I experience the same issue regularly when switching branches, rebasing, stashing/popping. When Atom doesn't reload the buffer, you sometimes accidentally add/make changes and save the file, resulting in changes to an old version of the file (or a different version from a different branch).

When this happens I sometimes try to close the file, then Atom prompts me about unsaved changes and asks me if I want to save them. Why can't it detect the changes sooner and reload the buffer?

Please fix this.

Atom 1.6.0
Windows 10 x64

[johackim]

+1

[rossvz]

We have an app that has multiple flavors depending on the branch, need this fixed.

[osala-netquest]

+1

[oqx]

Same issue here :-(. It happened after I stashed and switched branches. The stashed files carried over to master. Luckily I caught them. atom --safe didn't seem to have any affect after closing and re-opening. I've repeated the close > atom --safe process a few times.

EDIT: I checked out a super old feature branch to see if it would refresh. While it didn't refresh, the new files did appear as untracked via git status, so it's definitely not just a visual issue.

System info:
Yosemite 10.10.5
git version 2.5.4 (Apple Git-61)
atom 1.6.2

[brunogarcia]

Same issue here.
When I change to another branch, the open files do not update automatically.
I need close them (being careful of not saved it) and open it again.
It's very annoyed.

System info:

• Ubuntu 14.4
• git version 2.8.1
• atom 1.3.2

Anyway, there is a plugin than watches open files for conflicts or changes:
https://atom.io/packages/file-watcher

[kellywerks]

Anyone know a better workaround for handling this or is opening and closing the only route?

[orodbhen]

Sad. I was really starting to like Atom, after discovering that Kate VI mode is broken in CentOS 7. Seems very strange for an editor that's supposed to be built around git, to not refresh when changes are made. I'm just glad I discovered this before I had anymore work blown away.

[Rahbaran]

Hm ... any idea when this issue is going to be solved? Switching branches in mac terminal, files of former branch are shown.

[Pharylon]

This bug is the reason I'm not using Atom at the moment.

[adamfaulkner]

I was having this issue on linux, and I thought it might be caused by too many inotify events overflowing the queue. I did a sysctl fs.inotify.max_queued_events=1048576 and haven't had the issue in the last day or so. That might be the source of some of these issues on linux.

I'll update this if I experience the issue again.

[adamfaulkner]

To update, this inotify.max_queued_events thing does not entirely fix the issue (perhaps I need to set that number even higher?). However, it reduced this from a >10 times per hour issue to 1 time in the last week.

I think the fix might involve periodically polling the filesystem to check if open files have changed, rather than relying on inotify completely. (I could be completely wrong - haven't actually found where this code lives, maybe this is already implemented and I have some other issue).

[bjornhanson]

I'm also seeing this problem. I switch to a different branch, start working on a file that was already open, and realize it's not the current branch's version.

Ubuntu 14.04
Atom 1.7.4

[JSDesign]

is this the same issue?

• create this_new_branch from master
• make changes, git add ., then git commit -m 'stuff'
• switch to master, pull fresh
• switch to this_new_branch, merge master into it
• inside this_new_branch, my changes are gone

also, according to @Rahbaran this is occurring on Mac.

[hultberg]

Using https://atom.io/packages/file-watcher resolves this issue, but it should be fixed in core.

[nzod]

To pile on, just got bitten by this on Atom 1.8.0, Ubuntu 14.04.

[bessiambre]

A few times after working with git I realized Atom has silently reverted changes in my files so the project was now a mix of two branches plus working changes. I sometimes only noticed after the corrupted files were merged with other people's code. What a mess!

[brianblakely]

Throwing in what I believe is relevant feedback on a couple issues.

Windows 7 / Atom 1.8.0

1. When I switch branches with file tabs open, the previous branch's buffers for those files are retained in these tabs. I must make sure to close all of my tabs before switching branches.

Granted, this has saved me from losing work when I have used git incorrectly, but I would personally rather Atom's behavior assume good usage and let me learn from my mistakes.

1. When I switch branches, git color coding does not accurately reflect git status.

Clicking a file name will update the rendering to the appropriate color.

[wlgrd]

Are there any progress on this issue, being that it has been open for over a year now?

[ghost]

I just found out about this issue the hard way (making massive changes on a branch and then discovering that my main branch got changed as well). I lost a lot of work.

I would REALLY love it if we can get a solution to this.

Ubuntu 16.04
Git 2.7.4
Atom 1.8.0

[Pharylon]

The best solution I found is to switch to Visual Studio Code. ;)

[wlgrd]

@Pharylon Please refrain from making stupid replies that only serves as clutter for the people trying to fix this.

[gaui]

@chillwilly Trying to fix this? It's been one year, it's like they don't care. Also I have to agree with @Pharylon I'm glad I made the switch to VSCode, this bug was making me lose a lot of work. For an editor that's not a great feature.

[wlgrd]

@gaui I totally agree, this seems dead, but I still think that we should stick to the point. Or maybe, sharing the users frustration is something that might bring the extra kick to the devs. I'm just frustrated over the situation and really like the editor so I still have hopes this would be fixed soon.

[JSDesign]

what @hultberg posted

Using https://atom.io/packages/file-watcher resolves this issue

no need to close files, worry-free gitting for over a month now ;)

[orodbhen]

I've seen at least one instance in which the file watcher failed to work.
It's been several weeks though, so maybe it's been fixed. In any event, it
shouldn't be necessary to install an extension for such a basic feature.
Especially when the editor is supposed to be designed specifically to
integrate with an SVC system.

On Thu, Jul 14, 2016 at 2:13 PM, Jeannie Stevenson <[email protected]

wrote:

what @hultberg https://github.com/hultberg posted

Using https://atom.io/packages/file-watcher resolves this issue

no need to close files, worry-free gitting for over a month now ;)

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/atom/atom/issues/4982#issuecomment-232746727, or mute
the thread
https://github.com/notifications/unsubscribe/AEXKqWLedn5-xEIWgpD6yqNEhzDpAhMsks5qVnxQgaJpZM4DQw79
.

[oliver-dungey]

Same problem here on Atom 1.8/Windows7. This issue is driving me nuts as I'm switching GIT branches all day long and keep forgetting to close file tabs which can easily result in accidentally applying changes to the wrong branch - it's not that the behaviour is strictly wrong, its the fact that every other editor seems to work differently, I've become accustomed to automatic file reloads/warnings in other editors.

[amandaporto]

+1 on this issue.

[int64ago]

Any ideas ?! This issue has opened for toooo long time....

[somename85]

same issue
ubuntu 15.04
atom 1.9.6

steps to reproduce:

1. on branch A
2. file 'index.js' is opened in tab
3. merge with branch B (conflict in file 'index.js')
4. file 'index.js' still in same state as in A branch

[jlozadad]

same issue
centos 7.x
atom 1.7.3

[ghost]

Same issue here.

System info:

Ubuntu 16.04
git version 2.7.4
atom 1.9.9

[yassernascimento]

Same issue

Atom: 1.10.2
Ubuntu 16.04
Git 2.7.4

[akurtovic]

Same issue:

Atom: 1.10.2
Windows 7
Git 2.10.0.windows.1

[ktravelet]

I just started using Atom heavily and really started liking it. This will absolutely be a deal breaker.

macOS 10.12
Atom 1.10.2
git version 2.8.4 (Apple Git-73)

• git branch -b new_branch
• create new file in atom new_file.txt with contents "text"
• save file in atom and do not close the file
• git add --all
• git commit -a -m "testing atoms ability to switch branches"
• git checkout master
• git status now shows modified new_file.txt in master branch
• ls shows new_file.txt actually in the directory

wtf...

[AaronM04]

@ktravelet Was the first command supposed to checkout the new branch in addition to creating it?

On October 6, 2016 11:33:37 AM PDT, ktravelet [email protected] wrote:

I just started using Atom heavily and really started liking it. This
will absolutely be a deal breaker.

macOS 10.12
Atom 1.10.2
git version 2.8.4 (Apple Git-73)

• git branch -b new_branch
• create new file in atom new_file.txt with contents "text"
• save file in atom and do not close the file
• git add --all
• git commit -a -m "testing atoms ability to switch branches"
• git checkout master
• git status now shows modified new_file.txt in master branch
• ls shows new_file.txt actually in the directory

wtf...

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/atom/atom/issues/4982#issuecomment-252049793

Sent from my Android device with K-9 Mail. Please excuse my brevity.

[ktravelet]

@AaronM04 - you got it.

[AaronM04]

@ktravelet I changed the branch -b to checkout -b and I couldn't reproduce that behavior in Atom 1.10.2 on OS X 10.11.6. Instead, all I saw was that the text file tab in Atom disappeared (which seems like reasonable behavior to me).

On October 6, 2016 11:44:27 AM PDT, ktravelet [email protected] wrote:

@AaronM04 - you got it.

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/atom/atom/issues/4982#issuecomment-252052803

Sent from my Android device with K-9 Mail. Please excuse my brevity.

[50Wliu]

on OS X 10.11.6.

This bug only affects Linux and Windows.

[avances123]

Same issue

Atom: 1.10.2
Arch linux
Git 2.10.0

[Dkra]

Same issue on OS :(

OS X 10.11.6
Atom: 1.10.2
Git 2.7.4

[samblackmore]

Same issue

Windows 7
Atom 1.11.1
git version 2.10.0.windows.1

[acjwong]

Got the same issue.

Ubuntu 14.04
Atom 1.10.0

My machine had been on for an extended number of days with Atom running continuously through many days and many commits. I had no issues for many days in a row and then suddenly it stopped refreshing files that had changed on disk (branch changes, etc). I tried restarting Atom with no luck--the problem persisted. I rebooted the machine and continued working with a different text editor for a day. The next day, I came back to try atom again and it began responding to the branch changes with the appropriate file refreshes again. I suspect that this issue may be related to the fact that atom was running through many different commits and branch changes over many days. I have never had this issue before, but I'm surprised that this has been an issue raised since January of 2015 and still almost two years later, this still appears to have not been addressed yet.

[nicos68]

Same issue

Windows 7
Atom 1.12.0-beta3
Git 2.9.2

[ctiller]

Same issue

Linux
Atom 1.6.0
Git 2.8.0

[50Wliu]

Atom 1.6.0

@ctiller You might want to update...the latest version of Atom is 1.12.2.

[orodbhen]

I'm using 1.12.5, and the issue is still present. If the file has been saved, and another program changes it, then it will be automatically updated in atom.

However, if the changes haven't been saved in atom, you'll have no idea it was changed by another program, and it will overwrite the other program's changes on save.

With File Watcher installed, I get a prompt. That's fine, but I just can't see how an editor that's supposed to work well with git, doesn't do a better job of detecting changes.

[lucascosti]

I never used to have this problem before, but it has started occurring consistently for me in the last month or so.

Fedora 25
Atom 1.12.6
Git 2.7.4

Not sure why it has only started recently...

I've gotten used to reloading Atom with Ctrl-Alt-R after switching branches to be safe.

[ekuric]

same issue with fedora 26, atom 1.11.1 and git 2.9.3

[lee-dohm]

@karlpokus your comment was deleted as a violation of the Atom Code of Conduct as is insulting or derogatory. You may consider this an official warning.

[karlpokus]

@lee-dohm You're right. I apologize. I was way out of line.

[shachar-i]

Same issue

Windows 7
Atom 1.15
Git 2.6.3
I am also using SourceTree.
I will try switching through terminal only to see if I get the same behavior as @lpommers reported

[Bjvanminnen]

I'm on OSX El Capitan, and historically this has all worked as expected for me. However, in the last couple days I've started to hit this same problem. I'm not sure what I changed that caused this. Here is my repro.

1. git checkout new_branch
2. Create a new file (foobar.js) in atom (I did this by duplicating an existing file), and save it.
3. git add .
4. git commit -m "my changes"
5. git checkout master

Result
foobar.js is open in atom. The icon in my tab indicates that it has unsaved changes. If I save it, it saves to the original location (in my repo).
Strangely, if I now check out new_branch again, the icon on the tab in atom still indicates that it thinks this file is changed.

Expected:
foobar.js is no longer open in atom

[caesarsol]

Please take a look at https://github.com/atom/atom/issues/9257#issuecomment-286686455

Could this be the same problem?

@orodbhen this is the same issue you describe. Are you referring to https://github.com/lwblackledge/file-watcher ?

[Bjvanminnen]

It's possible that the issue in the comment you reference has the same root cause as mine, but the scenario feels pretty different. In their case, they edit the file in a different text editor. In my case, all I'm doing is switching branches in git.

Let me know if you need any additional info.

[Bjvanminnen]

Enabling the option in https://github.com/atom/atom/pull/13657 fixes this for me. (Presumably this worked for me, and 13657 regressed the scenario for me by changing the default behavior when I updated to 1.15.0).

[rkabrahpudi]

Awesome.. I got bashings from Manager because of this issue..
I take a pull before comitting my changes. When i commit the changes, others changes are lost if that tab is open.

[yubaoquan]

I lost a whole day's work. about more than ten new added files lost.

[yao23]

I'm in top folder and it works only after save (cmd+s) the change, then it will show in git.

[albert-the-creator]

I was going to switch from sublime to Atom but... after losing a whole day's worth of work, its just not worth it. I use branches so that this issues isn't an issue... My steps to reproduce are:

1. edit file A in branch A
2. checkout branch B while file A is still open and modify file A
3. checkout branch A
4. productivity -= 100;

Today was my first time using atom.

[yubaoquan]

Will this bug be fixed in this year?

[Szarko]

Any news on this issue? Atom doesn't even close open file tabs when switching between branches and the files do not exist in the new branch. You have to manually close the tab and click do not save changes.

[lemuelmc]

This is still happening.

Looks like Atom is not friendly to SCM :(

[luisespinal]

I'm having the same issue when switching branches.

• git version 2.12.2.windows.2
• atom 1.18.0-beta2 x64
• Windows 7

In fact, it's not just with SCM files, but with free files in general (though with a different behavior.)

Say I have a file opened in Atom (my.txt), and some other process modifies it.

At that point, Atom's tab changes the tab (and file) name to my.txt~ (notice the tilde.)

It's a surreptitious change, one that will go unnoticed if you are working with multiple files.

Worse, I can make changes in the tab and save. That creates a my.txt~ file (instead of reporting a conflict.)

Eclipse and IntelliJ detects such changes. Notepad++ does it to. And so does Sublime and even the good old and humble gvim.

I'm new to Atom, so maybe this behavior is know, but it is very disconcerting. I need to be aware of both my work and my IDE's behavior if I'm using Atom. :(

[luisespinal]

As a work-around, I'm using file-watcher with these configuration settings:

[anushreesubramani]

Same issue.
Atom 1.17.2
Ubuntu 14.04

Cant believe this issue is 2 1/2yrs old. Would be nice if this gets fixed soon.

[nmarchini]

I've started to have this issue in the last few days, it was working fine until then.

Which version of Atom are you using? Using Atom 1.18.0
What OS and version are you running? Mac OSX Sierra Version 10.12.5 (16F73)
Can you reproduce the issue after completely exiting Atom and restarting using atom --safe? Yes

Git version 2.13.1 (was also an issue with previous version, I updated git to try and resolve the issue)

I have removed Atom and reinstalled it with default packages. Still having the issue.

I've just realised i've lost a whole days work due to this problem

• Why did it just start happening?
• What are the work arounds?
• When will a permanent fix be put in place

@lee-dohm anyone available to look at this or at least comment on when this can be worked on please?

[cdmac24]

I too am having this issue but it wasn't happening _before_.

Currently on:
MacOS Sierra 10.12.6 Beta (16G18a)
Atom 1.18.0 x64
Git 2.11.0

"Before" includes before MacOS Sierra, before updating Atom (I think I was on 1.17).

I have not updated git.

If I run atom --safe, the issue is the same.

[mattchilds1]

I'm also having the same problem, not fixed by --safe. Only way I'm able to fix it is to delete the contents of ~/.atom/storage/* followed by a restart of Atom.

I'm on:
OSX 10.12.5 (16F73)
Atom 1.17.2 x64

@lee-dohm

[ungb]

I was unable to repro on 1.18.0 based on the repro on the first comment, does any one have a more updated scenario of when they see this? That scenario has to do with modifying a file.
Are people seeing issues with deleted/adding files or modifying a file, saving, committing and switching branches?

[AustP]

@ungb Have you tried the reproduction steps in my comment on Feb 2, 2016?

Those steps are still producing the issue for me. (Atom 1.18.0 Linux)

[cdmac24]

This issue is still reproducible for me as well just as @AustP described in his post from 2 Feb 2016.

I didn't know enough to know back then because I have been doing a bunch of tutorials for which I always merged the feature branch into master when I was done with the section in the tutorial. In that scenario I never noticed this behavior because all the files open would exist in _master_ as soon as I merged the feature branch into master.

[ungb]

I was able to repro the issue with repro steps from @AustP (https://github.com/atom/atom/issues/4982#issuecomment-178676463).

It seems like this issue is fixed with this setting that was added in pr: https://github.com/atom/atom/pull/13657

If this setting is checked, the file will close when you change branches

[cdmac24]

Thanks, @ungb !! Much appreciated. I can confirm that with this setting enabled, Atom is now closing the tab(s) for the file(s) that do not exist in the other branch as expected (for me at least).

[ungb]

Thanks @cdmac24, I'm going to close this issue. If you guys still see this issue after applying the setting mentioned in https://github.com/atom/atom/issues/4982#issuecomment-316193811, please comment here and I will reopen this issue.

Thanks everyone for all your help!

[ungb]

It seems that this issue is fixed on 1.18, but regressed in 1.19. See https://github.com/atom/atom/issues/14765 for more info

[sashak007]

I'm still able to reproduce this issue - same steps outlined by @AustP even with the 'Close Deleted File Tabs' option selected. I'm using Atom 1.19.0. Would appreciate any help!

[ungb]

@sashak007, This issue regressed in 1.19.0 and just yesterday @kuychaco pushed a fixed out in https://github.com/atom/text-buffer/pull/244. Currently 1.19 is at 1.19.2. This issue should be fixed when 1.19.3 goes out. Sorry for the trouble.

[sashak007]

Ok, thanks!

[ZachEddy]

Still having this issue, @sashak007? I'm able to reproduce with version 1.19.4.

[sashak007]

@ZachEddy - It's resolved! Thanks for checking in!

[goodlux]

@sashak007 I'm still having this issue: unsaved changes when switching branches overwriting files in the new branch...atom 1.20.1

[ktravelet]

Sorry guys this was one of the major deciding factors for switching to vscode. Git integration is a first class citizen over there.

[adamsimonini]

Currently on version 1.21.1. I was having the problem of changes persisting across branches for weeks. I have gone into settings, core, and clicked the item @ungb recommended. Will post back if problem remains; if not, it's solved. Thanks :)

[jcmarchi]

The solution @ungb pointed remediates the problem when files are not present in different branches, preventing tabs from staying open when files no longer exist, but the Git "branch switch" problem still remains.

In terms of Git, a clean state is needed to change branches. It means that non-committed files (known as "dirty files") must be stashed first, before switching branches, so the status of the changes can be retrieved when you switch back to the branch with non-committed files (or if you want to move those files across branches).

I am not sure if Atom could use stash for this purpose (probably not, after all, it would be kind of hard to manage an accumulation of stashes from several branches). Maybe a visible warning asking developers to commit or stash their changes before switching branches could be a better choice. One thing is fact: branches should not be switched if non-committed non-stashed files exist.

A good reading about the subject be found here https://stackoverflow.com/questions/22053757/checkout-another-branch-when-there-are-uncommitted-changes-on-the-current-branch and here https://www.kernel.org/pub/software/scm/git/docs/git-read-tree.html#_two_tree_merge

[alecbz]

Solution by @ungb is pretty good, but kind of unfortunate that there's not more direct git integration here. E.g.: it'd be nice if this happened when the git branch switches, but not for general deletions otherwise (this way atom would save the buffer if it was accidentally deleted by some other mechanism).

[philippgovernale]

On 1.23.3 I am still having these issues even with the solution by @ungb. Files do not update after changing branch. Not even restarting has worked so I am forced to use another text editor.

[zbroniszewski]

I was not having this problem up until a couple days ago. I'm running Ubuntu 16.04.3 LTS, atom 1.2.3 downloaded by adding the repo to my system. If I completely wipe my disk, reinstall Ubuntu, install atom, and test switching branches, it will work. When I restart my computer, it stops working. In the bottom pane of atom where it tells you the branch you are on, that only changes the branch name once you give focus to atom after running for example "git checkout newBranch" in terminal. So to summarize, if I checkout a new branch, nothing will happen. When I click into atom, it will change the branch, the git diff package will highlight changed lines, BUT no lines or code will actually change. This used to work perfect. I've tried installing older versions of atom, same thing. This is extremely annoying. Any updates on this? It's clearly effecting a lot of users.

[zbroniszewski]

Well, I think I figured it out. At least on Ubuntu 16.04.3 LTS. An application I was installing (ULauncher) seems to have an effect on this issue. When I install it, this feature of atom breaks. When I remove it, and run sudo apt-get autoremove it works fine after a reboot.

For anybody who uses ULauncher, you know you have to fix a broken install when you install it for the first time. Here's what appears after sudo apt-get install -f

The following additional packages will be installed:
gir1.2-keybinder-3.0 libkeybinder-3.0-0 python-backports.ssl-match-hostname python-dbus python-gi python-levenshtein python-pkg-resources python-pyinotify python-pysqlite2 python-six python-websocket python-xdg
Suggested packages:
python-dbus-doc python-dbus-dbg python-gi-cairo python-setuptools python-pyinotify-doc python-pysqlite2-doc python-pysqlite2-dbg
The following NEW packages will be installed:
gir1.2-keybinder-3.0 libkeybinder-3.0-0 python-backports.ssl-match-hostname python-dbus python-gi python-levenshtein python-pkg-resources python-pyinotify python-pysqlite2 python-six python-websocket python-xdg

So perhaps its one of these python packages? No clue, just hope this helps give us a clue. Remember, this might not necessarily be a ULauncher thing but ANY application or program that requires one of these packages that are screwing this feature of atom up.

If anybody can help me out who runs Ubuntu and has this issue (4982), please run a sudo dpkg -l {package-name} on the packages listed above under "The following NEW packages will be installed:"

If we get enough people to do this and cross-reference, we can triangulate that pesky package.

[zbroniszewski]

I can confirm that it has to be a package required from ULauncher. To test my hypothesis, I tried a few things:
1.) I set ULauncher to boot on login, rebooted, and atom was having this issue when trying to switch branches.
2.) I removed ULauncher from Startup Applications, rebooted, launched atom BEFORE starting ULauncher, and everything was working perfect.
3.) I kept ULauncher out of Startup Applications just as it was previously, rebooted, but this time I opened ULauncher BEFORE atom, and the issue of this thread occurred yet again.

It's worthy to note that it appears that everything depends on which application is started first, if I start ULauncher before atom, this issue will always result during the current session. However, if I start atom first, everything will work perfect during the current session, even if I open ULauncher as many times as I want afterwards.

I'm searching for all of atom's dependencies as Linux packages but I can't seem to find anything helpful online, does anybody know how I can view atom's dependencies?

[zbroniszewski]

@philippgovernale @AlecBenzer @jcmarchi @adamsimonini @goodlux please check my recent comments, maybe we can finally figure this out after two years!

[samablews]

Still having this issue in Atom 1.24.0 on MacOS 10.12.6. vi shows updated file contents but Atom keeps loading an old version. This is after doing a pull request.

[zbroniszewski]

@samablews please read my comments above yours. I know we are on different operating systems, but if there is a way to disable ALL startup applications on Mac, do that, then reboot. Open atom ONLY when you boot, then the console or whatever you use to switch branches. See if atom updates the files correctly.

[stanfieldr]

I am not using git, but am doing something similar and my tab isn't updating. Figured out how to reproduce the issue if it helps.

$ cd projectA
$ touch diff.diff
$ atom . # Close all tabs if you have any open, it doesn't seem reproducible if you do not
$ cd ../projectB
$ atom . # Only can reproduce if two editors open in different projects
$ cd ../projectA
$ printf 'test\n1' > diff.diff
# Go to atom with projectA, hit ctrl+p, open diff.diff
# Notice test then new line then 1
$ printf 'test\n2' > diff.diff
# Does not update tab to show test 2... only if you close tab and reopen.

I'm running Fedora 27 with Atom 1.23.3

[DmitriWolf]

I also have this problem and find it very annoying. Closing and re-opening the tab is a fail because it is useful to be able to ctrl-z and ctrl-shift-z to compare the changes that happened when you switched a branch. When you close and re-open the file, those changes are lost.

I'm surprised that this is marked as "closed". It looks like this is not going to get fixed. It surprises me that folks who maintain this project don't find it annoying as well.

Looks like I'll be switching to another editor.

[izzydoesit]

+1 to closing tabs that don't exist on destination branch when switching between branches. I know Atom doesn't assume workflow and that's why it leaves it open.

How about a setting that can toggle this feature on and off so user can decide?

[ktravelet]

Sorry for the not so helpful comment but this issue has made me switch to VSCode and I haven't looked back since. I'd really like to develop with non-Corporate open source projects but VSCode is so much better than the alternatives. Please feel free to reach out to everyone once Atom catches back up and I'd be more than happy to come back.

[jcmarchi]

WOW... I was silent about that but... I switched to VSCode as well and it
was the best thing I ever did.

Sadly (for Atom) VSCode is much faster, much more reliable, less memory hog
and everything works (even the plugins). :)

I believe the real problem relies upon Atom itself, as it is Chrome based
and it is naturally bloated at its core.

I still have Atom installed, but for no reason at all. Even my secondary
editor is now Kate before Atom...

I would love to see Atom catching up... But, as far as I can see it will be
a very hard task.

_Edit: Moderator removed personal information_

[lee-dohm]

Thanks everyone for the feedback on this. Unfortunately, the conversation has gotten way off the point here. I'm going to lock this issue for further comments. If people have a bug they would like to report, please open a new issue and fill out the required template.