Re: git-subtree: bug, and ideas for doc improvements

[Yann Dirson <dirson@bertin.fr>]

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