switching upstream tips

switching upstream tips

[Ittay Dror]

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

Re: switching upstream tips

[Alex Riesen]

2009/5/13 Ittay Dror <ittay.dror@gmail.com>:
> 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.

> * 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)

> * Change the upstream repository reference so it points to the new
> repository

Just edit your .git/config and re-fetch.

> * 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").

Re: switching upstream tips

[Ittay Dror]

Alex Riesen wrote:

> 2009/5/13 Ittay Dror <ittay.dror@gmail.com>:
>   
>> 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.
>
>   
>> * 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
>   
>> * 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.
>   
>> * 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").
>   

Re: switching upstream tips

[Alex Riesen]

2009/5/13 Ittay Dror <ittay.dror@gmail.com>:
>> Alex Riesen wrote:
>>> * 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.

>>> * 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.

Re: switching upstream tips

[Ittay Dror]

Alex Riesen wrote:

> 2009/5/13 Ittay Dror <ittay.dror@gmail.com>:
>   
>>> Alex Riesen wrote:
>>>       
>>>> * 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

>   
>>>> * 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.
>   
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

Re: switching upstream tips

[Johannes Sixt]

Ittay Dror schrieb:
> Alex Riesen wrote:
>> 2009/5/13 Ittay Dror <ittay.dror@gmail.com>:
>>>> Alex Riesen wrote:
>>>>> * 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

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

Re: switching upstream tips

[Ittay Dror]

Johannes Sixt wrote:

> Ittay Dror schrieb:
>   
>> Alex Riesen wrote:
>>     
>>> 2009/5/13 Ittay Dror <ittay.dror@gmail.com>:
>>>       
>>>>> Alex Riesen wrote:
>>>>>           
>>>>>> * 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
>>     
>
> 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

> -- Hannes
>
>   

Re: switching upstream tips

[Johannes Sixt]

Ittay Dror schrieb:
> same thing:
>> 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

Re: switching upstream tips

[Alex Riesen]

2009/5/13 Ittay Dror <ittay.dror@gmail.com>:
> Johannes Sixt wrote:
>> 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

Well, don't put random characters where your branch names should be.

Re: switching upstream tips

[Alex Riesen]

2009/5/13 Ittay Dror <ittay.dror@gmail.com>:
>
> 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

>> 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.

Re: switching upstream tips

[Ittay Dror]

Alex Riesen wrote:
> 2009/5/13 Ittay Dror <ittay.dror@gmail.com>:
>   
>> 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)
>   
>>> 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.
>   

Re: switching upstream tips

[Alex Riesen]

2009/5/13 Ittay Dror <ittay.dror@gmail.com>:
> Alex Riesen wrote:
>> 2009/5/13 Ittay Dror <ittay.dror@gmail.com>:
>>>
>>> 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.