0

I have a strange discrepancy between my local git and the one on GitHub. Both repos are at the same level but the local one has modifications (a few commits in the past) that the GitHub one did not register at the file level (the commit is there).

I noticed that for some reason .git was in my .gitignore file, I removed it, commited, and pushed but nothing changed (removing .git form .gitignore did not trigger any new files to be committed).

As an example, I have a file CurrentTime.vue locally, but it is currentTime.vue on GitHub. That was indeed the old name of the file, changed a few commits ago (and this commit is present on GitHub as well).

I have a single, linear branch (master).

My questions:

  • is it possible that for identical repos, with the same history, there would be a difference between them?
  • if so - is it possible to force a push of the complete repository so that they become identical (I guess this is equivalent to deleting/recreating the GitHub repo)?
WoJ
  • 27,165
  • 48
  • 180
  • 345
  • 2
    Are you working on Windows or a Mac (i.e. a case-insensitive filesystem), and are the only changes you're missing capitalizations of filenames? – CodeCaster Oct 02 '22 at 10:22
  • @CodeCaster: I work on Windows 10. The change of casing was correctly caught by the commit. – WoJ Oct 02 '22 at 10:27
  • Are there any other changes that are not about capitalization of file names? – tymtam Oct 02 '22 at 11:13
  • Can you show us that gitHub shows the name in the commit? – tymtam Oct 02 '22 at 11:30
  • Related, but not identical: [Change case of a file on Windows?](https://stackoverflow.com/q/1793735/1256452), [How to deal with case sensitive files in git?](https://stackoverflow.com/q/68455900/1256452), [Changing capitlization of filenames in Git](https://stackoverflow.com/q/10523849/1256452) – torek Oct 02 '22 at 15:43

2 Answers2

2

Ripley: ... nuke the entire site from orbit. It’s the only way to be sure.

If your local repo is the source of truth then rename->recreate may be the solution.

However, you can:

  • git mv currentTime.vue CurrentTime.vue and see if the change is now correctly processed.
  • Install "Windows Subsystem for Linux" (it's easy) and look at your repo there. Linux is a case-sensitive operating system and will highlight all case changes.
tymtam
  • 31,798
  • 8
  • 86
  • 126
  • I finally found (and published) the solution - thank you for your comment about looking closely at the commit to make absolutely sure that the case was taken into account. Thank you. – WoJ Oct 02 '22 at 11:56
0

This ended up being a setting in the local repo .git/config, I had ignorecase = true in [core].

After carefully reviewing the commit, I realized that there were changes to (for instance) currentTime.vue (lower case) and I took them for also being a rename.

This search was triggered by @tytam's comment about looking again at the commit. Thank you.

WoJ
  • 27,165
  • 48
  • 180
  • 345
  • 1
    You *should* have `ignorecase = true` if your system ignores case, i.e., considers the file names `currentTime.vue` and `CurrentTime.vue` to name the same file. Git needs to know this—to know how *your system* behaves—and that's why `core.ignorecase` exists. You can sometimes change this setting briefly to *trick* Git into doing something useful, but once you've done that, always put it back to the way it should be for your sytem. – torek Oct 02 '22 at 15:39
  • @torek understood, thank you. I now realize I should have had changed the case via `git mv -f` instead that doing it on the OS level. – WoJ Oct 02 '22 at 17:19
  • Yeah, the official guide says: "Git relies on the proper configuration of this variable for your operating and file system. Modifying this value may result in unexpected behavior." – tymtam Oct 03 '22 at 03:57