From: Alex Riesen <hidden> Date: 2016-06-15 22:46:45
2009/5/13 Ittay Dror [off-list ref]:
quoted
Alex Riesen wrote:
quoted
* 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
quoted
* 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").
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.
* 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.
tried git rebase, this is what i get:
> git rebase -i upstream master
fatal: Needed a single revision
Invalid base
quoted
quoted
quoted
* 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
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.
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
From: Johannes Sixt <hidden> Date: 2016-06-15 22:46:45
Ittay Dror schrieb:
Alex Riesen wrote:
quoted
2009/5/13 Ittay Dror [off-list ref]:
quoted
quoted
Alex Riesen wrote:
quoted
* 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.
tried git rebase, this is what i get:
quoted
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
* 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.
tried git rebase, this is what i get:
quoted
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.
same thing:
> git rebase -i --onto upstream old-upstream master
fatal: Needed a single revision
Does not point to a valid commit: upstream
From: Alex Riesen <hidden> Date: 2016-06-15 22:46:45
2009/5/13 Ittay Dror [off-list ref]:
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
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.
From: Alex Riesen <hidden> Date: 2016-06-15 22:46:45
2009/5/13 Ittay Dror [off-list ref]:
Johannes Sixt wrote:
quoted
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.
same thing:
quoted
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.
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
quoted
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.
From: Alex Riesen <hidden> Date: 2016-06-15 22:46:45
2009/5/13 Ittay Dror [off-list ref]:
Alex Riesen wrote:
quoted
2009/5/13 Ittay Dror [off-list ref]:
quoted
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?
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)
(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.