I'm sadly aware of the difficulty in debugging this, so thank you for caring! The code isn't super sensitive so I'll try to get approval to share it (privately) but the client might insist on a background check (commercial). I'll only do this with your consent, and after we have exhausted all other options. > Is the repo you are talking about public ? The repo isn't public but it is hosted on github (private). The main reason I reported it is that github was able to rebase the two branches with no conflicts, so the problem seems to be related to my local copy, which I made a backup of before cloning the merged one so I could try to answer some of these questions. Some weirdness (5xx errors) started happening to our deploy pipeline a bit after CI picked up the new branch which might suggest that something similar happened with those copies, but it seems to have recovered so it was either an unrelated fluke, or this something that only happens on certain versions of git. > Does settings/local.py exist is both branches, origin/test and main ? I can't really tell you what `main` contains at the moment since I don't know how to open it, but assuming it was up to date with `origin/main` (high likelihood: it was stale for almost two years prior to yesterday), then `settings/local.py` only exists on `test`. The two branches have diverged significantly over time: CI picks up `main` and deploys it to production (this would have been the first such deploy), whereas `test` is deployed to staging and has been the main merge target thus far. What does git ls-files --eol setings/local.py give you ? Nothing: % git ls-files --eol setings/local.py % > Is there a .gitignore, which is different on both branches ? Yes, this is what I too suspect is the root cause. A placeholder `settings/local.py` file was added to `test`, and then gitignored so that devs can override their own settings without pushing them back. In this case, the error message makes a lot of sense since that is exactly what would be happening: since `main` does not have a corresponding file, all local changes would be lost. The files are however bit for bit identical: 9b4988c3a70e41db3b5ef8eb2d9d1eb92fc08c68 settings/local.py <-- `test` in bugged repo 9b4988c3a70e41db3b5ef8eb2d9d1eb92fc08c68 settings/local.py <-- `test` after reset --hard Weirdly enough, the error goes away after the hard reset and I am able to checkout `main` even though the conflicting file wasn't changed (other than maybe some internal flag) > The error message as such is probably the best information that Git has, Mentioning gitignore in this case might be a good idea though > what does git add --renormalize . give you ? (Please do not omit the '.') That also solves it! git add --renormalize . git status On branch test Your branch is up to date with 'origin/test'. % git checkout main branch 'main' set up to track 'origin/main'. Switched to a new branch 'main' So it seems like there's a dirty flag that's not updated to reflect the shasum. In my book, we can write this one off as random bit flip caused by a cosmic ray but if you'd rather investigate it further, let me know how I can help; I've kept an archive of the offending repo just in case. Thanks and best wishes! On Fri, Jul 21, 2023 at 9:58 AM Torsten Bögershausen <tboegi@xxxxxx> wrote: > > On Fri, Jul 21, 2023 at 12:52:30AM +0300, Radu Dan wrote: > > Thank you for filling out a Git bug report! > > Please answer the following questions to help us understand your issue. > > > > > What did you do before the bug happened? (Steps to reproduce your issue) > > > > % git stash > > No local changes to save > > > > % git commit -m wtf > > On branch test > > Your branch is up to date with 'origin/test'. > > > > nothing to commit, working tree clean > > > > % git checkout main > > error: Your local changes to the following files would be overwritten > > by checkout: > > settings/local.py > > Please commit your changes or stash them before you switch branches. > > Aborting > > First of all: thanks for your feedback. > However, the situation on your local disk is hard to debug from remote. > Which could be frustrating on both sides, so to say. > > So we may come further by asking some questions: > - Is the repo you are talking about public ? > Does settings/local.py exist is both branches, origin/test and main ? > - What does > git ls-files --eol setings/local.py > give you ? > > - Is there a .gitignore, which is different on both branches ? > - What does > git ls-files | grep -i local.py > give you ? > > > > > > > > What did you expect to happen? (Expected behavior) > > > > Switch to `main` > > > > > What happened instead? (Actual behavior) > > > > Still on current branch > > > > > What's different between what you expected and what actually happened? > > > > Better error message > > The error message as such is probably the best information that Git has, > the question is, which changes does Git see ? > > Another question : > what does > git add --renormalize . > give you ? (Please do not omit the '.') > > > > > > > > Anything else you want to add: > > > > First bug in 10 years of usage, great work! > > > > > Please review the rest of the bug report below. > > > You can delete any lines you don't wish to share. > > > > [System Info] > > git version: > > git version 2.39.2 (Apple Git-143) > > cpu: x86_64 > > no commit associated with this build > > sizeof-long: 8 > > sizeof-size_t: 8 > > shell-path: /bin/sh > > feature: fsmonitor--daemon > > uname: Darwin 22.5.0 Darwin Kernel Version 22.5.0: Thu Jun 8 22:22:22 > > PDT 2023; root:xnu-8796.121.3~7/RELEASE_X86_64 x86_64 > > compiler info: clang: 14.0.3 (clang-1403.0.22.14.1) > > libc info: no libc information available > > $SHELL (typically, interactive shell): /bin/zsh > > > > > > [Enabled Hooks]
