On Tue, Nov 29, 2005 at 03:29:57PM +0900, Samuel Masham wrote:
> Hi Chris, All,
>
> Got round to doing some testing but now on version .39 nice work with
> the series handling it should make life easier for a lot of people.
>
> (tested with andrews quilt stack against 2.4.15-rc2 ish - no problems)
>
> on to the merge work:
Thanks for trying both out.
>
> Ok, multiple merge/ parents behavior is working nicely and gives nice
> results.
>
> However this is NOT different from my patch on its own in this
> respect. As the p0 (first parent) is always your ancestor on the
> stack the original codes multi-parent blindness didn't matter (just
> discarding the guard on qrefresh etc should let it work, qpush qpop
> worked fine as is ...)
>
>
> It follows that *if* i am correct in this then you don't need the
> ".hg.patches.merge.marker" maybe... (if pparents ever returns p2 then
> I am defiantly wrong, but my theory is that it can't).
There are some corner cases in there. The parents stored in the
changeset are sorted by sha. It's easy to get into a situation where p0
wasn't the parent you expected it to be. (hg update -C rev for example).
I changed the merger marker so that it isn't a real patch. It lives
only in the status file. This makes it much easier to get rid of. A
simple pop will do.
>
> Now the remaining versioning issue is with qpop -a / qpush -a losing
> the merge information. I wil send a separate mail on why this may
> matter sometimes.
>
> (nice to see qrefresh keeps this info now though)
qpop ; qpush will lose the merge info. qpop ; qpush -m will
regenerate it. Because the qpush -m first tries to just apply the patch
in .hg/patches, you won't have to go through the merge again, the result
will just be setting the parents.
-chris
|
