5

I can't quite get my head around, why a freshly cloned git repository shows that there are changes not stagged for commit.

Here is a short example:

    [dpetrov@macbook-pro ~/work]$ git clone /tmp/git/pollers.git pollers
    Cloning into 'pollers'...
    done.
    [dpetrov@macbook-pro ~/work]$ cd pollers/
    [dpetrov@macbook-pro ~/work/pollers (master)]$ git status
    On branch master
    Your branch is up-to-date with 'origin/master'.

    nothing to commit, working tree clean
    [dpetrov@macbook-pro ~/work/pollers (master)]$ git checkout pollers-1.0
    gBranch pollers-1.0 set up to track remote branch pollers-1.0 from origin.
    Switched to a new branch 'pollers-1.0'
    i
    [dpetrov@macbook-pro ~/work/pollers (pollers-1.0)]$ git status
    On branch pollers-1.0
    Your branch is up-to-date with 'origin/pollers-1.0'.

    Changes not staged for commit:
      (use "git add <file>..." to update what will be committed)
      (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   share/mibs/IANAifType-MIB.mib

    no changes added to commit (use "git add" and/or "git commit -a")
    [dpetrov@macbook-pro ~/work/pollers (pollers-1.0)]$ git diff share/mibs/IANAifType-MIB.mib
    diff --git a/share/mibs/IANAifType-MIB.mib b/share/mibs/IANAifType-MIB.mib
    old mode 100644
    new mode 100755
    index 3b4added..14da8028
    --- a/share/mibs/IANAifType-MIB.mib
    +++ b/share/mibs/IANAifType-MIB.mib
    @@ -1,13 +1,11 @@
    --- Extracted from http://www.iana.org/assignments/ianaiftype-mib
    ---
    -   IANAifType-MIB DEFINITIONS ::= BEGIN
    +IANAifType-MIB DEFINITIONS ::= BEGIN^M

   IMPORTS
        MODULE-IDENTITY, mib-2      FROM SNMPv2-SMI
        TEXTUAL-CONVENTION          FROM SNMPv2-TC;

    ianaifType MODULE-IDENTITY
-       LAST-UPDATED "200505270000Z"  -- May 27, 2005
+       LAST-UPDATED "200411220000Z"  -- June 17, 2004^M
        ORGANIZATION "IANA"
        CONTACT-INFO "        Internet Assigned Numbers Authority

Any clues how to debug that and what might be causing it?

Thanks so much.

Dimitar Petrov
  • 667
  • 1
  • 5
  • 16
  • Did you checked if those branches are perfectly the same? As you cloned from 'origin/master' and checked out to 'origin/pollers-1.0' seems like the differences between the branches are what you seeing as unstaged commits – Gabriel Rodrigues Jan 10 '18 at 13:26
  • @RômuloGabrielRodrigues nope, it even happens on the master branch without checking out any branches. Could it be a bad merge made into the bare repo? – Dimitar Petrov Jan 10 '18 at 20:04
  • 1
    @DimitarPetrov what do you mean by 'it even happens even on the master branch'? In the example we see there is no changes on master > nothing to commit, working tree clean – Rumid Jan 11 '18 at 12:40
  • Also have you checked this solutions: https://stackoverflow.com/questions/14564946/git-status-shows-changed-files-but-git-diff-doesnt https://stackoverflow.com/questions/5787937/git-status-shows-files-as-changed-even-though-contents-are-the-same ? – Rumid Jan 11 '18 at 12:42
  • @Rumid in the example above there was nothing, but when I checked out it locally, even the master branch was displaying there is diff. Turned out, that there were case sensitive files, that were causing troubles when checked out on my mac. – Dimitar Petrov Jan 11 '18 at 22:03
  • So the question is misleading, feel free to close it, or edit it if it is not the duplicate to one I mentioned. Also this one might help: https://stackoverflow.com/questions/2825428/why-should-i-use-core-autocrlf-true-in-git – Rumid Jan 12 '18 at 06:07
  • It's not duplicate, as the 2 files are different: so you have example.xml and ExamPLE.xml which are two different file with different content. Depending on the filesystem those are displayed either as diff or shown just fine. the reason I didn't pick it up, when I opened the ticket, was that I was testing on remote machine which is running Linux and later on tested on my Mac. I am pretty sure I found the answer somewhere on stackoverflow, so will just close it as duplicat.e – Dimitar Petrov Jan 12 '18 at 07:30
  • I have the same issue, freshly cloning a repository, in a Mac – Sourcerer Dec 26 '18 at 17:13
  • Does this answer your question? [Why should I use core.autocrlf=true in Git?](https://stackoverflow.com/questions/2825428/why-should-i-use-core-autocrlf-true-in-git) – LeGEC Jul 05 '20 at 08:40

1 Answers1

0

It was a case sensitivity issue in the file names : two different files, with only difference in casing in their names, were stored in git.

When checking the differences, git would receive the "wrong" content for one of the two names.

LeGEC
  • 46,477
  • 5
  • 57
  • 104
  • old question, self answered in the comments. Just adding a post to state "there is an answer". – LeGEC Jul 05 '20 at 09:05