[PATCH] Merge fixes

Aaron Bentley aaron.bentley at utoronto.ca
Fri Jul 8 01:42:32 BST 2005


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Martin Pool wrote:
> 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.

True, but filesystem-based merging can also be useful, e.g. merge-revert.

> 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.

> 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.

I think merging using the last-committed revision is the common case.
It's the fastest case, too, since all the store ids are known.  So I'll
make ./@ and . both mean 'the last committed revision', and leave /@
undocumented.

>>>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.

I'm not sure whether remote working trees serve any purpose.  One
doesn't usually want someone else's uncommitted changes.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCzcv40F+nu1YWqI0RAspcAJ9dklJmXog+pshbkaUgiJTgS18L+wCeIuZu
70s/QmJfeE9PPo4UynMi2jk=
=oXcT
-----END PGP SIGNATURE-----




More information about the bazaar mailing list