switching upstream tips
Hi,
I'm working on a repository in github that is forked from another repository. I've committed several times and pulled (merged) from the upstream a few times (so the committs are interleaved). The upstream repository is a clone of an SVN repository (in apache). The project has switched svn repositories (moved from incubation to top level project) and so created a new repository in github.
Now I want to start working with the new upstream repository. My problem is that because of the changes in the backing SVN, the objects are completely new, so when i try 'git pull new-upstream master', I get a lot of add/add conflicts. Most of the conflicts show the whole file has changed while actually just a few lines differ. So I'm having trouble making sense of the mess.
What I'm trying to figure out is how to do the following:
* Reorder my history so that my commits are on top of the tip of the old upstream repository.
* Change the upstream repository reference so it points to the new repository
* Apply my commits on top of the new upstream repository
Of course any other alternative which will allow me to continue to work with the new upstream is also welcome.
Thank you,
Ittay
2009/5/13 Ittay Dror <[email protected]>:
Quoted 6 lines
I'm working on a repository in github that is forked from another repository. I've committed several times and pulled (merged) from the upstream a few times (so the committs are interleaved). The upstream repository is a clone of an SVN repository (in apache). The project has switched svn repositories (moved from incubation to top level project) and so created a new repository in github.
That's evil.
Quoted 2 lines
* Reorder my history so that my commits are on top of the tip of the old upstream repository.
Look at "git rebase -i" (interactive rebase)
Quoted 2 lines
* Change the upstream repository reference so it points to the new repository
Just edit your .git/config and re-fetch.
Quoted 1 line
* Apply my commits on top of the new upstream repository
You can try to cherry-pick your commits (git cherry-pick). Maybe rename detection will be enough to apply your changes as is. But as far as I understand, the path names in the new upstream are now all different (moved a level up?). You can save your commits in a mbox:
git format-patch -o mbox old-upstream..your-last-commit
Edit the paths in the mbox and try to apply the result:
git am -3 result.mbox
Or, you can use git filter-branch to modify the old history as if it was always operating on the directory structure of the new upsteam (assuming it is possible, of course). See manpage of git filter-branch, there is an example (look for "move the whole tree into a subdirectory").
A message that is not in the archive (sent off-list or not yet received): [email protected]
2009/5/13 Ittay Dror <[email protected]>:
Quoted 9 lines
Quoted 5 lines
Quoted 2 lines · Alex Riesen
* Reorder my history so that my commits are on top of the tip of the old upstream repository.
Look at "git rebase -i" (interactive rebase)
well, i was hoping for something more automatic. git rebase will list all commits without author, so i'll have to manually figure which of them is mine from the commend and reorder
git rebase will list only commits not on upstream (simplified). Has nothing to do with author being absent.
Quoted 7 lines
Quoted 4 lines
Quoted 2 lines
* Change the upstream repository reference so it points to the new repository
Just edit your .git/config and re-fetch.
but then git suddenly sees a bunch of new objects (because of the svn changes) and i get a lot of conflicts.
"git fetch" and "git remote update" do not produce conflicts. You cannot get them unless you also do a merge (like when you do "git merge" or "git pull").
Quoted 3 lines
note that it is not the directory structure that changed, just the svn repository which is included in the commit comment (by git-svn) and so changes the commit sha1.
Ok, that simplifies everything. Just cherry-pick (see "git cherry-pick") your commits on new upstream. You might find it easiest if you cherry-pick them on commits in new upstream which correspond the old-upstream exactly.
Quoted 9 lines · Alex Riesen
2009/5/13 Ittay Dror <[email protected]>:
Quoted 7 lines
Quoted 7 lines
Quoted 3 lines · Alex Riesen
* Reorder my history so that my commits are on top of the tip of the old upstream repository.
Look at "git rebase -i" (interactive rebase)
Quoted 8 lines
Quoted 4 lines
well, i was hoping for something more automatic. git rebase will list all commits without author, so i'll have to manually figure which of them is mine from the commend and reorder
git rebase will list only commits not on upstream (simplified). Has nothing to do with author being absent.
tried git rebase, this is what i get:
Quoted 1 line
git rebase -i upstream master
fatal: Needed a single revision
Invalid base
Quoted 20 lines
Quoted 9 lines
Quoted 6 lines
Quoted 4 lines
* Change the upstream repository reference so it points to the new repository
Just edit your .git/config and re-fetch.
but then git suddenly sees a bunch of new objects (because of the svn changes) and i get a lot of conflicts.
"git fetch" and "git remote update" do not produce conflicts. You cannot get them unless you also do a merge (like when you do "git merge" or "git pull").
Quoted 4 lines
note that it is not the directory structure that changed, just the svn repository which is included in the commit comment (by git-svn) and so changes the commit sha1.
Quoted 5 lines
Ok, that simplifies everything. Just cherry-pick (see "git cherry-pick") your commits on new upstream. You might find it easiest if you cherry-pick them on commits in new upstream which correspond the old-upstream exactly.
can you explain a bit more how to work with git cherry-pick? if i understand correctly, i need to write down my commits, switch to the new upstream tip ('git checkout upstream master'?) and then call git cherry-pick for each of my commits.
ittay
Quoted 15 lines · Ittay Dror
Quoted 14 lines · Alex Riesen
2009/5/13 Ittay Dror <[email protected]>:
Quoted 12 lines
Quoted 7 lines
Quoted 4 lines · Alex Riesen
* Reorder my history so that my commits are on top of the tip of the old
upstream repository.Look at "git rebase -i" (interactive rebase)
well, i was hoping for something more automatic. git rebase will list all
commits without author, so i'll have to manually figure which of them is mine from the commend and reorder
Quoted 7 lines
Quoted 3 lines
git rebase will list only commits not on upstream (simplified). Has nothing to do with author being absent.
tried git rebase, this is what i get:
Quoted 1 line
git rebase -i upstream master
fatal: Needed a single revision
Invalid base
I guess it should have been
git rebase -i --onto new-upstream old-upstream master
That is, you take commits old-upstream..master and transplant them onto new-upstream.
-- Hannes
Quoted 34 lines · Johannes Sixt
Quoted 24 lines · Ittay Dror
Quoted 12 lines · Alex Riesen
2009/5/13 Ittay Dror <[email protected]>:
Quoted 10 lines
Quoted 10 lines
Quoted 5 lines · Alex Riesen
* Reorder my history so that my commits are on top of the tip of the old
upstream repository.Look at "git rebase -i" (interactive rebase)
Quoted 10 lines
Quoted 6 lines
well, i was hoping for something more automatic. git rebase will list all
commits without author, so i'll have to manually figure which of them is mine from the commend and reordergit rebase will list only commits not on upstream (simplified). Has nothing to do with author being absent.
Quoted 7 lines
tried git rebase, this is what i get:
Quoted 2 lines
git rebase -i upstream master
fatal: Needed a single revision
Invalid base
Quoted 7 lines
I guess it should have been
git rebase -i --onto new-upstream old-upstream masterThat is, you take commits old-upstream..master and transplant them onto new-upstream.
same thing:
Quoted 1 line
git rebase -i --onto upstream old-upstream master
fatal: Needed a single revision
Does not point to a valid commit: upstream
Quoted 3 lines
-- Hannes
Quoted 4 lines · Ittay Dror
same thing:
Quoted 1 line
git rebase -i --onto upstream old-upstream master
fatal: Needed a single revision
Does not point to a valid commit: upstream
I guess you don't have a branch with the name "upstream". Use the name (or SHA1) that designates your upstream.
-- Hannes
2009/5/13 Ittay Dror <[email protected]>:
Quoted 5 lines
Quoted 4 lines · Johannes Sixt
I guess it should have been
git rebase -i --onto new-upstream old-upstream master
Quoted 8 lines
Quoted 3 lines
That is, you take commits old-upstream..master and transplant them onto new-upstream.
same thing:
Quoted 1 line
git rebase -i --onto upstream old-upstream master
fatal: Needed a single revision
Does not point to a valid commit: upstream
Well, don't put random characters where your branch names should be.
2009/5/13 Ittay Dror <[email protected]>:
Quoted 5 lines
tried git rebase, this is what i get:
git rebase -i upstream master
fatal: Needed a single revision
Invalid base
$ git checkout my-old-master-based-on-old-upstream $ git rebase -i old-upstream
Quoted 9 lines
Quoted 4 lines
Ok, that simplifies everything. Just cherry-pick (see "git cherry-pick") your commits on new upstream. You might find it easiest if you cherry-pick them on commits in new upstream which correspond the old-upstream exactly.
can you explain a bit more how to work with git cherry-pick? if i understand correctly, i need to write down my commits, switch to the new upstream tip ('git checkout upstream master'?) and then call git cherry-pick for each of my commits.
$ gitk old-upstream-with-my-changes-on-top & $ git checkout -b my-new-master-on-top-of-new-upstream new-upstream ...select a commit in gitk... $ git cherry-pick <paste-the-selected-commit-here> # hit Enter
repeat until you run out of commits you want to have on top of the new upstream.
Quoted 11 lines · Alex Riesen
2009/5/13 Ittay Dror <[email protected]>:
Quoted 5 lines
tried git rebase, this is what i get:
git rebase -i upstream master
fatal: Needed a single revision
Invalid base$ git checkout my-old-master-based-on-old-upstream $ git rebase -i old-upstream
so i need to create an 'old-upstream' branch first, that is based on the tip of the old-upstream remote, right? how? (thanks for the patience)
Quoted 19 lines
Quoted 11 lines
Quoted 6 lines
Ok, that simplifies everything. Just cherry-pick (see "git cherry-pick") your commits on new upstream. You might find it easiest if you cherry-pick them on commits in new upstream which correspond the old-upstream exactly.
can you explain a bit more how to work with git cherry-pick? if i understand correctly, i need to write down my commits, switch to the new upstream tip ('git checkout upstream master'?) and then call git cherry-pick for each of my commits.
$ gitk old-upstream-with-my-changes-on-top & $ git checkout -b my-new-master-on-top-of-new-upstream new-upstream ...select a commit in gitk... $ git cherry-pick <paste-the-selected-commit-here> # hit Enterrepeat until you run out of commits you want to have on top of the new upstream.
2009/5/13 Ittay Dror <[email protected]>:
Quoted 9 lines
Quoted 8 lines · Alex Riesen
2009/5/13 Ittay Dror <[email protected]>:
Quoted 6 lines
tried git rebase, this is what i get:
git rebase -i upstream master
fatal: Needed a single revision
Invalid base
Quoted 6 lines
Quoted 3 lines
$ git checkout my-old-master-based-on-old-upstream $ git rebase -i old-upstreamso i need to create an 'old-upstream' branch first, that is based on the tip of the old-upstream remote, right? how?
no. Just use the remote reference. Should be something like origin/master. It is the reference to the commit where to put your commits on. You can use the SHA1 there, if you wish. All the rebasing happens on and to that branch of yours (my-old-master-based-on-old-upstream in the example above)
Quoted 1 line
(thanks for the patience)
This patience is just about to end. Ever looked at the man pages? "git help git" can be a good start.
Quoted 10 lines · Alex Riesen
2009/5/13 Ittay Dror <[email protected]>:
Quoted 7 lines
I'm working on a repository in github that is forked from another repository. I've committed several times and pulled (merged) from the upstream a few times (so the committs are interleaved). The upstream repository is a clone of an SVN repository (in apache). The project has switched svn repositories (moved from incubation to top level project) and so created a new repository in github.
Quoted 9 lines
That's evil.
Quoted 3 lines
* Reorder my history so that my commits are on top of the tip of the old upstream repository.
Look at "git rebase -i" (interactive rebase)
well, i was hoping for something more automatic. git rebase will list all commits without author, so i'll have to manually figure which of them is mine from the commend and reorder
Quoted 7 lines
Quoted 4 lines
* Change the upstream repository reference so it points to the new repository
Just edit your .git/config and re-fetch.
but then git suddenly sees a bunch of new objects (because of the svn changes) and i get a lot of conflicts. note that it is not the directory structure that changed, just the svn repository which is included in the commit comment (by git-svn) and so changes the commit sha1.
Quoted 22 lines
Quoted 3 lines
* Apply my commits on top of the new upstream repository
You can try to cherry-pick your commits (git cherry-pick). Maybe rename detection will be enough to apply your changes as is. But as far as I understand, the path names in the new upstream are now all different (moved a level up?). You can save your commits in a mbox:
git format-patch -o mbox old-upstream..your-last-commit
Edit the paths in the mbox and try to apply the result:
git am -3 result.mbox
Or, you can use git filter-branch to modify the old history as if it was always operating on the directory structure of the new upsteam (assuming it is possible, of course). See manpage of git filter-branch, there is an example (look for "move the whole tree into a subdirectory").