On 21 November 2011 17:12, Stephan Herrmann
<stephan@xxxxxxxxxxxxxxx> wrote:
Our repo contains a fork of org.eclipse.jdt.core, from which I periodically
fetch all changes and apply them to our fork. So far I'm doing this by manually
creating and applying patches, but in git times I figure I should just setup
the original jdt.core repo as a remote and use commands like cherry pick
for updating.
(Side issue: can I cherry pick (in EGit) many commits in one operation?)
Unfortunately, both repos don't match in structure, the jdt.core plugin
resides in these locations:
repo: eclipse.jdt.core
path: /org.eclipse.jdt.core
vs.
repo: org.eclipse.objectteams
path: /plugins/org.eclipse.jdt.core
The subtree merge does precisely this. If there's a foreign git repo, whose content corresponds to a subdirectory of your main repo, then you can mark the point where the repo's were most recently in sync (using a graft, say), and then use git merge -s subtree to merge in more recent changes.
Now cherry-picking works, but EGit's history shows the moved version
as having no history. Is there a way to tell EGit to follow moves? If that's
possible, is it advisable to move a whole project so every history lookup
will require matching all those files across different paths?
To me this sounds more fragile than a move was in svn - am I missing
anything?
Next I'm thinking of deep-diving into some variant of svn2git to see if
it can do the move during migration so we won't lose history.
Does anybody have experience with re-shuffling the directory structure
during svn2git? If so, which "svn2git" should I use, given there are several
different tools of the same name.
CGit can track renames and moves without problem (and git-blame tends to track the origin of lines well).
If you want to move content around, changing history, then having done the conversion you can git-filter-branch to change branches and tags to the layout of your choice.
