change parent location and be able to merge

Asked by Jared Silva on 2012-06-05

bzr branch lp:pithos used to branch from http://bazaar.launchpad.net/~kevin-mehall/pithos/trunk/, but it now branches from http://bazaar.launchpad.net/~kevin-mehall/pithos/git-import/, I think.

http://bazaar.launchpad.net/~kevin-mehall/pithos/trunk/ is no longer updated.

bzr branch http://bazaar.launchpad.net/~kevin-mehall/pithos/trunk/
Branched 206 revisions.
bzr info trunk
  parent branch: http://bazaar.launchpad.net/~kevin-mehall/pithos/trunk/

bzr branch lp:pithos
Branched 220 revisions.
bzr info pithos
  parent branch: http://bazaar.launchpad.net/~kevin-mehall/pithos/git-import/

If I change the parent location/branch from ~kevin-mehall/pithos/trunk to ~kevin-mehall/pithos/git-import, which is now where lp:pithos points, I cannot merge to get my branch from r206 to r220.

cd trunk
bzr config parent_location=http://bazaar.launchpad.net/~kevin-mehall/pithos/git-import/
bzr info
  parent branch: http://bazaar.launchpad.net/~kevin-mehall/pithos/git-import/
bzr merge
Merging from remembered parent location http://bazaar.launchpad.net/~kevin-mehall/pithos/git-import/
bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified.

bzr config parent_location=http://bazaar.launchpad.net/~kevin-mehall/pithos/trunk/
bzr info
  parent branch: http://bazaar.launchpad.net/~kevin-mehall/pithos/trunk/
bzr merge
Merging from remembered parent location http://bazaar.launchpad.net/~kevin-mehall/pithos/trunk/
Nothing to do.

How can I change the parent location from the old location to the new location and be able to merge the latest changes into my branch? I cannot just use a new bzr branch because my branch has commits, merges, history, etc, that I do not want to lose.

Question information

Language:
English Edit question
Status:
Solved
For:
Bazaar Edit question
Assignee:
No assignee Edit question
Solved by:
Jared Silva
Solved:
2012-06-13
Last query:
2012-06-13
Last reply:
2012-06-07
John A Meinel (jameinel) said : #1

Is there a problem with 'bzr merge --remember lp:pithos' ?

Jared Silva (jayrod) said : #2

Same result.

bzr merge --remember lp:pithos
bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified.

Jared Silva (jayrod) said : #3

Perhaps different revision ids has something to do with it?

bzr log http://bazaar.launchpad.net/~kevin-mehall/pithos/trunk/ -c 206 --show-ids
------------------------------------------------------------
revno: 206
revision-id: <email address hidden>
parent: <email address hidden>
committer: Kevin Mehall <email address hidden>
branch nick: trunk
timestamp: Tue 2012-04-17 10:39:56 -0600

bzr log http://bazaar.launchpad.net/~kevin-mehall/pithos/git-import/ -c 206 --show-ids
------------------------------------------------------------
revno: 206
revision-id: git-v1:43a9de014f37ab59f1fe60ddf06501c4c6cfce67
parent: git-v1:6d10e5f0e6b0d6c0c7e9de8416bff7fac596240e
committer: Kevin Mehall <email address hidden>
timestamp: Tue 2012-04-17 10:39:56 -0600

John A Meinel (jameinel) said : #4

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 6/6/2012 5:35 AM, Jared Silva wrote:
> Question #199401 on Bazaar changed:
> https://answers.launchpad.net/bzr/+question/199401
>
> Jared Silva gave more information on the question: Perhaps
> different revision ids has something to do with it?
>
> bzr log http://bazaar.launchpad.net/~kevin-mehall/pithos/trunk/ -c
> 206 --show-ids
> ------------------------------------------------------------
> revno: 206 revision-id:
> <email address hidden> parent:
> <email address hidden> committer: Kevin
> Mehall <email address hidden> branch nick: trunk timestamp: Tue
> 2012-04-17 10:39:56 -0600
>
> bzr log
> http://bazaar.launchpad.net/~kevin-mehall/pithos/git-import/ -c 206
> --show-ids
> ------------------------------------------------------------
> revno: 206 revision-id:
> git-v1:43a9de014f37ab59f1fe60ddf06501c4c6cfce67 parent:
> git-v1:6d10e5f0e6b0d6c0c7e9de8416bff7fac596240e committer: Kevin
> Mehall <email address hidden> timestamp: Tue 2012-04-17 10:39:56
> -0600
>

