Re: split directories into branches

[Konstantin Khomoutov <kostix+git@007spb.ru>]

On Mon, 4 Jul 2016 12:45:39 -0400
shawn wilson <ag4ve.us@gmail.com> wrote:

> I've got a chef cookbook repo where everyone started developing
> cookbooks in a single dev branch (not project specific). Minus a few
> edge cases, it should be fairly simple to split this up into feature
> branches based on /cookbooks/<feature>.
> 
> I tried:
> $ git filter-branch --subdirectory-filter cookbooks/<feature>--
> <feature> And
> $ git subtree split --prefix cookbooks/<feature> -b <feature>
> 
> Which both seem to do the same thing (haven't looked at the subtree
> bash - guessing it does exactly the filter-branch). The issue is that
> it removes the directory tree (so obviously merges wouldn't work). I'm
> thinking some type of filter-branch --index-filter with a cherry pick
> (or similar) should work...?

To achieve what you're after I used `git subtree split` followed by
`git filter-branch --tree-filter ...` which moved all the files under
the directory hierarchy `git subtree split` removes.

I'd love if `git subtree split` had an option to preserve the prefix
(even better would be to have another option to rewrite the prefix)
because that would greatly simplify another use case for `git subtree`:
moving "a directory" with its full history from one repository into
another.  Presently, the user is able to split that directory out from
the source repository but when they subtree-merge it back in the new
repository, they are puzzled by the fact `git log` invoked on the new
history with the pathname prefix designating the "inserted" directory
does not traverse past the merge point which brought that directory in.

I know Git tracks content, not files (and directory) but still many
folks have "stable" directories for their files, assign certain
semantics to them etc.  I've needed such transfers myself, and this
topic has been raised more than once by folks over there on the
git-users mailing list.