Hi Konstatin, thanks to you mentioning git filter-branch I found out it is possible to have two seperated trees in a repository. Your reply was not in this thread, so I include in at the bottom of this reply.
This is what I succesfully tried in another repo: - in that repo I had a branch only containing new files, my goal is to have a repo with only the commits and files that were introduced where the branch started. - a problem was formed by the files of the main project that I don't need anymore. You explained that they come to live after rebasing again unless some measures are taken. I tried *git filter-branch* and found a new tree in the repository. That gave me an idea. After some reading of documentation I came up with this: - I made a completely new commit, apart from the existing tree with 'git commit --orphan new' - in commit new I removed all files with git rm -r - made a branch with git branch x - rebased the commits I needed onto (empty branch) x with git rebase --onto x start_branch^ head_branch - leaving me in exactly the situation I wanted (apart from the x-commit, which I can squash with the first commit of the rebased branch). The branch now only contained the files that where introduced by it, not the unrelated files in the main tree. Konstatin, thanks for the help and the inspiration. The sun is shining again! Ruud Konstatin wrote: *Yes, basically in the rebase script presented to you by `git rebase` you change the action for A to "edit" (and change its title when prompted), then change the actions for B-E to "fixup" and then leave the actions for F-G as "pick". The result would be E' created of A (with modified title) plus B-E squashed into it and F-G picked on top of that E'. But note that you mentioned A contains lots of unwanted files. It wasn't obvious to me you wanted to get rid of some files and not just squash several commits into one. It might turn out that you might want to make "delete" the action for A and adjust the actions for B-E accordingly. Also note that if a file you intend to delete from A has been modified in any of commits B-G, a mere deletion of A during the rebase operation would not be enough: the file deleted by wiping off A would be "magically" brought to life in the nearest commit in which a changed state of that file has been recorded. So you might consider first running `git filter-branch` on your branch-to-be-extracted to actually get rid of all the unwanted files through the whole range of the branch's commits.* -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