The branches don't seem to be related. One is a native bzr branch, and
the other is a conversion-from-git branch.

Is one of these a primary? (Was the code originally in git or bzr?)

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk/PMKgACgkQJdeBCYSNAAOPaACeMGphhs6GUiXuqQCO9OsKTpKy
KWwAn3khr0lcDnY4fRAuGGfJiZtfr+XP
=buhZ
-----END PGP SIGNATURE-----

Jared Silva (jayrod) said : #5

The code was originally in bzr, but it looks like the author moved to git.

bzr log -c 208
------------------------------------------------------------
revno: 208
message:
  Moving to git

Looks like the original lp:pithos pointed to a bzr repository, but has since been migrated to git, lp:pithos now points to a git repository, and the original bzr repository is not being updated against the new git repository.

Where does this leave all of the bzr repositories that branched from the original bzr repository? Are they all orphaned? Is there a good way for these branches to move on? r206 in the bzr repository is the "same" as r206 in the git repository. I know in Subversion this would be doable to get around, but Subversion's merge concept is very different. In Subversion I can set a point in time, r206 for example, where I start tracking merges from that point on. Is it possible to do this in Bazaar? Is there another approach other than manually reconstituting my full history against the git repository?

John A Meinel (jameinel) said : #6

You should be able to do something like "bzr merge -r0 ../other" to give a
merge, and then "bzr revert *" to revert out content changes. However, file
IDs will be different if coming from a git conversion rather than from bzr.
So you'll get far too many conflicts and history will be hard to track
anyway. I would recommend doing something more like rebasing the branches
you have against the new trunk. I'm not sure if the bzr-rewrite plugin has
bits to make this easier.

John
=:->
On Jun 7, 2012 4:50 AM, "Jared Silva" <email address hidden>
wrote:

> Question #199401 on Bazaar changed:
> https://answers.launchpad.net/bzr/+question/199401
>
> Status: Answered => Open
>
> Jared Silva is still having a problem:
> The code was originally in bzr, but it looks like the author moved to
> git.
>
> bzr log -c 208
> ------------------------------------------------------------
> revno: 208
> message:
> Moving to git
>
> Looks like the original lp:pithos pointed to a bzr repository, but has
> since been migrated to git, lp:pithos now points to a git repository,
> and the original bzr repository is not being updated against the new git
> repository.
>
> Where does this leave all of the bzr repositories that branched from the
> original bzr repository? Are they all orphaned? Is there a good way
> for these branches to move on? r206 in the bzr repository is the "same"
> as r206 in the git repository. I know in Subversion this would be
> doable to get around, but Subversion's merge concept is very different.
> In Subversion I can set a point in time, r206 for example, where I start
> tracking merges from that point on. Is it possible to do this in
> Bazaar? Is there another approach other than manually reconstituting my
> full history against the git repository?
>
> --
> You received this question notification because you are an answer
> contact for Bazaar.
>

Jared Silva (jayrod) said : #7

bzr-rewrite has the same problem. Tried various combinations, all with the same result. Does not seem like a merge/revert combination will get me there either.

bzr: ERROR: Branches have no common ancestor, and no merge base revision was specified.

Any other ideas?

Jared Silva (jayrod) said : #8

Can't figure out how to continue a bzr branch when the parent changes from bzr to git. Can figure out how to continue a bzr branch when the parent changes from bzr to git by converting the bzr branch to git.

Thanks for the help, but I see no clear way around the revision and file id problem induced by bzr. Git's value on content seems to win in this case.