git on Mac sees files I havent touched as modified and they also appear as staged already - windows

I am seeing strange behavior on Mac with git. I dont see this happening on Windows. Using git v 2.19.1 on mac and 2.18.0.windows.1 on windows.
I work in a crossplatform team, so some of us use Windows, others use Mac. I use both.
Here is the scenario I see:
I work on my feature branch for few days and like to make sure I update my branch with latest changes on remote so I always work on most recent version of remote. So, I daily do following to reduce chance of conflicts and stay on most recent version:
git checkout develop
git fetch origin
git merge origin/develop
git checkout my-feature
git merge develop
Once that is done, I apply my changes to my-feature branch but I notice that git behaves very strangely on Mac. Here is what happens:
I added some changes
I did not stage anything yet, so no git add . was issued
I do git status and I see lots of files as if they got modified and staged by me even though I did neither modified nor staged them.
For example, git status shows my .gitignore file now as:
me$ git status
On branch my-feature
Your branch is up to date with 'origin/my-feature'.
Changes to be committed:
new file: .gitignore
On Windows, this does not happen and since I did not modify this file, it will not show in git status at all. My modified files show as needed to be added which is how it should behave.
Why would files I never touched be viewed by git on Mac as somehow modified and staged?

In mixed dev environments (like I work in also) I see this behavior when 'line endings' are mismatched. The best way to solve this is to update your .gitconfig file.
I encourage everyone on the teams I work within to add the following to their .gitconfig file. You can add a .gitconfig to each repo, just like a .gitignore, and/or each developer can set it within their git global config file.
[text]
eof=lf
There are different options, but the key is for the whole team to use the same line endings when committing & pulling.
Here is my gitconfig, per the request below.
[User]
name = Ben Horgen
email = xxx#xxxxxxxx.com
[text]
eof=lf
[core]
autocrlf = input
[pull]
rebase = true
[push]
default = simple

Related

Cannot git checkout master: invalid path '?'

