Re: [egit-dev] Moving the Scala Eclipse tooling to git

[Shawn Pearce <spearce@xxxxxxxxxxx>]

On Thu, Apr 8, 2010 at 3:14 AM, Miles Sabin <miles@xxxxxxxxxxxxxx> wrote:
> I've decided to finally take the plunge and move the Scala Eclipse
> tooling over to git, but I have a few questions about how best to
> approach things given jgit/egit's current state of development.
>
> My understanding is that jgit/egit don't support submodules yet. Is
> that so? If they don't, do you have any idea when you'd expect to see
> submodule support arriving?

Correct.  These don't fully support submodules yet, to the extent that
if a submodule is present, EGit can cause tree corruption or crash.
:-(

Its not currently on a roadmap to fix this.  We know about the
problem, but I don't think anyone has volunteered to address it.  We
should try to fix it before 0.8 however, its a pretty glaring problem.

> The issue for me is that I would like to keep the core scala toolchain
> (ie. compiler and standard libs) somewhat separate from the IDE
> specific components (ie. at least one repository for the core
> toolchain/libs and at least one repository for the IDE), but I still
> need to be able to commit atomically across both. I believe the git
> way of doing this is with submodules, whereas egit currently only
> supports multiple Eclipse projects within a single git repository and
> chokes on repositories which are set up as submodules.

Yes, that's true.

> I also gather that egit doesn't yet support merging in general, and
> presumably subtree merges in particular. Assuming I get by with the
> command line tools for (subtree) merges now are there any issues I
> should be aware of?

Also true.  We don't support either merges, or subtree merges.  But if
you did the subtree merge (or any other merge) on the command line,
EGit will be fine with the result.  So long as no submodules are used.

Needing to us subtree merge to work around EGit is less than optimal,
its going to cause the parent project to import the history of the
subproject for all time.  Though this might not be all that bad, an
advantage is you can more easily setup the parent project via a single
git clone.  Submodules would require a few more commands to also get
the submodule projects into the same checkout area.

If you use subtree merge and are OK with having the history of the
subproject in the parent project, then that's a reasonable way to go
right now, today.  git.git still uses subtree merge to bring in gitk
and git-gui, even though submodules have been available "for a while
now".

-- 
Shawn.