The working directory should be visible on a WebDAV server and none of the parent folders should contain the repository itself.
I want to separate totally the folder for .git and the working directory (on a different drive, clean from project files and others).
Using Eclipse EGIT, the repository creation allows set of working directory (Target Location) within a path within the repository.
No way found to set GIT_DIR or working_directory within Eclipse. Linking not an option (Windows)
The project .location contains the place within the repository (and that is a binary file anyway), so that should be configurable.
Is there any way to move the working directory to a totally different place?
Is there a configuration option I have missed?
After editing the files, do I really have to push all to the server, then commit to git?
To summarize what has been written in the comments, EGit does not support Git repositories whose work directory is at a different location than the .git directory. I.e. the core.worktree configuration setting is not taken into account.
See also this open enhancement request: https://bugs.eclipse.org/bugs/show_bug.cgi?id=433451
Related
I am working on a project which has GitLab repository and the local repository is on a network folder so I wanted to create an Eclipse Workspace on that folder as one can share the project with the other team members but when I tried to build the project I got an error message which says that eclipse workspace can't be a UNC path, so my question is, is there any work-around way I can do this, for example is there any way I can let the OS (Windows 10) link a local folder to the one on the network so that every member would do the same and work on his own local folder and it will be automatically edited in the network folder?
Thanks
No, this is not possible since everyone needs their own cloned Git repository to work with.
For instance, switching the branch or staging files are per repository and would therefore affect everyone. When you clone a Git repository without the bare option, there will be a so-called working tree which is the location where the currently checked-out files are and this folder is not copied but mapped into your workspace. Everyone would not have a copy of those files but working with the same files.
Besides the editing conflicts you would have, another disadvantage of having a Git repository on a network drive is that it would be slower. Therefore one would not want to have this even if it were possible to have Eclipse projects on a network drive.
But since in most cases a Git repository including the working tree takes less disk space than in SVN the working copy of the same, it should not be a problem if everyone has a locally cloned Git repository.
I've seen similar questions but some are very old and some are not quite what I'm looking for or have no answers.
I have projects in Eclipse under /workspace/project1 and /workspace/project2. They are Gradle projects and are dependent on each other. I also have /workspace/project3 which is a Gradle project but independent.
I need to "upload" them to a git repo on Bitbucket. I installed EGit to help me with this. It asks me where my local repo is located and I don't know what to tell it. Should I create a repo per workspace or per group of dependent projects or what?
For example when I right click a project and press Team > Share > Git I get to this dialog and I don't know what I should fill in there.
Each (non-bare) git repository has a work directory in which the files of the currently checked out commit (referred to as HEAD) are stored.
By default, the work directory is the parent of the git metadata directory (named .git), but it can be detached through a config setting. For example: git config core.worktree /path/to/workdir
EGit cannot deal with repositories that have a detached work directory as answered here: EGit working directory not under the local repository
But irrespective of this limitation, you cannot split the work directory of a git repository among several workspaces.
Therefore, you should move the projects to the work directory to resemble this structure:
~/git/my-repo/.git
~/git/my-repo/project1
~/git/my-repo/project2
~/git/my-repo/project3
If project3 is independent of the others, it may remain where it is or be located somewhere else entirely.
A word of caution when planning to have interdependent projects spread across several git repositories. This makes the git repositories effectively interdependent as well, but without git having a dependency management tool.
To have EGit move the projects, you would enter project1 in the Path within repository input field.
Commonly used build files like the master pom.xml or corresponding Gradle files would be located in the root of the work directory. This also eases configuration of popular build services like Travis, Codeship and friends.
A few things to understand/keep in mind:
An Eclipse workspace is a logical container of projects, not necessarily a physical container. The folder in which a worksapce is located can also be a physical container of projects, meaning the project's files can be located in a folder under the workspace folder (this is the default location if you create a new project in Eclipse). But that is not a requirement; a project that is contained within a workspace can have its contents (its files) located in any location on your file system.
In most dev setups, the local git repos are located in a "standard" location in the user's home directory, namely %USER_HOME%/git/name-of-repo. Again, that's not a hard requirement, users have the option to clone or create repos in any location they choose.
So Eclipse eGit is showing you those 2 axes of flexibility. It's asking where you want to create your local git repo, which usually is different than your workspace folder. Use the Create... button to create it. I think at that point it will auto-populate the Path within repository field. If it does not, you can name that path anything you want (usually its the same as the project name, though not necessarily)
At the end of it all you'll have your workspace (logical container) as well as a local git repo which will be the physical location of the project contents.
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.
Long story short I moved my local project to the root of my web server. In doing so I've lost my connection to the local git files.
Here is the location of my Working Directory after pulling the source down from git.
C:\Users\Administrator\git\SiteName
subfolders are:
.git
android
website
My local webserver no longer has an android or website dierctory, but instead the contents of website are simply in htdocs.
Is it possible to reference the structure on github but keep my local files in eclipse in a different area, so I can once again merge and push files?
You can tell EGit to point to a local git repo from the Git Repositories view. Once EGit knows where your repo is, it can import projects from that repo. You can work on them in eclipse, but they point to the repo external to the workspace.
You could create symlinks to the files in the "website" directory inside your htdocs. That may or may not be what you want, since, all changes will be immediately reflected on the front end.
While importing a project, eclipse allows you to create symlinks to the files without copying them into the workspace. It's an option that appears after you click the "Advanced" button in the import dialog box. This should allow you to keep the files wherever you like, and still use them in eclipse.
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).