46

I'm just moving from svn to git, and am keen to lay some good foundations.

By default Eclipse wants to store my local clone repository in ~/git. I'm more comfortable keeping all data for a task in the same workspace - so I'm inclined to keep it in my workspace.

Are there any significant pros/cons I should consider?

I don't intend doing a lot of branching - I'm really going down the dvcs route mostly to overcome some unreliable internet comms issues.

Michael Schmidt
  • 9,090
  • 13
  • 56
  • 80
ianmayo
  • 2,256
  • 3
  • 26
  • 44

3 Answers3

31

I'm too switching to Git in Eclipse, and reading about this issue. It seems that current wisdom (though not everyone agrees) is:

  • Get used to NOT having your projects below the workspace directory.

  • Have one git repository for each group of related eclipse projects (and perhaps more files, of course). The concept of "related projects" is up to your convenience [*]

  • For each repository, one first level directory for each Java project. This implies that you'll have a .git/ directory, and, at the same level, the project directories.

Example: suppose that, "before GIT", you had one eclipse workspace with several projects:

/wk/workspace/.metadata/  
/wk/workspace/projXXX/  
/wk/workspace/projXXXtest/  (related with the previous)
/wk/workspace/projYYY1/     |
/wk/workspace/projYYY2/      >  three related projects
/wk/workspace/projYYY3/     |
/wk/workspace/projZ/        (a project you are not going to version in git)

Then you'll create two empty directories, one for each repository, say:

~/repositories/XXX/ 
~/repositories/YYY/

and afterwards, with the new GIT layout, you'll have:

/wk/workspace/.metadata/  
/wk/workspace/projZ/ 

~/repositories/XXX/.git/   (XXX related repository - non-bare)
~/repositories/XXX/projXXX/
~/repositories/XXX/projXXXtest/

~/repositories/YYY/.git/   (YYY related repository - non-bare)
~/repositories/YYY/projYYY1/
~/repositories/YYY/projYYY2/
~/repositories/YYY/projYYY3/

Eclipse (EGit) does all this for you when you click Team->Share over an existing project and specify (in the example) ~/repositories/XXX/.git/ as repository, (~/repositories/XXX/ as "Working directory", leave "Path within repository" blank).

[*] Bear in mind that here each group of projects is, from the Git point-of-view, just a set of directories inside a repository. Some relevant implications: in the above example, you'll never have in the Eclipse workspace two different branches/versions of projects projYYY1 -projYYY2 simultaneously; and, say, when you tag a project commit, you are actually tagging the full repository (group of projects) commit.

leonbloy
  • 73,180
  • 20
  • 142
  • 190
  • 3
    Do you happen to have a link or two to people who disagree? Because I find the logic of the "common" wisdom" approach not fully convincing. All of the reasons given apply to the case where you make the workspace the repository, rather than a project the repository. Note I agree it seems the eclipse recommended path, but I'm not convinced they are right :). – studgeek Oct 17 '12 at 20:09
  • I'm not sure I understand the alternative "make the workspace the repository, rather than a project the repository" In my example, each repository corresponds neither to a workpace nor to a project, but to a set of projects. – leonbloy Oct 17 '12 at 20:14
  • 3
    You could make the repository at the project level. So you don't have to move the project at all and you also don't have any of the problems listed in the article you link to. This assumes you don't need more than one project in a repository. – studgeek Oct 19 '12 at 14:29
  • The point is not only to be able to have more than one project per repository (which in itself is nice), is that having the repository (`.git/` directory) inside the workspace directory is clumsy and can have performance issues. Read http://wiki.eclipse.org/EGit/User_Guide#Implications – leonbloy Oct 19 '12 at 15:01
  • 2
    That is the link I am talking about. The reasons it gives only apply if you put .git at the workspace level, not if you place it at the project level. If its at the project level then there is no .metadata and .git its not a direct child of the workspace. Is the other "clumsiness" that is not explicitly described? – studgeek Oct 22 '12 at 15:24
  • 1
    Note, I am not disagreeing with you, just trying to understand the option better. You had mentioned "though not everyone agrees", so I thought you might have links/background on why they don't. Thx. – studgeek Oct 22 '12 at 15:25
  • @studgeek: I am just learning git/EGit and the idea of per-project repos raises this question for me: Would there be a problem in maintaining consistency between library project versions and versions of client projects that use those libraries if you used a separate git repo for each project? I have a number of Android projects that share a few important libraries, and I'll need the library and app versions to be synced (especially for tracing bugs occurring in the wild for a particular version from the ProGuarded code in which they occur). Might a multi-project git work better for that? – Carl Aug 01 '13 at 16:15
  • The Git Submodule feature seems to be an attempt to address this very issue by allowing a repo for one project (e.g., an app) to refer to a particular commit within a repo for another project (e.g., a library). That seems to suggest that clumping "related" projects together might not be the best approach, but that we might do better by keeping configuration management separate for libraries and their clients, respectively and then using this feature to connect them...? https://www.kernel.org/pub/software/scm/git/docs/git-submodule.html – Carl Aug 02 '13 at 22:04
  • There is no way to add from Eclipse a README.md file in the root of the local git repository. Something like `~/repositories/XXX/README.md` and `~/repositories/YYY/README.md`. You can create one from the file explorer, or the terminal. – christianbueno.1 Apr 26 '23 at 03:24
