[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
> 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:
I don't think this right.
A normal (non fast-forward) merge occurs whenever there have been
_any_ changes on the local branch which aren't reflected in the
incoming branch. i.e. fast-forward is a special case which only
occurs when there have been no local changes since the branch was last
pulled... It doesn't matter where the changes were made, the merge
node will have two (or more) parents if the merged branches have
different commits.
I found this a great help for getting my head around git:
http://eagain.net/articles/git-for-computer-scientists/
It's not too verbose and explains the fundamental building blocks
which puts the command set into perspective.
> 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 :-)
I think one of the first steps is a read-only git repo from CVS which
tracks HEAD. Interested committers can start playing with it and
testing out the tooling without committing ourselves to a drastic
migration... There are now a few of us interested in this that would
make this a good start.
Cheers,
James