After an "unsuccessful" git pull on my local master, an error prevents to switch back to master:
C: repo_folder> git checkout master
error: invalid path '?'
The ? must be because it is a keybase repo.
From another branch where I checked out some files of the last commit:
C: repo_folder> git diff origin/master --compact-summary
"\004" (gone) | 1902 ---------------------------
some irrelevant stuff | (num) -
The removed file "\004" (that was never present in my local) seems to come from some Mac OS (someone might have opened a csv and a temporary file was created when that user did the commit and pushed?).
observe that the file that is marked as (gone) is to be removed by git
the problem is that the filename has characters that are not compatible with the Windows file system and that the file never existed in my local Windows repo.
If I clone from a Linux platform, I can checkout to master with no problems. However, in Windows, there's no way back to the master branch.
Any ideas on how to solve this issue? (already tried some posts with no success)
I can't really understand how it comes git doesn't even allow me to checkout to master. Should I file a bug report?
Alternatively, perhaps I could create a new master branch and get rid of the current one.
EDIT
A clone from Linux helped to identify that the file ? was actually there.
This could be checked directly from Windows as well by using the command: git ls-tree origin/master (which was showing the original problematic name "\004")
The accepted answer includes the case where you want to save the content of the file, while in my case I only wanted to get rid of it. So in my case, I have just deleted the file from Linux, committed and pushed the change, and did a git fetch origin master:master to fetch my local master with being checked out in another branch (as I was not able to checkout to master). This finally did the trick and I could checkout to master.
Hope this clarifies to someone with a similar problem.
? (or maybe it's EOT) cannot be used as a filename on Windows. The file will have to be deleted or renamed. You can do this most easily by cloning on a system which does allow ? and making the fix.
If you only have Windows, Fixing Invalid Git Paths on Windows offers a method of renaming the file without checking it out. In brief...
git checkout origin/master -f to get the checkout without the problematic file.
Make a branch.
Add and commit the "deleted" problematic file.
Use git ls-tree HEAD^ to get the ID of the problem file.
Use git cat-file -p <ID> to get the content of the problem file.
Put the content into a new file.
Add and commit.

Is it possible to fix Windows altered case of file names with pull from remote git repo?

I have a problem where a Windows file restore changed the case of some file names. This causes a trainwreck with some projects.
Fortunately these projects are pushed to remote git servers. The remotes are up to date with origin/master, and cloning the projects is a solution. The only problem with that is the time-consuming task of replacing git-ignored files and dealing with other updates.
An ideal solution would be to pull down all files from the remote, overwriting the files in the origin/master. Is this possible? How do I force a pull down or merge, even though they are already a match. I want to keep it that way, just use git to rewrite the correct file name cases.
git pull or git pull -f results in Already up-to-date.
First, set git to be case sensitive. By default this was set true to match Windows:
git config core.ignorecase false
Check the list of changed-case file names Windows messed up. At the very least, this is your list of files to fix:
git status
Now, delete the files and folders that are messed up. Do not delete git ignored files! Files in .gitignore must be fixed the hard way.
Now, get your deleted files back as they were before Windows changed the case:
git checkout .
Yet another reason to quit Windows.

Git status is clean even though a file has changed

I have spent a great deal of time since I first started using Git struggling with files being reported as changed when they hadn't been touched, and core.filemode = false resolved those issues... but today I have the reverse problem. (Unless otherwise specified, I'm doing this from Git Bash (1.7.10.msysgit.1) in Windows 7.)
The situation:
On my master branch, I did git pull upstream master to pull the latest changes - this said everything was up to date (I double-checked and the last commit is the same on my local master, my origin fork and the upstream Github repo so I'm reasonably certain this is correct)
I amended an existing file. The diff in TortoiseGit 1.8.0.0 shows the changes, though its overlay still shows the directory as clean. Odd. git status is... still clean. Very odd.
I delete a file: rm Readme.md. File disappears. git status is still clean. Clearly, git isn't actually tracking my files anymore.
(For the record, setting core.filemode = true and then running git status just gave me nonsense about files whose mode changed at some point between my Windows system and Github, but still didn't list the deleted or the truly modified files)
I'm missing something here and I hope someone can tell me what it is! I've done dozens of commits from this machine to that same repository via my fork on Github so I'm reasonably certain this environment works and I generally know what I'm doing, but clearly something has changed that I can't put my finger on right now.
Edit, as requested, my Git workflow as followed in Bash (didn't bother checking out a new branch as the problem occurs in master anyway):
Emma Burrows#PC ~/Documents/Dropbox/gitproject (test)
$ git checkout master
Switched to branch 'master'
Emma Burrows#PC ~/Documents/Dropbox/gitproject (master)
$ git status
# On branch master
nothing to commit (working directory clean)
Emma Burrows#PC ~/Documents/Dropbox/gitproject (master)
$ git pull upstream master
From git://github.com/company/gitproject
* branch master -> FETCH_HEAD
Already up-to-date.
Emma Burrows#PC ~/Documents/Dropbox/gitproject (master)
$ rm Readme.md
Emma Burrows#PC ~/Documents/Dropbox/gitproject (master)
$ git status
# On branch master
nothing to commit (working directory clean)
Readme.md is a tracked file present in both my forked repo on Github and in the original upstream repo. I hope that helps?
NEW EDIT I've moved the folder out of Dropbox to a local folder on a local drive, but the problem remains the same. The .git folder must be poked. I was hoping to find out what was wrong with it though.
Thank you to everyone who tried to help. The problem persisted after I moved the whole folder, including .git folder into another location on my local hard drive. I can only assume that two copies of the repo on different machines had tried to sync the git folder at once and resulted in a broken local repo. I ended up recloning the folder (out of Dropbox for now) and everything is working normally again.

Git on live Windows Server - Trying to pull from the repo but local files already modified

I have my Git repository hosted at github.com. I would like to push updates and such to github.com and then log into my Windows server and do a git pull to get my changes (that are verified to work on my local machine. Ideally I should have another server setup as my local machine settings are different from the live server. But I'm cheap.).
It seems like whenever I try to do a git pull on the server, the files seem to get modified somehow since the last pull. And so I am unable to get the update as git says I need to commit my local (Windows server) changes.
How can I use git like I want to? Or is there a better way?
Is it possible you change the git core.autocrlf flag after cloning the repository?
Issue 83 on the google code project form msysGit goes deeper in on this topic.
If that it the case, doing a new clone should fix the problem (as long as the flag is not touched).
Are you using the Git GUI or Git Bash?
For some reason, Git GUI on Windows does not have core.autocrlf configured by default when cloning a repo, even after attempting to set core.autocrlf in the global configuration using Git Bash (might be GUI setting or environment issue that if corrected, could make the GUI a viable option).
Also, for some reason Git GUI in some cases seems to think it's better to make a master branch in the new repo rather than using the existing branches in the repo being cloned. After Git GUI makes this master branch, it then does a checkout of this master branch immediately after the clone. Since you're using a pull and having issues, this might only have been the issue if you initially cloned using Git GUI.
Most likely, it you're core.autocrlf setting. The following steps should set up a repo for you and ensure the proper crlf settings...
Steps to Clone without Modified File Garbage:
Using the following command in Git Bash from the Windows folder clones the repo as a full copy without making an initial checkout of a branch.
git clone –n --no-hardlinks
By not checking out the branch when cloning, you now have the ability to verify your .git/config file has the correct settings for autocrlf before checking out the branch. You might want to add safecrlf just to be safe ;) To update these settings crlf settings, execute the following commands from your newly cloned Windows repo using Git Bash:
git config core.autocrlf true
git config core.safecrlf warn
To verify the changes made it correctly, open your .git/config file and you should see:
autocrlf = true
safecrlf = warn
PLEASE NOTE: You want autocrlf set to input in your Linux repo... setting to true is for your Windows repo. Also, I only use warn on safecrlf, you may want to use true.
Once you have your crlf configuration set, you can finally checkout the branch normally using git checkout .
If there are still modified files in your new local Windows clone, it's likely due to having CRLF instead of LF in your Linux repo. This can be verified by using a hex editor on the files in your Linux repo and searching to see if 0D0A is present, or if everything is just 0A as it should be.

Git - Switching branches (windows) & uncommitted changes

I'm having a hard time understanding some git/DCVS concepts. Here's what happened:
I created a git project, and imported it from an SVN repo
I made some commits
I wanted to experiment something, so I created a branch called constants-update
I switched to constants-updatebranch, moved some files, deleted others and added many more
I committed to this branch
Now I'm trying to switch to my master branch using git checkout master
I got this error: error: You have local changes to 'src/groovy/Constants.groovy'; cannot switch branches.
My understanding of DCVS is that I can switch branches at will, even if some branch has more or less files than the others, as long as I commit my files. I've tried committing with git commit -a and switching to master branch, but I have the same error.
As a side note, when I commit git warns me that LF will be replaced by CRLF and warns me about some trailing whitespaces also; after I commit I do a git status and a bunch of files always appear as #modified ....
Is this related to git/windows, or I do not understand correctly what it is supposed to happen? I just want to switch to my master branch without losing my changes in the other branch.
Lookup git-stash for changing branches while there are unsaved changes in the current branch.
You are correct in your thinking about how this should work.
However, it sounds like git is having issues with the line endings, and it thinks all your files are modified even when they aren't. I don't use git on Windows, but I was going to suggest the "core.autocrlf" option to make the crlf handling work. However, the following blog entry indicates that this might not be a good idea: http://weierophinney.net/matthew/archives/191-git-svn-Tip-dont-use-core.autocrlf.html
I solved the problem hacking my pre-commit hook (commenting these lines in .git/hooks/pre-commit with a #):
# if (/\s$/) {
# bad_line("trailing whitespace", $_);
# }
Just use the following option in .gitconfig file which resides in your users directory.
[core]
autocrlf = true
And it will solve the issue.

Resources