1

I'm fairly new to using git and I've dug myself in to a hole a couple of times where one of my git commits ends up modifying files that do not show up when doing a git status. I'm curious if anyone knows might cause my local repository to get in to such a state since I seem to need to re-clone the repository to fix my issue.

An example git status with one unstaged file.

User@User-DESKTOP:~/code/tap$ git status                                                    
On branch what-is-programming                                                            
Changes not staged for commit:                                                           
  (use "git add <file>..." to update what will be committed)                             
  (use "git restore <file>..." to discard changes in working directory)                  
        modified:   exampleFile.cs   

no changes added to commit (use "git add" and/or "git commit -a")

Then I add the file

User@User-DESKTOP:~/code/tap$ git add .
warning: LF will be replaced by CRLF in exampleFile.cs
The file will have its original line endings in your working directory

Then I commit the file

User@User-DESKTOP:~/code/tap$ git commit -m "some message" [what-is-programming bd86d6b] some message
 3 files changed, 88 insertions(+), 186 deletions(-)
 create mode 100644 someFileIDontExpect.cs
 delete mode 100644 anotherFileIDontExpect.cs

If I do a diff against the previous commit it shows what I expect

User@User-DESKTOP:~/code/tap$ git diff --name-status HEAD~
M       exampleFile.cs

Same if I diff against master

User@User-DESKTOP:~/code/tap$ git diff --name-status master
M       exampleFile.cs

But when I push to github, it shows me creating someFileIDontExpect.cs and deleting anotherFileIDontExpect.cs.

The potential places I see me doing "weird" stuff that I sometimes do a git commit -m "WIP" and then later a git reset --soft HEAD~ to continue working on the WIP commit. I've found the workflow better than git stash but maybe it creates issues? I'm not exactly sure how to figure out what is broken since diffing my commit seems fine but once it gets to github it is very much in an unexpected state.

We're also using git-lfs but this is occurring with source files so I'm not sure it's having an impact.

Thanks for any insight you could provide! I'm very curious how I'm breaking things.

EDIT

@mkrieger1 you're right that git add . adds all the files in my working directory but git status did not show any other unstaged files. Also the git diff of my commit shows no other added or modified files.

@matt I'm not sure I follow. git diff --name-status HEAD~ should list the added or modified files from the previous commit right? It shows only the exampleFile.cs as being modified even though my commit message showed someFileIDontExpect.cs being created and anotherFileIDontExpect.cs being deleted. I expect git diff --name-status master to show me the changes in my branch what-is-programming that are not in master and they also show just exampleFile.cs as being modified. My local copy of master matches the remote so why when I push do the two other files show up in a pull request? Is there something I should be diffing against to see what will show up in my pull request?

Peter G
  • 11
  • 3
  • `git diff --name-status HEAD~` and `git diff --name-status master` do not do what you think they do. I think you think they compare the commit you just made `what-is-programming` to something. They don't. They compare the _work tree_ to something. So they add nothing to what you already knew. – matt Apr 06 '20 at 20:37
  • `git add .` adds *all* files in the current directory, not just the one you intended. – mkrieger1 Apr 06 '20 at 20:53
  • The way to reply to a comment is with a _comment_. And when you do, address the commenter by name. Otherwise we won't hear you. For example, comment "@matt ..." if you want me to hear you. – matt Apr 06 '20 at 22:43
  • Consider finding out the raw hash ID of the commit(s) in GitHub that you will compare to, and then doing `git diff HEAD` after doing `git commit`, to see what the difference is from that commit—specified by hash ID—and the one you just made, specified by HEAD. – torek Apr 06 '20 at 22:45
  • Besides this, consider running `git fetch` followed by `git log --all --graph --decorate --oneline` to see the commit graph of what you're working on now, vs what your Git can get from their Git via `git fetch`. Or, you might prefer some graphical user interface to view commits. – torek Apr 06 '20 at 22:46
  • Have you used `git rm` on `anotherFileIDontExpect.cs`? – liuwenzhuang Apr 07 '20 at 07:51
  • I think what you want is `git diff origin/master HEAD` then you see all your changes between the local repo and the remote repo. – jugendhacker Apr 07 '20 at 10:08
  • @torek I'll try that out next time. I have done just a normal `git log` and it seemed expected. @liuwenzhuang I did. I've even done a `git clean -fd`. @jugendhacker I can try that the next time I get in to this situation but doing a `git reset --hard origin/master` on my master branch produced no changes so I'm not sure diffing against `origin/master` will change the result. – Peter G Apr 07 '20 at 15:03
  • Given that you're on Windows and that this seems to be a common occurrence for people working with `.cs` files there (whatever those are), I'm suspicious that you're running into a name-case-folding issue, where someone has put two different files named `LOUD.CS` and `loud.cs` into your repository. Your Windows system is literally incapable of storing both files, while your Git (which only uses Windows to let you *modify* files—it has its own internal storage for exchanging with other Gits) can store both. But you've obscured the actual names here, so it's hard to be sure about this. – torek Apr 07 '20 at 19:42
  • @torek, `.cs` files contain code written in C# (hence the name derived from **cs**harp). – kostix Apr 09 '20 at 12:55

1 Answers1

0

Just went through the same issue. I also do the same as you, WIP commits and a reset --soft to continue working, so it could be the same cause.

With a git reset --soft, the changes remain staged. I was using git restore --staged * to remove all files in the staging area and later do smaller commits. The same problem was happening, adding only 2 files resulted in a commit with a lot more changes, even though they were not listed as staged with a git status.

What solved for me was doing the same steps, but changing the command:

git restore --staged *

to

git restore --staged .

Note the difference between * (all) and . (current directory).

I suspect that the files not supposed to be commited somehow remain added to the staging area, but are not listed with a git status and are not recognized by the * argument, as it probably refers to all staged files. It is a guess, don't really know.

Lucas Falabretti
  • 1