I've been using git on windows for years without any major issue.
However, it's been some time now that I believe I have something that tempers with my local git repositories and from time to time flags my modified files as assume-unchanged to the point I have an alias that runs all my repo files and update-index --really-refresh --no-assume-unchanged each and every one of them, and I use it nearly before every git status. But this is no way to live! :P
I had removed ConEmu from my machine in hope this might help, but didn't get any results (mind, I should probably restart my machine before). I doubt VS code has anything to do with it. I'm at lost tbh. Is there any git config value that may cause this?
Has anyone experienced a similar issue and found the evil forces that are behind this Machiavellian mechanism? I wish to name and shame it throughout the universe...
Seriously though, any help would be highly appreciated.
I had a similar problem, but on Linux. The answer from OP about git config didn't work for me but got me looking in the right direction.
The git config option core.fsmonitor was set to true (carried over from my Windows config where this was an experimental option that improved performance). On my Linux system, this causes basically no file system changes to be detected by git. Now that I've removed it, everything works just fine.
Hope this helps someone else with the same issue.
From your comment : something (some script or some other process) is setting the assume-unchanged flag on each of your files.
You may look into your .git/hooks directory (also check git config core.hooksPath to see if you have a custom hooks directory configured), or some other script/task that would pass on all the files in your repo.
If you really don't have a clue about what might be causing this : use grep -e "assume-unchanged" -r . (to try to spot a script which would run update-index --assume-unchanged), first in your repo, then in your home dir, in last resort from / ...
Ok, so after messing around with vs code, resharper and sublime text (uninstalling everything, deleting leftovers, restarting the machine and so on)- nothing was coming up as the reason behind this weird behaviour.
And then I commented out all of my gitconfig file- and the behaviour was gone. It then took me no time to figure out the reason behind this behaviour was the following configuration that was set to true:
core.ignoreStat
I have no idea how and when did it sneak into my gitconfig file and got set to true, but hopefully this will help others who may experience this.
Related
We're using svn for version control on our Mac. Its working cool. But the only problem is we're multiple devs developing together and everyone can see any file changes status inside their Xcode ( attributes next to the file ) in their Xcode except me. How to resolve this?
This is what I want (see "M" next to the file name),
Even Xcode Source Control Menu is showing no changes.
I'm not sure if there's anything to set here?
I have checkout the code again and again, but still the problem persist.
I'm not sure, why this "Working Copies" menu "iOS" is disabled? Its enabled on other machine.
Any help would be highly appreciated.
I also encountered this problem, the following is my solution, hope I can help you.
Start the terminal, enter the code in the folder.
Type the command - svn status.
The output will be similar to this
svn: E155036: Please see the 'svn upgrade' command
svn: E155036: The working copy at '/Users/chao/svn/project'
is too old (format 29) to work with client version '1.9.4 (r1740329)' (expects
format 31). You need to upgrade the working copy first.
Type the command - svn upgrade.
The problem is resolved,I wish you good luck.
SVN can define status of working copy files and directories comparing your local files with the current repository located on the remote SVN server.
I believe that checking "Refresh server status automatically" will do the job.
You can say this is true when your local files will have attributes aside (U, M etc)
Having no luck, you may run the command line tool, which is usually more verbose. More details here: https://stackoverflow.com/a/19922150/195812
I have a very strange git error here that has me totally at a loss. It's not a major blocker, but it's extremely irritating to work around all the time.
I have a working copy of a repository and, in said working copy, every time I switch from one branch to another Git tells me, after the switch has completed, that I have local modifications. A few more details:
This is on Windows
Git status shows the file(s) as changed (every line as changed, see attached screenshot for an example)
Beyond compare shows no differences; file encoding and line endings are the same, both files exact same number of bytes.
The weird thing: I can't reset the changes, whatever they are. Even deleting the file and then resetting the deletion results in a new file that is supposedly changed.
What could be going on here? I thought that it might be something to do with file attributes, but I have no idea how to check this.
Update:
VonC was correct that it was line endings that were the issue. More specifically if you have core.autocrlf set to true but any files in the repository that were previously committed with Windows line endings then you will see this issue. The reason it's impossible to reset the change is the fact that checking out the file modifies it, since Git works out that your working copy of the file is different to how it would look if you were to commit it now. Confusing, I know.
Anyway, I was able to fix the issue by making one huge commit that set all the line endings in the repository to Unix, which luckily turned out not to be as huge a pain as you might think. I followed the instructions in this post: Trying to fix line-endings with git filter-branch, but having no luck, specifically the answer by Russ Egan, which worked best for me.
Simply make sure to type (once), before the next checkout:
git config --global core.autocrlf false
That will avoid the kind of automatic eol (end-of-line) transformation that this setting (set to true by default with msysgit) does.
.gitattributes files are a better place to declare the files you want to have their eol managed.
See "git replacing LF with CRLF" for more on that setting.
As I originally posted in this question...
I had some phantom changed files that were showing as modified, but were actually identical.
Running this command sometimes works:
(Turns off git's "smart" but often unhelpful line-ending conversions)
git config --global core.autocrlf false
git config --local core.autocrlf false
But in another case I found it was due to a .gitattributes file in the root which had some line-ending settings present, which was trying to apply autocrlf for certain files even when it was turned off. That wasn't actually helpful, so I deleted .gitattributes, committed, and the file no longer showed as modified.
My Cygwin SVN client changed behavior regarding Windows ACL between version 1.6.17 and 1.7.4.
[ UPDATE: SVN 1.7.4 and 1.6.17 have the same behaviour actually. The problem lies elsewhere. What I didn't get is the point where it stopped working, probably a Cygwin update. ]
[ UPDATE: The Cygwin-built SVN client actually honors the svn:executable keyword by setting the executable ACL bit for the current user. The mention "has not effect under Windows" in the SVN book has to be taken with caution. ]
Running a check-out with 1.7.4 sets all extracted files to read-only for the current user. For instance, and that's what is annoying in my specific case, it does not set the execute flag for batches. In the file properties, the Security tab ticks Read for Everyone, and Read/Write for the current user.
Running a check-out with 1.6.17 does not show this behavior. Files are checked out with user-friendly rights, and batches can be executed. In the file properties, the Security tab ticks Read & execute/Read for Everyone, and Modify/Read & execute/Read/Write for the current user, which is what I'd expect from a check-out. That check-out is part of a scripted process, so the environment is the same in both test scenarii.
I found no mention of that behavior in svn tickets, and had no luck searching. Most of the results relate to server-side configuration.
I'm no ACL/NTFS expert, I did read the Cygwin posix/windows article at http://cygwin.com/cygwin-ug-net/ntsec.html, but that did not clarify the difference.
I tried the svn:executable keyword, but as expected this has no effect under Windows.
The same difference happens under Windows 7 or under XP.
I noted that TortoiseSVN 1.7.6 (built against "native" SVN 1.7.4) runs the check-out correctly.
I have the default fresh-install /etc/fstab, which is empty, and no /etc/fstab.d config.
It's not that I'm unhappy with 1.6.17, but some of the features in 1.7.4 are interesting.
How do I solve that weird access rights issue?
Well, the solution was to rebuild /etc/passwd and /etc/group using mkpasswd and mkgroup.
However, rolling the changes to those files back does not revert the configuration in a state that triggers the issue. Possibly rebuilding them and running the check-out again had an impact on the SVN tool itself, but I have no idea why and how.
EDIT Nope, problem not solved.
Ultimately, this was solved by find'ing and chmod'ing files deemed executable:
sh - c "find %MYDIR% -name '*.bat *.sh *.exe *.com *.cmd' -exec chmod u+x {} \;"
What I certainly missed because of a lack of time to investigate is that svn:executable should actually be handled by the Cygwin-built SVN to add the correct permission flag. I'll have to check that soon.
[ UPDATE: The Cygwin-built SVN client honors svn:executable, so this is the way to solve the issue. ]
When I macfusion into my ubuntu VM, and hg clone something from bitbucket - and then try and do a commit / export / etc on it, I get a folder added with a name prefix of 'hg-checklinks-'.
On inspection it appears to house a never ending chain of symlinks back to its parent folder. This is driving me completely nuts, and so far, I've lost my faith in mercurial.
Mind you, seems to work fine when I just use it on a local folder. Does anyone have any idea how I can get around this.. or even more info as to why it's happening?
Cheers!
The decentralized part of DVCS is about running it locally -- the only Mercurial operations that should be done on anything other than the local system are push, pull, and clone. If you're cloning from bitbucket onto your Ubuntu VM then you should clone from your Ubuntu VM onto your mac and push to the Ubuntu VM.
That said, it looks like your network FS isn't correctly deleting the file when it's told to. Here's the relevant code (found here: https://www.mercurial-scm.org/repo/hg/file/a2dc8819bb0d/mercurial/util.py#l710):
name = tempfile.mktemp(dir=path, prefix='hg-checklink-')
try:
os.symlink(".", name)
os.unlink(name)
return True
except (OSError, AttributeError):
return False
So either your network FS is creating the symlink but throwing an exception anyway or throwing an exception when asked to delete (unlink) the symlink.
The problem here is with sshfs's very special "-o follow_symlinks", which will happily create symlinks, then claim it couldn't create them, then show them as awesome recursive unremovable directories. This broken option may automatically be turned on by a bug in Macfusion (https://code.google.com/p/macfusion/issues/detail?id=284). So if anything, you should "lose faith" in sshfs and Macfusion, not Mercurial.
This will be worked around in Mercurial 2.7. In the meantime, you should be able to run sshfs manually without the option.
(For faster bug fixes, please report bugs to the Mercurial/sshfs/macfusion projects, not random internet question forums.)
Git-svn allowed for a duplicate filename, just with different case, to be added to our subversion repository.
On Windows this meant that subversion could not checkout the file, complaining of a duplicate.
Another developer deleted the incorrectly cased version from the repository. Now when trying to do a git-svn rebase I get a "could not detach HEAD" message and a complaint about the file name in question being untracked and needing to be overwritten. Deleting the file makes git-svn complain that the file needs to be updated.
Is the only solution to copy the repository to a machine with a case sensitive filesystem do the rebase then move it back?
I understand that git-svn isn't ready for real world work on Windows but I'd like to recover from this mess it has created.
Best current answer (I don't know if this existed back when this was originally posed):
git config core.ignorecase true
Then redo the rebase. It will proceed without error -- and will even properly handle the case change in the filename.
This isn't specific to git-svn. It can happen in a straight 'git rebase'.
I hope that helps the next person....
I ran into a similar problem with Git (alone, not even with git-svn) getting very confused about changing the case of filenames when using a case-insensitive Mac filesystem. I didn't find a solution to fix the repository on the case-insensitive filesystem, but instead created a new case-sensitive volume in a .dmg file, mounted that, and used Git on that volume instead.
You may find that some of the Git "plumbing" commands might be helpful. For example, git checkout-index has a -f flag to force overwriting of existing files (also use -a with that command otherwise it might not do anything). The plumbing commands are generally more powerful (and more dangerous) than the porcelain commands, but may give you the flexibility you need to fix this.
The same way you always solve this problem under Windows. You have to rename one of the files, then you can restore the other one.