Gitkraken repo, failing to checkout branch, then suddenly deleting dozens of files

As will soon become clear, I'm not a master of Git or even Gitkraken. As such, I just have a hotfix, a master and a feature branch. I make changes in hotfix, commit, push, and merge into master (which I then also push). So far I've endeavored not to get more complicated than this.

Even my one feature branch is a bit cowardly, in that that I still keep my feature work separate (in separate files/directories) from my working files, and consistently merge master into the feature branch so I don't lose all the site's hotfixes – all so that my crucial site files are kept whole and untouched regardless of branch. I consider this an intermediate practice as I continue to maintain the site while getting my head around Git. Since now I'm having this bizarre issue, I can see why I hadn't taken that leap yet. Apparently I'm indeed not ready to power-use Git or Gitkraken.

This morning, I did some work on hotfix, and merged it into master. No issue. Then I tried to switch to the feature branch (which I hadn't been in for weeks as it has been all about hot fixes lately), and all hell broke loose. Gitkraken throws the error: "Checkout failed. Could not remove [swf file - one that was there long before my last commit] Operation not permitted." What? Web searches with these key phrases turned up literally nothing... making me the first person to have this happen, I guess.

Then!... immediately, still in hotfix and having done nothing further, suddenly there are 27 file changes staged and ready to commit! All of them deleted files, and none of which did I actually throw away. Some of them I didn't even touch since my last commit, others were new files I had made.

I was able to simply undo-button my way back and restore those deleted files, but this did inexplicable things to the Gitkraken timeline (see that I have no way of understanding... somehow it involves changes having been made to the feature branch (aka JQMUpdates5 in the screen cap) that I was unable to switch to...?

At least I got those deleted files back. However, I'm unable to move forward or to restore my repo to a workable state. Even after restoring to this morning's state via Time Machine, and attempting to retry the process, I get the same result.

The only thing I can think of is that the file GK "could not remove" is locked in the Finder. This shouldn't be an issue since this file is the same as many others like it in the repo – all of which are also locked n the Finder.

Other than that, it occurs to me I did not push master before trying to switch to feature – like I usually do. But as far as my meager understanding goes, it shouldn't be necessary to update the remote master branch before switching to a different local branch...

I need help. Is this a bug? Is my repo corrupted? The upshot seems to be that although I personally didn't delete any files, GK seems to randomly be doing it for me when I try (unsuccessfully) to switch to the JQMUpdates5 (feature) branch.

I'm trying to understand why my hotfix branch was in a fully up-to-date state until trying to switch to the feature branch, when suddenly GK trashes dozens of files and stages these deletions in one fell swoop. Undoing isn't helpful – just complicates the issue – and now I'm so spun around I have no clue how to get my repo back. It would be an absolute disaster for me to lose JQMUpdates5 branch, as it contains a huge amount of dev work.

I'm not sure how helpful my description of the problem is (because this is confusing as anything I've encountered), but I'd sure appreciate some guidance if anyone has any insight.
Gitkraken's inexplicable error messageThis happens immediately after the failed feature-branch-switch. This recurs even after restoring from everything from a time machine backup.This is the timeline after trying to undo the commits/pushes. I have no idea what's happening, but it seems to involve the branch I couldn't switch to, which is weird.
Matt KWeb DesignerAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

What happens when you switch back to the hotfix branch? Do the files reappear?

Actually, it is quite difficult to corrupt the repository. The files are probably there. The question is what was expected in the feature branch and from what commit point the feature branch was created.

The visible files are actually a copy of the state that belongs to the commit point.

I suggest to download the standard Git installation from and use the git gui and gitk --all commands to see what happens (visual). Then you can compare what you can see in GitKraken.

Actually, the repository is the same -- only the tools are different. I can guide you when using command line and the tcl/tk based GUI -- I do not know GitKraken.
Matt KWeb DesignerAuthor Commented:
Thanks for jumping in, pepr.

This was all due to bad permissions.

I noticed that the branch switch always choked on the same file, so I moved that file out of the repo. Then it choked on the next file of the same name in a different directory. Something about those little .swf files. I noticed that the one thing these files had in common beside their MIME type was that they were locked on my system, and that even I as the admin couldn't simply unlock them.

Long story short, I had to recursively apply read/write permissions from the top of my user directory to regain the privileges to unlock these files. Once I did, GK stopped choking on them and I was able to switch branches again. Thanks to a well-timed backup, I still had all the most up to date branches on my local repo, so I just force pushed those and updated the remote. The repo is sitting pretty again.

Of course now I'm side-eyeing Gitkraken a little, 'cause that is not the behavior I would expect from Git when encountering locked files or permissions issues... deleting/staging a bunch of unrelated files, really? Just because some locked files are encountered? Maybe someone smarter than me could explain exactly why that makes sense, but I sure don't get it.

You make a strong point about the command line. Might have to start going back to that more often. Thanks again!

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Matt KWeb DesignerAuthor Commented:
This was such a weird issue, I was just glad to have someone jump into the fray. I'm sure I'm going to run into Git problems again (especially if I'm using the command line more often) so I'm glad to know folks are out there willing to walk me through it. Cheers, Pepr!
You are welcome :)

We have a proverb here: "More heads, more wisdom." But sometimes it works the way the other head works only as a catalyser -- not actually bringing the solution, but helping to find it by just the presence. For the situation, I have modified the proverb to: "More heads, more cabbage." :)

Anyway, I have found the following source of information to be very good (and freely available)
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.