[PATCH] Merge fixes

[Martin Pool]

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

> > 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.
> 
> True, but filesystem-based merging can also be useful,
> e.g. merge-revert.

I suggest keeping WorkingTree merge in the underlying merge code so it
can be used for revert, but hiding it from the user-visible 'merge'
command, at least by default.

> > 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?
> 
> It just felt intuitively right to keep the support there, so users had
> the power if they needed it.  But I don't have any really convincing
> arguments.
> 
> > I think inverting the usual sense of them would be confusing.
> 
> Oh, I meant redefining the usual sense.  That would only be confusing as
> a one-time thing for the current user base, not as an ongoing problem.

It's nice to have ./foo refer to the file that actually exists as foo,
and have the special syntax refer to things that don't exist in the
filesystem.

-- 
Martin