[PATCH] Merge fixes

Martin Pool mbp at sourcefrog.net
Fri Jul 8 01:58:18 BST 2005

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


More information about the bazaar mailing list