Intent of TestCommitMerge.test_merge_new_file?

[Martin Pool]

On 29 May 2006, Aaron Bentley <aaron.bentley at utoronto.ca> wrote:

> No, the idea I had is that you get the two source trees physically
> nested using branch or checkout, etc.
> 
> $ bzr checkout ~/repo/foo foo
> $ bzr checkout ~/repo/bar foo/bar
> $ bzr graft ~/foo/bar foo
> 
> I think this is a clearer way of doing it than a command that says
> "check out or branch this branch into this other branch, making its root
> such-and-such subdirectory":

Yes, I think you're right that it's cleaner.  But then why do you need
two arguments?  Isn't it enough just to give the name of the directory
which is going to be grafted?

> The root directory can only have one id.  So if root ids differ between
> branches, and you try to combine the root directory contents of those
> branches, you'll be effectively deleting one root, and moving its files
> into the other root.  This will come back to bite you when you do a
> merge that adds new files to the deleted root.

This may require some more consideration; merging two previously
unrelated trees is a reasonable thing to do.  Perhaps it can be handled
under the aegis of a regular merge that conflicts because the
destination directory is deleted?  Perhaps it requires remembering what
file ids or versions have already been merged in -- file-id joining, etc.

> ~  So typical use will be 'bzr graft ../somelibrary
> | ./library'.
> |
> | We should test that revert correctly undoes the graft as I imagine
> | people will fairly often change their mind or decide to graft it
> | somewhere else.
> 
> Interesting.  Given that step 4 of graft is "remove the control
> directory of bar", that may be a problem.

Well, I won't absolutely insist on revert working, but there does seem
some risk here that people will lose some of their history.

-- 
Martin