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 


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 git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to