I try to init a new Git local repository using either Git Bash or Egit in Eclipse. It always creates it in some default directory rather than current working directory (or specified path in case of Egit). EGit after trying to clone a repo returns an error that specified folder "does not look like git repo" - because it failed to init it correctly. Whatever I do, git init always produces files in the same place. Any idea?
I managed to find the reason. Git (and Egit which is also respecting environment vars) is using the path specified in GIT_DIR environment variable and completely ignoring current working directory. I once specified GIT_DIR in windows env vars, but then deleted it and it was not on the list anymore. Somehow, when I echoed it in Git Bash it was still there. Adding it again in windows vars and deleting again did the job.
Here I should note two bugs I discovered:
Windows is not always deleting environments vars and the may stay there with the old values (probably difficult to reproduce as it does not occur always).
EGit is respecting the GIT_DIR variable but still asking for the repo directory. This produces an error because the .git folder is in completely different location that Egit is looking for.
Related
I am trying to establish a git subtree in my project and for some reason I keep getting a message saying You must provide the --prefix option. I am making a Flutter project and the project repo (as well as sub repo) are both on gitlab.
Below is the command that I am running in the console while in my root project directory.
git subtree add —-prefix=subtrees/mysubtree https://git.company.com/subdirectory/subtree_repo.git master — squash
I have experimented a little with the command. For instance I tried —-prefix subtrees/mysubtree (sans =), as well as git config alias.sba 'subtree add --prefix subtrees/mysubtree / https://git.company.com/subdirectory/subtree_repo.git master —-squash'.
The last command doesn't throw any errors and it actually triggers pub get but no files change and no directories are added (at least not to the root which is where I am running the command).
I am not really sure what I am doing wrong and the messages (when there are messages) aren't very informative. I have checked my syntax and referenced it with Gitlab as well as with this post.
I'm running this on Windows Server 2003, and using the Cygwin version of the Git command line tools.
I have a Subversion repository containing a set of Eclipse projects, and am testing migration of this repository into Git. From the command line I've used git svn to create the git repository, and git clone to clone the new repository locally. In Eclipse I use the import wizard "Import->Projects from Git->Existing local repository" to import the projects from the local clone.
Once the projects have been imported, EGit shows an apparently random selection of source files as having unstaged changes. Comparing the files reveals no differences with the version in Git, and replacing the file with the HEAD revision has no effect.
Eventually after much head-scratching I tracked down the problem.
In the original Subversion repository, a number of source files had been checked in with the Subversion svn:executable property set. This property is honoured by git svn, and when the file is ultimately presented in the Git working directory it has the execute permission property set. Even though this is how the file is configured in Git, EGit looks like it isn't seeing the permission set in the repository and is treating it a difference between the repository copy and the working copy... hence it appears in the list of unstaged changes.
I fixed the issue simply using chmod -x on the affected files from the Cygwin bash shell, and committed the changes. I understand that setting the Git property core.filemode=false should also resolve the issue, although I've yet to try this.
Hopefully there is some setting in git config for this...
Our project team chooses to store eclipse .project and .classpath settings in the git repository. Now, ignoring wether or not storing these files in the SCM is good or bad -- the problem is when the repository is cloned under windows any filename starting with a dot '.' is set as a system file, making it read-only which causes eclipse to spew errors when trying to update projects.
Could not write file: D:\git\SFP\framework\Auth_Server\.classpath.
D:\git\SFP_convert\framework\Auth_Server\.classpath (Access is denied)
So, how do I stop git from setting files starting with a dot '.' as system/read only?
Git shouldn't change those permission, and dotfiles aren't always considered as "system files" in read-only.
Case in point: a .gitignore present in most repo should be perfectly writable when the repo is cloned, even on Windows.
Git only stores two permissions (755=rwxr.xr.x, 644=rw.r..r..).
One way is to make sure to commit in a repo with git config core.filemode false.
But for a repo which already contains files with the incorrect permission, you need to make a new commit with those same files with the right 755 permission.
You can use a reverse patch or git-meta-cache.
The OP Jon reports:
We are currently using msysgit 1.6.5. upgrading to match the git version on the server (1.7.9) has fixed the problem.
I would recommend also to upgrade to the latest available (1.8.4 Sept. 2013)
This problem occurs when we copy the project from system to other system then some file are automatically hidden.You go in your project directory and in this project directory. some folder and file have a hidden attribute so un-check hidden attribute in all file and folder and now import project.
I used computer A via the Terminal to create a) create a git repository, b) add an index.html file to the repo, c) add a remote origin, d) push to the remote origin. All OK.
Then, i used computer B to clone that repository via Terminal. Then, I opened Eclipse (equipped with Egit), and created a new project in the folder that was created by the cloning process. Then I used Eclipse to push any changes to the remote origin.
Returning to computer A, I used Eclipse to create a project in the original repo folder, and then I attempted to pull from the remote origin, in order to get the changes that were pushed when using computer B.
Eclipse will not do it. It complains the I have items such as .settings, .project and similar and since they are not under version control it won't overwrite them by fetching files from the server. I had to manually delete those files (via Terminal) and then Eclipse worked as expected.
Please provide information on how to avoid this.
Should I create the local repo from within Eclipse and then push it to the remote origin, so that items such as (.settings) are under version control and (if so) how would that cause trouble to people cloning the repo and use different versions of Eclipse?
Should I gitignore those items?
Should I ask Eclipse to save its own affiliated files to another folder (not that i am aware how to do that, i only know that NetBeans does it)?
Looks like you didn't gitignored eclipse files.
Probably, when you commit/push via egit, you also commit and push those files you already had unversioned in your machine A, so git complains, because you are asking to override existing unversioned files.
I strongly recommend you to gitignore those eclipse files. You can see examples of .gitignore files in the github gitignore repo.
Hope it helps.
It complains because if you pull the changes from your remote it will overwrite your local files. That is the problem. The other answerer has right. You should better add all the eclipse project files and and target .settings and classpath to gitignore. You can use a global gitignore for your computers as well, before creating projects. You could use maven for example, then you can import your projects only from the pom.xml-s given in the git repository.
I use them the same. Egit and other guis are a bit too complex to work with. Git repositories can get easy in an inconsistent state where you should use the oldfashioned terminal to solve things. Like, rebasing, merging on conflicts. Gits learning curve is solid.
Now you can solve your problem if on the first computer save a backup of your original and clones your project later, after fixed it on the second. On the second git remove all this files, but use the --cached option to avoid deleting them. Before you do it so, check the help of git remove! after you have done this, put them into the .gitignore as filenames with wildcards. You can also use a global gitignore file in your user folder. Creating a .gitconfig file where you can specifiy the global ignore with the following :
[core]
excludesfile = ~/.gitignore_global
Than just create the .gitignore_global like this :
/nbproject
/bin
/build.xml
.idea
chess.iml
target/
bin
( This file is for idea and netbeans. you can add eclipse project files here )
You can have .gitignore files per project too. You can commit them to the repository, so on the next machine you do not have to do this again. The nicest way I think is having a dotfiles git repository, which is a git repo of your home directory and the dotfiles in it. I also use it for different windows and linux distros.
That's all. You should keep all of your configuration in a safe place. And source code management can do it. But do not commit private stuff to public a place! ;)
Oh I wanted to mention that, you can also have a .gitignore entry in your .gitignore file. That can be very useful when you do not want to touch a repository but need to add a gitignore to hide some stuff especially from the given repo.
Issue
After importing an Eclipse project from a cloned git repository, I make some changes and commit - and wtf? I get a ".git" folder added to the project, the whole shebang with the heads and refs and worst of all the whole object database gets added to the project, all files/folders having that little question-mark icon signaling that the files have not been added / are not yet tracked by git. This .git folder exists in the actual Working Directory (how does that even make sense?). You can imagine what an annoyance this causes when trying to use the "Synchronize" tool/view (which is supposed to make life easier for committing, you can see all the changes and changed files and diffs).
Question (tl;dr)
How to correctly import an Eclipse project from a cloned git repository? I don't want a .git folder showing up in "Team > Synchronize" when I commit, let the .git folder reside somewhere else outside of my project.
Additional Info
I'm on Windows 7 using Eclipse Indigo and Egit.
I am using Egit to clone a git repo from http://git.apache.org/ (the ofbiz project, to be exact) and in the wizard I choose the option to import an existing project from this newly cloned repo.
Yes I am aware of how little I may expect from Egit. In fact, if there are any alternative ways (external git tool? command line git for windows? other?) to use a git-tracked project in Eclipse which keeps the actual .git stuff out of the project, i'd gladly abandon Egit.
When you clone a git repository, the default behavior is to create a .git folder inside the root of the local clone. You can change the default behavior by setting the GIT_DIR variable:
Git docs says:
"GIT_DIR
If the GIT_DIR environment variable is set then it specifies a path to use instead of the default .git for the base of the repository."
Depending on which terminal you use, you could set it using setenv or export.
For example in a bash terminal:
export GIT_DIR='[path_to_git_directory]'
After setting the variable, you should be able to clone and the .git directory should show up at the specified directory.
I totally agree - I can't imagine it would ever be anyones intent to commit the .git folder!
And git/EGit knows that this is the repository folder of the project, so it should be easy to implement the appropriate exception - so that this folder does not become part of the synchronization.
I know the following does not solve your problem, but in cases where you control the way files are layed out in the repository, you could choose to have the Eclipse project folder not be the root folder of the repository, but rather a sub-folder.
This also allows you to have stuff in the repository that should not show up in Eclipse, or even have multiple Eclipse projects grouped in one repository (if you should wish to do so).