Re: [git-users] moving top of branch to another repository
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 git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[git-users] moving top of branch to another repository
hi group, I recently started a new branch in a project. It appeared that the branch only contained new software and was not based on the rest of the project. I want to move that branch to a new repository, but not all of the history of the original project. I found out with the help of google, it is possible to git-push a branch to a new repository, but then all the history of the project comes with it, not only from the point where the branch started. A-B-C-D \ E-F-G Both D and E-F-G are based on C. I only want to move E-F-G to a new repo The best I can think of is this: * git push the branch to a new repository (giving A-B-C-E-F-G) * with git-rebase delete all of the old project commits A-B-C Is this the only way? thanks in advance, Ruud -- 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.
Re: [git-users] moving top of branch to another repository
On Thursday, 3 October 2013 11:51:28 UTC+2, Konstantin Khomoutov wrote: I think yes, this is the only way because you need to squash A-C into a new commit, C', and then reapply E-G on top of it, and that's what `git rebase` is goot at. Hi Konstatin, thank you for your reply. I was a bit afraid this was the way to go. If I focus on first pushing the whole of the branch A-G to a new repository: when I squash A-C into commit C', it still leaves me with a commit isn't it? Although I need no single file in that commit. I can empty it, but it still leaves me with that node. No possibility to make E the root node of the repository? regards, Ruud Note that you might as well do squashing in the original repo and then push the modified history: first fork a new branch off G, then rebase it, then push, then delete. -- 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.
Re: [git-users] moving top of branch to another repository
On Thu, 3 Oct 2013 03:56:03 -0700 (PDT) ruud r.grosm...@gmail.com wrote: I think yes, this is the only way because you need to squash A-C into a new commit, C', and then reapply E-G on top of it, and that's what `git rebase` is goot at. thank you for your reply. I was a bit afraid this was the way to go. If I focus on first pushing the whole of the branch A-G to a new repository: when I squash A-C into commit C', it still leaves me with a commit isn't it? Although I need no single file in that commit. I can empty it, but it still leaves me with that node. No possibility to make E the root node of the repository? Sure it's possible: just squash A-E into E' not A-C into C' -- there's really no difference, I've just failed to discern from your message that you did not want C as well. If you'are worried by the fact D references C as well as E, and that squashing A-E would affect D, then fear not: parental relation between commits is implemented in reverse -- children refernce their parents while parents do not know anything about their childen, -- and `git rebase` creates new commits not *replaces* those which were created when rebasing so your A-B-C-D - foo \ E-F-G - bar (with foo and bar being refs (tags or branches) pointing to their respective commits) after squashing A-E into E' and rebasing F-G onto E' would look like A-B-C-D - foo E'-F'-G' - bar That is, D will reference the same chain of commits as before while bar will reference a new chain with all new commits; E' will be synthetic and F' and G' will be mostly the same as their original commits F and G but with their commit dates changed. Let's recap: when `git rebase` creates new commits, old ones are left intact and they either persist (if they're still referenced by a ref) or become dangling and are eventually garbage-collected. They're not *replaced* in the sense of being modified in-place; they're replaced only from the point-of-view of a reference which has been rebased and now points to a new chain of commits. Note though that there's no such thing as a root node of a repository: a Git repository might contain arbitrary number of branches which share no commits (and even no other kinds objects such as trees and blobs). So the correct spelling would be a root commit of the new branch. That's nitpicking, but I thought it won't hurt clarifying to possibly prevent future confusion. -- 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.
