[RFC][BUG?] pull does not de-dup pending merges

Robert Collins robertc at robertcollins.net
Tue Aug 8 00:54:01 BST 2006


If I have a working tree at revision C, with a pending merge of B and do
a pull from a branch which brings in revision A, which has C in its
ancestry, and B in its ancestry, we currently leave B as a pending merge
- but this is in fact incorrect - we've pulled in the merge of B
already.

I think the right thing to do on pull is to remove all parents of the
tree which are now in the ancestry of the new left most parent.

Thinking about this has made me realise there is another thing we could
do that might be too clever, but which I think would be very nice.

Say I have a branch with tip B, and I do a merge of a branch with tip A
but dont commit. At this point my working tree has two parents - [B, A].
Now, imagine there is another change made to the branch I was merging,
giving A'. I want that included in my merge.

I can currently do:
 - revert and merge again. - means I have to do conflict resolution
again
 - merge -r A..A' --force

But what about allowing:
 - pull A - which would update the parents list of my tree to be
            [B, A']. If the commit on A had been a merge of B, then it
could even [correctly] give me [A'].

This is possibly overly clever, but I thought it worth expressing.

-Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060808/49d651c1/attachment.pgp 


More information about the bazaar mailing list