I'm getting some odd behavior when trying to stash changes. I'm not a git expert so I'm hoping someone can shed some light on this:
On an up-to-date branch, I modify a tracked file. git status shows it as modified
git stash (responds with "Saved working directory and index state WIP on...)
git status still shows the file as modified, but git diff (and git gui) show no changes.
git stash list shows the stash was created
git stash pop responds with "error: Your local changes to the following files would be overwritten by the merge:"
The behavior at 3 makes no sense to me. It started happening fairly recently. I've been using stash/stash pop for several months with no problems.
I wondered whether there was an issue with my local working copy so I re-cloned but get the same behavior.
Is my GIT installation broken, or am I missing something?
Additional info:
Tried this on another PC and it behaves as expected, so it's something to do with this installation.
Tried creating a new local repo, add & commit 1 file, modify, stash. Same behavior
Tried with files with CR LF and LF line endings. Same behavior
git config -l:
core.symlinks=true
core.autocrlf=true
core.fscache=true
color.diff=auto
color.status=auto
color.branch=auto
color.interactive=true
help.format=html
diff.astextplain.textconv=astextplain
rebase.autosquash=true
http.sslcainfo=C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crt
http.sslbackend=openssl
diff.astextplain.textconv=astextplain
filter.lfs.clean=git-lfs clean -- %f
filter.lfs.smudge=git-lfs smudge -- %f
filter.lfs.process=git-lfs filter-process
filter.lfs.required=true
credential.helper=manager
core.editor='C:\Program Files (x86)\Notepad++\notepad++.exe' -multiInst - notabbar -nosession -noPlugin
core.excludesfile=C:\GIT\gitignore\VisualStudio.gitignore
core.editor=notepad
core.fscache=true
core.preloadindex=true
gui.fontdiff=-family Consolas -size 10 -weight normal -slant roman - underline 0 -overstrike 0
gui.recentrepo=C:/GIT/polarisv4
filter.lfs.clean=git-lfs clean -- %f
filter.lfs.smudge=git-lfs smudge -- %f
filter.lfs.process=git-lfs filter-process
filter.lfs.required=true
user.name=xxxxx
user.email=xxxxxx
difftool.sourcetree.cmd='C:/Program Files/TortoiseGit/bin/TortoiseGitMerge.exe' "$LOCAL" "$REMOTE"
mergetool.sourcetree.cmd='C:/Program Files/TortoiseGit/bin/TortoiseGitMerge.exe' -base:"$BASE" -mine:"$LOCAL" - theirs:"$REMOTE" -merged:"$MERGED"
mergetool.sourcetree.trustexitcode=true
alias.co=checkout
alias.br=branch
alias.st=status
winupdater.recentlyseenversion=2.15.1.windows.2
credential.helper=manager
core.repositoryformatversion=0
core.filemode=false
core.bare=false
core.logallrefupdates=true
core.ignorecase=true
As DaveW said the problem comes from the core.fscache=true setting. This is a Windows only setting that enable a file system cache in order to mitigate slowness of some Windows file system operations. Here is the description extracted from the commit message Win32: add a cache below mingw's lstat and dirent implementations:
Checking the work tree status is quite slow on Windows, due to slow
lstat emulation (git calls lstat once for each file in the index).
Windows operating system APIs seem to be much better at scanning the
status of entire directories than checking single files.
Add an lstat implementation that uses a cache for lstat data. Cache
misses read the entire parent directory and add it to the cache.
Subsequent lstat calls for the same directory are served directly from
the cache.
Also implement opendir / readdir / closedir so that they create and
use directory listings in the cache.
The cache doesn't track file system changes and doesn't plug into any
modifying file APIs, so it has to be explicitly enabled for git
functions that don't modify the working copy.
The last sentence of this commit message gives an indication of the cause of the OP problem.
At Ortomala Lokni's suggestion, I removed all global git config files 1.
The problem went away. I reinstated each file until the problem returned and then fiddled with settings that seemed like reasonable candidates.
The culprit was fscache - setting true causes the problem. I have no idea why as the same setting works fine on other PCs.
Thanks everyone for your help!
Related
I am using Git for Windows 2.5.1 under Windows 7 x64.
I am experiencing a strange phenomenon, that is...
...whenever I use Right-Click / Git Bash Here... on a plain directory that is not under the control of git (i.e. there is no .git directory present), a new subdirectory .git gets automatically created (with a file "config" in it), however, no git command has been issued.
I went into my registry settings and I found that the "Git Bash Here..." shortcut translates into "git-bash.exe" "--cd %v".
My question is as follows: is there any way to tell "git-bash.exe" * NOT * to create any .git folder (at least not as long as no git command is issued)
The problem is that I use "Git Bash Here..." all over the place, even for directories that are not under the control of git, and what happens is that my harddisk is now littered with many empty, useless .git directories.
I was thinking, maybe there is an additional option to prevent the creation of .git/config ?
Maybe git-bash.exe --cd %v --do-not-create-git-config ?
Any ideas ?
Thanks for #poke's comment
In fact, in my ".bashrc" I had a left-over from last week's testing: "git config color.diff auto"
I had forgotten to remove that line.
When I remove the "git config color.diff auto", everything goes back to normal
Problem solved
I use git on windows. In my project I changed case of filename. After that checkout of previous commits failed (commands are in Git Bash):
mkdir repofolder
cd repofolder
git init # create empty repo
git config core.ignorecase false # turn on case-dependent filenames
# create 'readme.txt'
$ echo "blahblahblah" > readme.txt
$ git add readme.txt
$ git commit -m "+readme.txt"
# rename it to 'README.txt'
$ git mv -f readme.txt README.txt
$ git commit -m "readme.txt => README.txt"
$ git status
On branch master
nothing to commit, working directory clean
$ git checkout HEAD~1
error: The following untracked working tree files would be overwritten by checkout:
readme.txt
Please move or remove them before you can switch branches.
Aborting
Why git doesn't allow to checkout previos commits?
You face with the same problem when delete one file and append another one with the same name, but different case. No matter how many commits you do: one (removing and appending in the same commit) or two commits (in first commit you remove file, in second you add another one).
On Windows git can't handle files with the same name but in different case properly
Git on Windows can't handle it because Windows itself can't handle it (emphasis mine):
As part of the requirements for POSIX compliance, the Windows NT File System (NTFS) provides a case-sensitive file and directory naming convention. Even though NTFS and the POSIX subsystem each handle case-sensitivity well, 16-bit Windows-based, MS-DOS-based, OS/2-based, and Win32-based applications do not.
In truth, Windows does have some level of support for NTFS case-sensitivity, but it's pretty flaky:
However, if you attempt to open one of these files in a Win32 application, such as Notepad, you would only have access to one of the files, regardless of the case of the filename you type in the Open File dialog box.
Other inconsistencies also exist. The Windows NT Command Prompt and File Manager correctly display the names of the files. However, normal commands, such as COPY, fail when you attempt to access one or more filenames that differ only in case.
In the move from C9 to hosting on my Macbook via SSH, I've had to re-download Kohana and change some other things just to get my site working; I don't want those to be committed. Is there any way to untrack all tracked files so only future changes are committed? Or is there something else I should be doing?
I'm on a Macbook running Mountain Lion with Apache and PHP turned on.
Even simpler:
cd /root/directory/of/your/local/repo
git rm --cached -r .
^^^
(space - dot)
Even even simpler:
git clone url/for/Kohana /different/local/path
git rm --cached File
Will delete the file in the index, so it will no longer be tracked, but won’t physically delete it. This will untrack the file only for current branch
[OR]
Use this git command. After you do this, git stops checking the file for possible modifications.
git update-index --assume-unchanged <filename>
At any time, you can track again by setting --no-assume-unchaged flag
git update-index --no-assume-unchanged <filename>
But these command do not affect the remote repository.
I'm not exactly sure what you mean by "untrack all tracked files so only future changes are committed". As you need to track files so they can be committed.
If all you just want to do is not track Kohana and the other downloads, then just remove them from your working directory using git rm --cached <file> or even better create a .gitignore file.
There are many helpful posts on stackoverflow to assist you with creating a .gitignore file for your project. By using this, you can exclude an entire folder easily.
For Mac, it would also be helpful if you could see hidden file as the . file is hidden. This page shows you how to see hidden files on Mountain Loin - http://www.mikesel.info/show-hidden-files-mac-os-x-10-7-lion/
I have an XML file that we consider binary in git. This file is externally modified and committed.
I don't care about who edited it and what's new in the file. I just want to have the latest file version at every pull. At this time, at every git pull I have a merge conflict.
I just want that this file is overwritten on every git pull, without manually doing stuff like git fetch/checkout/reset every time I have to sync my repo.
Careful: I want to overwrite just that file, not every file.
Thanks
I thought you could use Git Hooks, but I don't see one running before a pull...
A possible workaround would be to make a script to delete this file and chain with the needed git pull...
This answer shows how to always select the local version for conflicted merges on a specific file. However, midway through the answer, the author describes also how to always use the remote version.
Essentially, you have to use git attributes to specify a specific merge driver for that specific file, with:
echo binaryfile.xml merge=keepTheirs > dir/with/binary/file/.gitattributes
git config merge.keepTheirs.name "always keep their file during merge"
git config merge.keepTheirs.driver "keepTheirs.sh %O %A %B"
git add -A
git commit -m "commit file for git attributes"
and then create keepTheirs.sh in your $PATH:
cp -f "$3" "$2"
exit 0
Please refer to that answer for a detailed explanation.
If the changes to your files are not actual changes, you should not submit them. This will clutter your version history and cause numerous problems.
From your statement I’m not quite sure which is the case, but there are 2 possibilities:
The file in question is a local storage file, the contents of which are not relevant for your actual sourcecode. In this case the file should be part of your .gitignore.
This file is actually part of your source and will thus have relevant changes in the future. By setting up the merge settings like you are planning to do, you will cause trouble once this file actually changes. Because merges will then be destructive.
In this case the solution is a little bit more complicated (apart from getting a fix for the crappy tool that changes stuff it doesn’t actually change …). What you are probably looking for is the assume unchanged functionality of git. You can access it with this command:
git update-index --assume-unchanged <file>
git docu (git help update-index):
You can set "assume unchanged" bit to
paths you have not changed to cause git not to do this check. Note that setting this bit on a path does not mean git will check the
contents of the file to see if it has changed — it makes git to omit any checking and assume it has not changed. When you make changes
to working tree files, you have to explicitly tell git about it by dropping "assume unchanged" bit, either before or after you modify
them.
I have imported a rather large repository from another SCM into git. Unfortunately the migration was done (had to be) on Windows and every file got committed into git with the execute bit set. To avoid having to do the migration again (it is a long and hang-prone process) I am trying to figure out if I can clean out the executable bit server side. My thought is using git filter-branch somehow combined with git update-index, but I could take hints as to how to proceed.
Doing a huge commit at the end clearing all executable bits is not a solution -- I don't want every file to have a bump in the history.
This seems to do the trick:
git filter-branch --index-filter 'git ls-files -s |
sed s/^100755/10644/ |
git update-index --index-info' -- --all
Your solution is quite good, but there is another possibility: git config core.filemode false:
http://git-scm.com/docs/git-config
core.fileMode
If false, the executable bit differences between the index and the working copy are ignored; useful on broken filesystems like FAT. See git-update-index(1).
The default is true, except git-clone(1) or git-init(1) will probe and set core.fileMode false if appropriate when the repository is created.
This may create more work for everyone who has to clone the repo in the future (or it may not, I'm not really sure), so your solution is probably better, but I thought I'd throw this out there as it may be more appropriate for someone else's use case...