Well, things finally seem even more complicated: in my case, the tree
is a bit more particular than what I originally thought:
* I finally understand I read the --onto description wrong. It could
surely be made easier to understand, by telling the user he first
has to import the subproject history into the superproject repo
first. Adding an example of this would be of great use too.
* In my case the directory in which the kernel was originally located
has since then been renamed, and git-subtree stops exploring the
history at the rename commit, assuming the full import occured there.
Maybe git-subtree can be taught to follow renames, but currently the
way to handle that would seem to split in 2 steps:
- checkout the revision before the move
- split that part of history using the old name (without
--rejoin, and with a different --branch name than intended in
the end)
- checkout the head to be split
- split the remaining part, passing --onto the branch name that was
passed to --branch in the first run
However, if I try that, the root of the second split has no parent.
I can use a graft and filter-branch - but there is either something
else I did not understood incorrectly, or maybe a bug somewhere ?
Best regards,
--
Yann Dirson - Bertin Technologies
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html