[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [egit-dev] Layout when the project is in the repository root
|
On Thu, Dec 17, 2009 at 11:04 AM, Thomas Hallgren <thomas@xxxxxxx> wrote:
> I've noticed that for some git projects, the project is at the repository
> root. I.e. the repository is the project. This means that in my workspace, I
> will get an Eclipse project that in fact is the same as the Git repository
> (the .git folder is in the project). While that works, it's perhaps not so
> great when I delete the project since I then also delete the repository.
You delete your clone of the repository, yes. But other clones that
you have pushed to will still have that data. Of course, if you
haven't pushed to any clones, then you're essentially throwing it away
too. (Maybe we could have a warning when deleting a .git directory
with no remotes defined?)
> What layout would you recommend for cases like that? Should a 'checkout'
> folder be created that is the actual project?
I think one git repo per project is doable, but it then precludes the
ability to have multiple projects (say, client+server, or bundle+test)
in the same repository, which is a good thing in a number of cases. So
I'd suggest having a top-level repository which then contained one
folder per project, with the result you'd just check out that project.
The git repo could be created in the parent directory, giving the
option of having multiple projects checked out in the same repository
at a later stage.
It's worth noting that if you follow this policy, then all projects in
the same git repository must be on the same branch at all times. This
is different from the CVS case where each can be on its own branch;
I'm not sure whether it's different from SVN too. If it is, we might
be wise to consider warning the user that other projects will also be
switched if they share the same git repository.
(Note that this doesn't apply if you have two clones of the same
remote git repository, but you'd have to sync between the two using a
push/pull action, which is probably less elegant to achieve)
Alex