2

The .git should be where your working tree is (that is the files representing the current HEAD of the current branch you are working on)

Remember that with Git, branches are not directories (as opposed to SVN), so your working tree will represent directly a branch content, not several directories (for your various branches), followed by a content per branch.

I usually like to keep my project sources separate from my Eclipse workspace, but that is a matter of preference.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Keeping your sources separate from the workspace is, yes, a matter of preference, although it appears from what Zoltán Ujhelyi has written above that this approach could have some specific advantages for grouping related projects together under a single folder so that they can be versioned within a single git repository. – Carl Aug 01 '13 at 16:33
  • 3
    @Crowie eclipse workspace is mainly for Eclipse metadata. When you change Eclipse or want to use several versions of Eclipse on the same machine, you want to import your project independently of the Eclipse which does the import: that is clearer and easier if your project has a life of its own outside any Eclipse. – VonC Dec 17 '14 at 15:20
2

I think, it is a good idea storing the git version tree outside the workspace. This way it is possible to separate projects from different repositories, but still handle them in the same workspace.

Additionally, if you put the code outside the workspace, you can organize your projects hierarchically outside the workspace (in the working copy), but still see the flat representation in Eclipse.

Zoltán Ujhelyi
  • 13,788
  • 2
  • 32
  • 37
  • Yes, this seems very reasonable, since Eclipse is comfortable with having its projects outside of its workspace folder. So you could just group your related projects together under a single folder, as suggested in leonbloy's answer, only the folder would be *outside* the workspace hierarchy, and the git repos would be off each such folder. Although, being new to both git and EGit, I am not sure that EGit would be able to deal with source outside of the workspace - perhaps your approach would require the use of the regular command line git or a GUI that is built on top of that, and not EGit? – Carl Aug 01 '13 at 16:43
  • I suppose an alternative could be to allow only "related" projects to share a single workspace, and then put your git repo off the top level workspace folder. But that might be inconveniently rigid, as one might want to have projects of a similar kind in the same workspace for easy *reference*, even if they were not to be evolved together under a single version control repository. So your suggestion seems to be the most generally serviceable. – Carl Aug 01 '13 at 16:56
  • Actually, I've found the documentation that says you can use EGit for this here: http://wiki.eclipse.org/EGit/User_Guide#Creating_a_Git_Repository_for_multiple_Projects – Carl Aug 01 '13 at 17:43
  • 1
    @Carl Basically you can do everything, but in my experience, the external folder is the most robust option. I have introduced a folder where I put _all_ git repositories, so I don't have to think about where everything is; and this also helps testing maven-based builds outside eclipse... – Zoltán Ujhelyi Aug 01 '13 at 18:33
  • That's what I'm about to do, too. Creating a workspaceVersions folder that's a sibling of my workspaces folder (which now becomes partially empty), with a sub-folder under that for each workspace, and then a related projects group (or two or three) under each workspace, and the specific related projects under each of these related groups folders. The git folder gets created off each related group folder. – Carl Aug 02 '13 at 09:32
  • My understanding is that once you add stuff to the staging area and commit it, your source code no longer exists in a permanent usable form; it gets retrieved from the object database (directory) when you check out a specific version, and overwrites whatever is in your working tree (the area that used to be your project source folder hierarchy before you put stuff under version control). I guess you might need to hit F5 in Eclipse to refresh before building, after moving to a different version, so that it picks up the altered source files - at least if you were using git rather than EGit. – Carl Aug 02 '13 at 09:40