Using eGit to make a commit, the user name is consistently wrong and does not at all reflect what the .gitconfig file in my Win home directory shows (I've also searched for other .gitconfig files, none exist). egit insists on inventing some generated email address that combines my computer name with the domain it is attached - an email address that has only ever existed in egit's own mind.
When performing a commit and push, I have to alter the email each and every time. If I forget, I have to go back and correct it, then do it all over again. Where do I permanently inform egit what the user.email should be instead of the one it wants it to be?
Note: edited user.name to user.email
I'm going to make a wild guess, based on my experience and some of the subtle wording you use here, that your Windows environment does not have the "HOME" environment variable set.
Assuming that's true, what I've discovered is that the eGit algorithm for finding the "home" git config to use doesn't work as well as I'd like. If HOME is set to the Windows HOME, it works fine. If not, it tries some other strategies that don't work for me.
You can verify this in a cmd shell by setting HOME to point to your Windows home, then running Eclipse from that shell, and verify that your git config looks good.
To deal with this, I have written a very small batch program called "runwithhome.cmd" that looks like this:
set HOME=C:\Users\%USERNAME%
start /min %*
This assumes that %USERNAME% is set to your userid.
I use this by changing the shortcut used to start Eclipse, adding the absolute path to this batch file at the beginning.
Note that you'll now have to edit the icon setting, finding the path to the eclipse.exe file.
Related
I am trying to checkout a git repo (this) which requires the creation of a folder with unicode characters (the name is uni¢𐍈d€), where the missing character (I don't know how to render it here) is the Hwair gothic character. On my workstation, it works fine, but when I try to do it on a server (RedHatEnterpriseServer, where I do NOT have sudo powers), I get the error
fatal: cannot create directory at 'python/ycm/tests/testdata/uni¢𐍈d€': Permission denied
As a side note, I have tried to create the folder manually, and the hwair character is the only one that gives problems, meaning, that the folder uni¢d€ can be successfully created.
The LANG variable is set to en_US.UTF-8 on both systems. I have tried to find the differences between my workstation fonts and the server fonts. Grepping 'hwair', I found a font on my workstation that was missing on the server, so I copied the font folder in ~/.fonts on the server, and ran fc-cache, but that didn't work.
Google-ing hwair and grepping here and there on my workstation and the server, I found out that the 'hwair' character should be in the Code2001 font, which I think should be installed on both systems, since both system have the file /etc/fonts/conf.d/69-unifont.conf, which are identical, and contain the line
<family>Code2001</family> <!-- plane1 and beyond -->
I never really dealt with fonts at this fine level, so I'm not really sure if this is something solvable by adding some fonts locally or not (perhaps the system inhibits such particular fonts). I don't even know if copying fonts files to ~/.fonts/ and running fc-cache is enough or if there is something more to it.
So I guess the questions are:
Is the problem related to missing fonts on the server?
If yes, how can I add the missing font?
If no, is it related to something I cannot fix (perhaps it requires sudo privileges)?
Edit: the folder that cannot be created is part of the git repository. The error appears when cloning the repo (or anytime you try to checkout the master branch). I don't think there is an issue with permissions, otherwise it would fail also on my workstation (the permissions of the 'host' folder are the same). Also, trying to do mkdir $( printf 'uni¢\xF0\x90\x8D\x88d€' ) does not work either. The bash seems indeed to interpret correctly the unicode encoding, since when printing 'cannot create...', the name of the folder DOES show the hwair symbol.
Edit2: if you think the question has some flaws, please, add a comment rather than just voting for closing. I'm happy to change/edit/improve if need be.
I had the exact same issue!
It seems that for some - unknown to me - reason it is not possible to have that Hwair character in filenames on some filesystems as that other guy has already mentioned.
So as a workaround I suggest that you look at the available filesystems with something like:
df -Th
and then e.g. use a symbolic link to a filesystem which uses ext4.
FYI: The filesystem where it didn't work for me is of type nfs4.
In my scenario, I have two people that do work on the same code base. Their only available workspace is a shared dev environment (where the files built are used to host the dev version of the site to boot). As such, they perform their work directly in that location. I've recently introduced source control to the project, and turned that location into a Git repository.
Let me preface by saying: Yes, I would love it if the dev host spot was a deploy-to spot, and these people had their own local copies of the source code. But that isn't feasible right now.
My question: Is it possible for two different Windows users/Git users (they have separate accounts that they can use to interact with GitHub/etc. with) to share the same folder? My hope would be that SourceTree (our weapon of choice) or Git, at least, wouldn't have a problem with this: Just show diffs of what's changed, and use the currently-logged-in user's information when making commits/other actions.
It looks like that while SourceTree has separate installation directories, it still embeds some account information in the .git folder itself. When I try to interact with Git (via a pull for example), it first tries to prompt for new credentials/etc., but shortly thereafter it says "please enter password for {other-user}" without an option to hop usernames.
It looks like we'll just have to do things the right way after all. Painful (for them) but no choice.
What I did
I just started using git, and I think I accidentally initialized a bare repository (instead of a normal one) in my www folder. So when I committed everything, I noticed it started removing everything, which I didn't expect at the time. That's where I made the mistake of killing git. Now there's two files that I can't delete/move/read/write/execute.
When I knew what git was actually doing, I then cloned the git repo in my www folder to my desktop, and it looks like I got most of it back, including those two files, which are normal, and I can write and read to them.
What I'm trying to accomplish
I realize that this may seem like an elaborate scheme to learn how to hack, but that's not the case, I own these files and my goal is to delete them, not break in. I'm unable to delete them however, as killing git seems to have messed up the permissions on the file. I really desperately need to know how to delete them, otherwise git and every backup system I use keep breaking on doing anything in this directory!
Further info:
I'm using Windows 7 Ultimate x64, and Git version 1.8.5.2.msysgit.0
Below a screenshot of the situation:
When I look at the permissions tab in the file properties, I get the message I have to have be an administrative user with permissions to view its security properties. I then clicked on continue, as I have administrative permissions (since it's my laptop). In the newly opened window I get the message I don't have permission to view its security properties. When I try setting its owner, as it suggests, I get the message "Unable to set new owner on [file]. Access denied".
I already tried using an elevated command prompt to try removing them, even forcefully.
I'm desperate, guys (and girls)!
Ok, so I wasn't able to delete the files, on Windows.. I finally did it using a linux (debian 6.whatever) live-cd, and using rm -rf logs/
So if anyone else should encounter the same thing, this is a relatively quick solution.
I just discovered why Maven doesn't work properly on my machine. For some reason it reads the user configuration from the completely wrong location. And I don't understand why. When I run maven with the -X switch I get the following output in the beginning:
[DEBUG] Reading global settings from D:\dev\maven\active\conf\settings.xml
[DEBUG] Reading user settings from D:\.m2\settings.xml
[DEBUG] Using local repository at D:\dev\maven_repo
Why is it reading user settings from D:\.m2 and not my actual user directory like it normally should? It worked fine on my old computer. Does it have something to do with me having installed maven on a different drive this time? On my old computer it was installed on the C drive.
Where does it get this D:\.m2 from? How can I make it read the user settings file from the actual default location, %userprofile%\.m2?
Finally figured it out. Found the solution in this blog post. To find the home directory in Java you do this:
System.getProperty("user.home");
Problem is, for some dumb reason, Java isn't using Windows environment variables or anything like that to find this path. It actually uses the parent directory of the Desktop directory. Since I like to keep certain main folders in my user directory on a separate drive (documents, downloads, music, desktop, etc) I had moved the desktop directory to D:\Desktop. Java then takes that directory, goes one level up and makes Maven and other java applications think D:\ is my home directory.
Gotta say the more I use Java the more i hate it... anyways, hopefully this might help save some hours of head scratching for someone else too.
Update
The original blog post is gone, but found on the WaybackMachine (the URL has been updated), but here's the gist from that post in case that goes too...
The issue: So how does Java play into all of this? Well, Java
developers sometimes want to store settings for their applications in
a folder within the user’s profile directory. It’s the Linux way, and
Java tends to do things the Linux way. (As mentioned earlier, Windows’
“AppData” folder servers the same purpose, with some extra separation
for data dependent on whether or not it should roam with the user’s
profile.) For some reason, Java does not use the Windows environment
variable to determine the location of the user’s profile, but instead
access a registry key that references the user’s desktop folder. It
then takes the parent directory of the desktop and assumes that is the
user’s profile folder (assuming the user makes use of the default
setup Windows chooses).
Essentially, when a programmer calls the Java command:
System.getProperty("user.home");
Java uses the following idea to determine where my user profile folder
is:
PATH_TO_DESKTOP_FOLDER_AS_SET_IN_THE_REGISTRY + "\..\"
This breaks down when the desktop folder has been modified.
So, with my setup, instead of saving settings at:
c:\users\tim\
Java apps tend to save data to:
t:\tim\
In reality, Java apps should save settings to:
c:\users\tim\AppData\Roaming\
or something like that.
To add insult to injury, the Java apps continue to follow the Linux
way and use a period at the beginning of the folder name in an attempt
to “hide” the folder (as is done on Linux). For Windows users, this
simply ensures these folders are listed first in directory listings.
(Hiding a folder on Windows is achieved through setting the hidden
attribute for the file.)
It looks like NetBeans has addressed the issue for their application,
but the root issue remains an unresolved, low priority bug. Somehow
I’d bet it would get fixed a lot faster if the mechanism for
determining the user’s home path on Linux was wrong.
Background: this is running on a Windows 2008 Server.
https://www.mercurial-scm.org/wiki/Workflows#Feature_separation_through_named_branches
I'm a Mercurial newbie, and am trying to follow the advice above where it says to "Merge default into your feature as often as possible" -- and I've done this a couple of times previously today, already, with other files.
However, this newest change just won't merge.
When I do the 'hg merge default' I get the error "abort: Access is denied". After googling around, I see that some people reported actually having permissions problems on the files in question. There's nothing special about the permissions on the file in question, at least not that I can see. I'm a Linux person by training, not a Windows person, so fundamentally I don't really understand Windows file permissions. Cygwin claims that the file in question is 644 (i.e., I can write to the file), which is the same set of permissions as every other file that has previously been successfully touched by the hg merge process in the past.
I took a look at the DOS 'attrib' command and it doesn't show a 'read-only' flag next the file in question, either.
If this is less a Mercurial question than it is a Windows permissions question, I'm happy to modify the tags further as well.
I'm assuming that this "abort: Access is denied" error refers to the file in the changeset that needs to be merged, and not to one of the .hg/ files, but it's a very cryptic error message -- it doesn't say which file has an access issue (and there is only one single file in the changeset that was changed -- I purposely tried to be VERY simple with this test).
UPDATE:
Did an 'hg rollback' and tried the same test of commands in the same order, leaving the files open, only with a completely different file (lib/blort.html instead of blah/foo.html).
The 'hg merge' worked just fine.
So there's probably something particularly hinky about the permissions on the specific file I started with (foo.html), or the directory that is its parent.
Another Edit
Definitely something off about the parent directory, as I had the same problem w/ another file in the directory, but the problem does not manifest elsewhere in the directory structure, only in this one directory.
Just checked the permissions on lib/ versus blah/ and they both seem the same in Cygwin, but that's only a vague approximation of the Windows ACLs. When examining those by right-clicking each directory and examining the 'Properties' Security tabs, they again seem the same for both directories, but I think the crux of the problem is that I really don't quite grok ACLs.
Is there some DOS command-line tool, like 'attrib' only more powerful, that, like 'ls' in linux, would give me more information than the confusing jumble of checkmarks I get in the 'Properties'?
Hopefully the final edit
How to diff Windows permissions
'iCacls' seems to be the correct tool for the job, and seems to have solved the problem, but I'd like to duplicate this before accepting/closing.
SUMMARY
When in doubt, use --debug on your Mercurial commands. This is a little bit 'duh' now, but thanks to #lazy-badger for pointing it out.
You can fix your Server 2008 permissions using a command like icacls path /grant domain\user:(OI)(CI)F (see e.g. http://www.petri.co.il/forums/showthread.php?t=23207), but be sure to do this from an escalated CMD window ('Run As Adminstrator'). Again 'duh' to Windows people, not so obvious to a Linux person (instead I went googling around for some DOS equivalent to sudo).
You may get an access denied error on Windows if some other program has the file open. You can try closing programs that might have any files in that tree open, or rebooting the computer (which would, of course, close all programs).
Just to note "Access denied" on merge can have two different roots: mentioned by #emil and wrong or nonexistent rights for user, under which credentials hg was started, to create temporary files in $TEMP folder