[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Status of EGit and the like:
EGit works in conjunction with Eclipse, but there are some features
which are missing to have an Eclipse-only view of Git projects at the
moment.
However, I suspect the biggest transition is going to be in
understanding the differences between DVCS and CVCS ... I put together
some documentation at
http://wiki.eclipse.org/EGit/Git_For_Eclipse_Users (which is now in
the EGit docs, thanks Chris!) which would be worthwhile reading.
The key thing that's missing at the moment is full merge support. What
EGit supports at the moment, as Chris said, is 'fast-forward merge',
which probably doesn't mean a lot. Essentially, if you have some
checkouts which are on a slightly older version of the tree (say,
HEAD) then you can move your branches forward to that point. So given:
-A-B-C-D-E
\C'
if you have a development branch on C', and the head has moved on to
E, then you can fast-forward merge onto:
-A-B-C-D-E
\E'
A non-fast forward merge is when it's not possible to update this, and
you end up with a 'loop' in the tree. This will typically happen if
someone changes the same file in a changeset (plugin.xml and
MANIFEST.MF are the likely candidates) and you end up with a loop in
the stream. In the first case, if we'd changed duplicate info, we'd
end up with:
-A-B-C-D-E
\C'
being merged to:
-A-B-C-D-E-F
\C'-----/
In this case, F is a merge node which has two parents. EGit doesn't
support this at the moment, though the command line tool does, and
EGit supports reading repositories with such merges if they're done
outside of EGit.
It's worth noting that EGit are doing all of their development in EGit
(and with JGit) but that Gerrit handles much of the missing features
at the moment. However, they're all familiar with (a) the git command
line tool and (b) the underlying concepts behind DVCS. I honestly
think the latter is going to be more of a challenge than the former
for the CDT community.
Whether there's interest in using it ahead of the 0.9.0 release, or
whether CDT devs are happy with using the nightly builds for EGit is a
separate question. The goal will be for all of this to be fixed for
1.0.0, but the 0.9.0 will address the key missing parts that will make
it usable for day-to-day work.
In the interim, it might make sense to convert a small project to get
a feel for how it works, rather than doing a big-bang conversion.
Feedback could then be given to the EGit team as to how to improve
things :-)
The other thing that could be done is deciding on how to lay out the
Git repositories. As you may (not) know, a Git repository can't be
partially checked out (the way that CVS or SVN can) - it's all or
nothing in the repository. In addition, merges and keeping in sync
only happens within a single Git repository - submodules address some
of that and might be used to tie up the CDT release at the top level,
but wouldn't really be necessary (and EGit doesn't support submodules
yet). Doing it on a bundle-by-bundle basis is probably wrong; you'd
ideally want bundle+tests in the same git repository. In addition,
refactorings (e.g. coupling between a UI and non-UI bundle) might
merit being in the same repository.
It is possible to both merge Git repositories and split them after the
fact (EGit and JGit started life as a single repo, now are two) as
well as maintaining full history, so it's not a final decision. But
planning on how it should look is something that can be done ahead of
the tool support.
Alex
