Community
Participate
Working Groups
Hi, as the EGit user guide (https://wiki.eclipse.org/EGit/User_Guide#Considerations_for_Git_Repositories_to_be_used_in_Eclipse) itself advices I'm trying to create a Git repository out of my Eclipse project. However, all my attempts failed: - Cloning a repository and importing the project: .git folder and working directory are always in the same folder. - Creating a project and using the Git Sharing wizard. Either I choose to reuse an existing Git repository, then my Eclipse project is moved there. Or I create a new repository, then I only can create it where my sources are = with the Eclipse project as root. Interestingly the wizard discourages me to create my .git folder in the Eclipse workspace but itself offers just this as default location, which only needs to be accepted with the 'Create Repository' button. - Creating a (source) folder in my project and trying to share only this isn't possible - in the context menu the item 'Share project' is disabled. - Setting core.worktree in the repository's properties is ignored. As the EGit website says: JGit can handle it, but not EGit. - Cloning a repository into a different folder outside my workspace, adding a link to its working tree folder in the Eclipse project: works; however, the Eclipse project itself doesn't know that the sources are shared and thus neither EGit decorations nor the team menu work in this project. After days of desperated trial and error attempts I would really like to get this working... Thank you in advance.
(In reply to exquisitus from comment #0) > - Cloning a repository and importing the project: .git folder and working > directory are always in the same folder. This is the simplest way. Could you describe step by step what you are doing and why it doesn't work for you?
Thank you for your quick response. How to reproduce: 1) Clone external repository to local folder: from git://git.gnome.org/babl to /home/developer/git/babl-new. The git repository is then in /home/developer/git/babl-new/.git 2) Right click on the new repository in the Git Repositories view, select 'Import Projects...' 3) Alt. 1: import as C project: 1) Use the New Project wizard, 2) from C/C++ select 'Makefile project with Existing Code', 3) Project name: babl-new, Existing Code Location: /home/developer/git/babl-new, Language: C, Toolchain for Indexer Settings: GNU Autotools toolchain. The dialog has a label at top telling 'Create a new Makefile project from existing code in that same directory' - however, there is no option to import the code into another directory. 3) Alt. 2: import as general project: Project name: babl-new Directory: /home/developer/git/babl-new 4) Check back in the C/C++-perspective: Show new project's properties: Resource/Location: /home/developer/git/babl-new, Git/Git directory: /home/developer/git/babl-new/.git, Git/Working directory: /home/developer/git/babl-new I don't know why it is not working for me. It could also be possible that the Import wizards don't support this. However, it would be a great help if I could setup this with the Git Sharing Wizard or share only a subfolder to a repository out of my working tree.
Can you, please, continue after step 4 and exemplify what you think the layout should look like?
Var. 1 (plain) This variety is for cases where all the developers in the project work with Eclipse and share the same project configuration. Logical project layout as seen in Eclipse: babl-new (shared) sources file 1…n project metadata (.project, .cproject, etc.) Physical layout on harddisk: Resource/Location, Git/Working directory: /home/developer/workspace/babl-new Git/Git directory: /home/developer/git/babl-new/.git Var. 2 (hierarchical logical layout) Variety 2 is for cases like big open source projects where developers work with different IDEs and don’t want to pollute their public project’s repository with indidvidual IDE metadata etc. These data should be stored and version-controlled as each developers own responsibility. Logical project layout as seen in Eclipse: babl-new src (shared) sources file 1…n build data doc project metadata (.project, .cproject, etc.) Physical layout on harddisk: Resource/Location, Git/Working directory: /home/developer/workspace/babl-new/src or another directory that is linked as /src into the Eclipse project Git/Git directory: /home/developer/git/babl-new/.git
(In reply to exquisitus from comment #4) > Resource/Location, Git/Working directory: /home/developer/workspace/babl-new > Git/Git directory: /home/developer/git/babl-new/.git Such a layout is currently not possible AFAIK, the working directory must be in the directory where .git is located at. But what is the problem with having it like this?: Resource/Location, Git/Working directory: /home/developer/git/babl-new/ Git/Git directory: /home/developer/git/babl-new/.git Supporting core.worktree would require some changes to EGit's sharing wizard and/or to the import projects wizard I think.
> But what is the problem with having it like this?: > Resource/Location, Git/Working directory: /home/developer/git/babl-new/ > Git/Git directory: /home/developer/git/babl-new/.git The EGit user guide describes it more extensively: https://wiki.eclipse.org/EGit/User_Guide#Implications. Additionally it already happened that users accidently destroyed their Eclipse project by simply executing 'git clean -xdf' (remove everything from the working directory that is not comitted into the Git repository). There are use cases like big open source projects where developers work with different IDEs and don’t want to pollute their public project’s repository with indidvidual IDE metadata etc. These data should be stored and version-controlled as each developers own responsibility. > Such a layout is currently not possible AFAIK, the working directory must be in > the directory where .git is located at. [...] > Supporting core.worktree would require some changes to EGit's sharing wizard > and/or to the import projects wizard I think. In Git and JGit it is allowed, see for instance the core.worktree option. In EGit it doesn't work. That's why I filed a bug.
Git runs the clean operation on the worktree. Whether the .git directory and worktree are co-located or not, has no effect. The User Guide describes how the .metadata directory might accidentally become erased. Note that the workspace directory (called ".metadata") is not the same thing as you call metadata (.project etc). You can do the following to keep the project files separate from the repo and source files: Clone or create the repo into /dir/worktree/.git Create the Eclipse projects in /dir/projectdir, remote the default source folders and add new "linked" source folders that point to directories inside /dir/worktree. Linked source folders are tracked in the workspace, but you would use symlinks instead, but you'd have to create these without Eclipse's help. /dir/projectdir/project/.project (src = ../worktree/projectsrc) Just cd /dir/projectdir/project rm -rf src ln -s ../worktree/projectsrc src
Yes, I tried that and failed. It would also be a pain to link every single folder (and file) outside Eclipse to have nothing more than a workaround. Why don't we just solve the actual problem: EGit can't deal with repositories out of the working tree? And as the EGit website says: the underlying JGit library already supports it, so it wouldn't have to be developed from scratch. Thank you in advance.
(In reply to exquisitus from comment #8) > Yes, I tried that and failed. It would also be a pain to link every single > folder (and file) outside Eclipse to have nothing more than a workaround. > Why don't we just solve the actual problem: EGit can't deal with > repositories out of the working tree? > > And as the EGit website says: the underlying JGit library already supports > it, so it wouldn't have to be developed from scratch. > Thank you in advance. The JGit part was really easy to do. The EGit part involves deciding and the designing the UI and lower level parts for how to deal with a separate worktree when connecting the team provider and how to change the worktree after the fact. It's not a bad idea. Patches welcome.
