[PATCH] Merge fixes

[Martin Pool]

On  7 Jul 2005, Aaron Bentley <aaron.bentley at utoronto.ca> wrote:

> Okay, I can hack that up.  What if we swapped the meaning of
> "http://panoramicfeedback.com/opensource/bzr.merge" and
> "http://panoramicfeedback.com/opensource/bzr.merge/@"?
> 
> So http://panoramicfeedback.com/opensource/bzr.merge would mean "latest
> revision" and "http://panoramicfeedback.com/opensource/bzr.merge/@"
> would mean "working dir".
> 
> Or would you rather not cover working-dir merging?

I'm not sure if people would normally want to merge in uncommitted
changes.  There isn't any revision-id to keep track of exactly what was
merged.  Perhaps one case is when you've made a temporary branch and
want to pull it in, but why not just commit there?  What do you think?

I think inverting the usual sense of them would be confusing.  We could
do it with ./@working or perhaps with a 'merge --uncommitted' option.
Or perhaps merging the working copy should be the default and we should
just fix the bug in doing it from a remote copy.

> > The Tree object
> > should cope if it can't get a stat cache and it should probably be
> > possible to use remote working trees
> 
> This is a separate issue, right?

Yes.

-- 
Martin