1

I'm on a team of three developers working on an Xcode project that uses SPM dependencies (only; no Cocoapods, etc). Our repo is hosted at Github.

Proj.xcodeproj/project.xcworkspace/xcshareddata/swiftpm/Package.resolved was initially committed to the repo. Switching to Xcode 13b periodically would cause massive changes to that file, so for a time, we had a .gitignore file in Proj.xcodeproj/project.xcworkspace/xcshareddata/ that ignored Package.resolved. Recently I removed that, and re-added Package.resolved to the repo.

Now we’re seeing this behavior where periodically, Package.resolved will be deleted upon git pull, and git will report

$ git status
On branch add-google-sign-in-package
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
    modified:   Whatnot.xcodeproj/project.pbxproj

Untracked files:
  (use "git add <file>..." to include in what will be committed)
    whatnot.xcodeproj/project.xcworkspace/xcshareddata/swiftpm/

We can’t find a commit that shows the file being deleted. I’ve never seen it as a staged-for-deletion in git status. At no point does the old .gitignore file re-appear.

Update: This might be related to creating and merging branches.

Any idea what’s causing this?

Rick
  • 3,298
  • 3
  • 29
  • 47
  • The main thing you need to decide here is: *should* the file be committed? If it's autogenerated, the answer is usually "no". If it's not autogenerated, the answer is usually "yes". – torek Sep 02 '21 at 13:16
  • Note that `git pull` means *run `git fetch`, then run a second Git command for me based on what `git fetch` fetched*. The fetch step itself is always safe and won't ever destroy any file like this. The *second* command is the one that will change or even remove some working tree files. The default second command is `git merge`, and yes, merging is where you are likely to run into this kind of thing. – torek Sep 02 '21 at 13:18
  • Package.resolved is generally kept in source control. And this isn't about git pull vs git fetch. – Rick Sep 07 '21 at 18:15
  • OK, so if you do want it committed, you don't want it ignored; don't list it in `.gitignore`. As for pull-vs-fetch: your update said "might be related to ... merging", which is why I brought this up. Fetch will never cause any issues here, but pull might, because pull involves running `git merge` or `git rebase`. – torek Sep 07 '21 at 18:23
  • 1
    It's not in `.gitignore`. It was, for a time, but isn't now. It’s possible Xcode is deleting it and we're not noticing when we commit it. – Rick Sep 07 '21 at 18:26
  • I don't know if or why Xcode might delete it (I avoid Xcode as I'm allergic to IDEs ). *Something* is definitely deleting it; Git would only do that on a `git merge` if it were "deleted" on one "side" of the merge, i.e., `git diff --find-renames ` claims that the status of the file is `D`. If the file exists under that name in all three commits, Git won't claim it is `D`eleted. Other than these, I have no idea what's going on here. – torek Sep 07 '21 at 18:29
  • I am also facing similiar issue. did you find any solutions> – venky Jun 18 '22 at 00:52
  • No. I think other engineers on the team had something wonky. I think it just stopped happening eventually. – Rick Jun 18 '22 at 07:28

0 Answers0