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.)
Related
I uploaded my Laravel project to a shared server, now I am trying to clone the project from a local computer and I am getting the following error:
error: invalid path 'public/C:\xampp\htdocs\pfuxelacolab\storage\logs/laravel.log'
fatal: unable to checkout working tree
warning: Clone succeeded, but checkout failed.
You can inspect what was checked out with 'git status'
and retry with 'git restore --source=HEAD :/'
Help Please...
You have a repository with a commit that you, personally, cannot use on your system. A Linux user can use this commit, but you can't.
The problem here is the file's name:
public/C:\xampp\htdocs\pfuxelacolab\storage\logs/laravel.log
In a Git commit,1 there are no folders: files simply have long names like this one. Each forward slash / in a committed file's name—and only the forward slashes—will, on a Windows system, be turned into the appropriate backwards slash \ and Git will break up the path into pieces such as public and laravel.log and so on.2 Git will then do what your OS demands: treat each of the various pieces as folder-and-file parts, and make any folders needed so that it can create your OS's idea of a file named laravel.log in your OS's idea of a folder. Git itself doesn't hold with such silly notions: you just have a file with a long name with forward slashes in it, but OSes have these dumb and silly folder-and-file requirements, so, okay, Git will deal with it.
In any case, this file's name includes C: right in the middle—not up front, where some DOS/Windows software might be able to deal with it, but in the middle, after public. So Git is trying to create a new folder, named either C: or C:\xampp\htdocs\pfuxelacolab\storage\logs, within a public folder, and that is never going to work: Windows says you can't do that. Linux, by contrast, says Oh you'd like to create that as a folder name? Sure, done!
So, someone on a Linux or similar system can check out this commit. Having done so, they can fix the file's name or remove the file entirely and make a new commit that doesn't have this bizarro name with the colon and backslashes inside it. Remember, Git demands forward slashes. It will make forward slashes for its own commits, from the OS's folders and files. But it will also take any file names with embedded colons and backslashes found on a Linux system, and make a commit from those, that can't be extracted on a Windows system. That's what someone did: they created a folder named C:\xampp\htdocs\pfuxelacolab\storage\logs in a folder named public, and created a file named laravel.log in that, and then added that to Git's index and committed it, presumably on a Linux system.3
The easiest way for you to deal with this will be to boot up a Linux system (perhaps in a VM) and check out the commit in question and make a corrected one to use instead. Whether you can do this at all in WSL, I have no idea.
1Technically, this claim is true not of the commits themselves, but of Git's index. But commits move "through" the index on the way out to your working tree, and are made from the index, so the condition applies anyway.
2Since I don't use Windows, I don't know whether Git will try to break apart the backslashed pieces here too—but it won't matter because of the C: part. It would be interesting to create a file named test\path/file on a Linux system, commit it, and try to check that commit out on Windows, though. Does Windows Git make a test folder? If not, does it (whether intentionally or merely accidentally) use an existing test folder and make a path folder? But Windows forbids colons in path names, and the embedded C: part, with or without any subsequent part, is the first and fatal problem here.
3While I keep saying "Linux" here, any OS that allows this will suffice, so Solaris or one of the BSDs would do the trick too. You could even do this on macOS.
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.
I am new here and i will try to explain my question kindly ignore any mistakes.
I am using git version git-2.8.2
It worked fine for one day then this problem occurs.
I am using gcloud repository.
First I tried gcloud clone command then this error occurs
Then to make sure git is there I tired git command then this error occurs
Then I double check by opening git Bash but same error was there too.
I tried reinstalling changing directory. but nothing works.
I face the same problem after I try to avoid memory leak in Windows 10. If you happened to change the regedit like me, just type regedit in the search then go to
HKEY_LOCAL_MACHINE -> SYSTEM -> ControlSet001 -> Services -> Null
change the value of Start to 1.
I accidentally bumped into the same problem when I was sorting out the services running on my computer with Windows 10.
fatal: open /dev/null or dup failed: No such file or directory
The reason was that I deleted the service named 'Null' that had no description as I thought that was a virus service.
Thus, when I found my git unable to operate, I reckoned the deleted service.
According to a solution provided on some site I tried to run the service again using cmd.exe
sc config Null start= system
sc start Null
but it said the service hadn't been existed in the list.
Thankfully, there are some kind folks who shares the information of the default services running on Windows 10 and the description necessary for the successful bringing back the service.
So as to get the service back in the list:
press Win + R
type regedit
go to HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services section
Create Null folder and all the params it needs.
Restart your computer.
Now you got your Null service back and your git back as well.
Hope this helps.
I solved my problem accidentally. I would like to share it with everyone.
It was not a problem of git or gcloud or source tree.
Actually I have forcefully stooped windows update from installing which causes this problem.
Now when I install windows updates again this problem is fixed now.
Maybe this helps someone.
the similar situation in chrooted linux tree is fixable following way:
cd inside the folder where you are preparing the chroot dir, then
mount -o bind /dev dev/
then only chroot inside
I had this weird bug just now. I went back a dir and tried git init, it worked there.
I re-ran zsh and tried again in the dir it errored in originally and it worked. shrugs
I use Mercurial as source control with the main repository managed on KILN.
At one point in time I changed my iOS project name from WeatherTimeMachine to weathertimemachine.
This resulted in a case change of several files and folders:
WeatherTimeMachine.xcode
WeatherTimeMachine_Prefix.pch
WeatherTimeMachine-Info.plist
In the meantime I've added a tag to a revision in KILN... So I now have:
a head in KILN
a head on my local repo with case changes
When trying to merge I get the following error message: "Mercurial case-folding collision"
How can I fix this?
If you're on Mac OS X, you don't need to export your repository to Linux or another foreign case-sensitive file system as suggested by the Mercurial documentation. Just use Disk Utility to create a case-sensitive, journaled disk image slightly bigger than your repository, copy your repo there, then remove the conflicting files and commit.
I have found some information here: FixingCaseCollisions, but somehow this did not work for me. Here is how I managed to solve this issue:
Make a copy of your existing repository folder (for safety). For example:
cp -r WeatherTimeMachine WeatherTimeMachineCopy
Fool mercurial into thinking the problematic revision is the current tip:
hg debugsetparents <bad revision>
hg debugrebuildstate
Remove the files which are causing the problem (-f is required to force the removal). Here is an example:
hg rm -A -f WeatherTimeMachine-Info.plist
Once all problematic files have been removed, commit the changes
hg ci -m "fixed collision-folding issue" -u michael
Then restore mercurial to the proper revision
hg debugsetparents tip
hg debugrebuildstate
After this the merge is possible and the problem is gone.
And now I can happily resume working with MacHg to manage my Mercurial repository and push my change sets to KILN.
This is a no-programming no-hg answer, but it solved my mercurial case-folding problems once and for all! For now anyway..
I gave up trying to avoid and "fix" the case-collision problems. That just looks ugly and you can never really "solve" the problem, only can do a workaround.
The only way (that I can think of) to really solve the problem is to have a case-sensitive filesystem. No need to reformat your entire disk, a single partition will do the job nicely.
I used the Disk Utility app that comes with the os, pretty straightforward, just remember to select Mac OS Extended (Case-sensitive, Journaled) when creating new partition. Also, note that the Disk Utility can resize partitions only by moving the end (not the beginning) of partition.
You can probably create a symlink to where your old source code lived, so no need to change the IDE settings and stuff (but I haven't tried this, just happy with the new partition).
We resolved this without resorting to a case-sensitive filesystem by issuing HG rename commands. Say you are having trouble because "Foo.txt" needs to be called "foo.txt":
> hg rename Foo.txt Foo.txt.renamed
> hg rename Foo.txt.renamed foo.txt
We encountered this problem when a file was deleted and then later re-created in the main repository with the same name, but different case. A branch repository that was created before these changes could not then be merged in, despite the changesets from the main repository having been pulled.
For Mac OS X, what worked for me is to simply copy the folder (duplicate works - cmd-D) and continue working on it, from the new path.
OSX same I wanted to clone a repo and I had case-folding error preventing me top clone.
If the repository has multiple commit simply clone an earlier revision with this command:
hg clone -r 7
Then add anything conflicting to the .hgignore file and update.
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.