merge should allow merging in a wholly new codebase

Sadly, I also cannot change the importance to 'wishlist' in launchpad, despite my knowing that it belongs there. :)

GiuseppeVerde пишет:
> Public bug reported:
>
> The usage scenario is: I have a body of code which is inherited and a
> program which fits into it. Both are totally separate codebases, with
> totally separate revision histories. I would now like to land the
> program into the larger suite of programs, complete with its revision
> history.
>
> Sadly, this does not appear possible.

$ bzr merge -r0..-1 another_branch

should work.

As Alexander mentioned, 'bzr merge -r 0..-1 ../other_branch' will merge the entire other tree into this one, and then afterwards you can 'bzr mkdir subproject' and 'bzr mv new_files subproject'.

There is also https://launchpad.net/bzr-merge-into which should do exactly what you are looking for.

The biggest reason it isn't part of 'bzr merge' is just because the syntax to do it doesn't really fit the other merge use cases.

Could you elaborate on "The biggest reason it isn't part of 'bzr merge' is just because the syntax to do it doesn't really fit the other merge use cases."?

Particularly in light of how it merge *does* merge in, but only when invoked a Magic Way, which indicates that this is not actually the case?

What use cases are you referring to, exactly?

You *can* merge in another code base, but it:

a) Requires special effort. Right now that is supplying -r0..X. We will probably always require some effort, because most of the time merging a different project is an accident, not something intentional. I don't think -r0 is the best way to indicate it, it is just effective for now.

b) Merges everything into the root of the current project. Which generally means you need to rename everything to somewhere else.

'bzr merge' currently takes a single path as an argument. This can be a URL or relative path to a branch, or it can be the path to a specific file. Which would allow merging just the changes in that file. (Also useful is the --uncommitted flag when you have been making changes in the wrong branch.)

We could have it take more than 1 path. Either by considering the extra paths as filenames to also merge, or as a target destination to merge the changes into. I would really like to avoid the problems we have with 'bzr diff' which has a whole lot of possible interpretations of the command line arguments (it usually works well, but there are always bits of ambiguity and it makes the code harder to work with).

I probably would prefer to add a command line option such as :

bzr merge --set-root=path ../other/branch

I'm not sure whether it should be "--set-root" or "--into" or "--base" or "--into-directory" or all sorts of possibilities. That could automatically set 0 as the base revision, and set everything up for merging in a child project.

However, there is a 'bzr join" command which is coming soon, which will have you put the branch in a subdirectory, and then just "bzr join subdir". Which might be simpler overall.