Re: recur status on linux-2.6

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Aug 13, 2006, 18:16 UTC
Message-ID: <Pine.LNX.4.63.0608132006510.10541@wbgn013.biozentrum.uni-wuerzburg.de>
In-Reply-To: <7v64gwmv2j.fsf@assigned-by-dhcp.cox.net>

Hi,

On Sun, 13 Aug 2006, Junio C Hamano wrote:

> Recreating the tip of "next" (10a6653) might be fun.  I do not know why, 
> but it ended up having 14 merge bases.  The speed-up is about 6x, and 
> the resulting half-merge is worse than recursive (not using rerere 
> cache).

Well, my guess for these 14 merge bases is that you merge a lot between topic branches.

As for the worse half-merge: I get only this difference:

-100644 fad39ff609f3ea27981e7a9ffdfc29731d1065d0 1 upload-pack.c +100644 b6cc43c3c89c68e950c6d86298c928e9aab25e70 1 upload-pack.c

So, after both -recur and -recursive, upload-pack.c is in the index in an unmerged state.

The difference between fad39ff6 (from -recur) and b6cc43c3 (from -recursive) is that this block

-- snip --

        if (nr_has < MAX_HAS) {
                struct object *o = lookup_object(sha1);
                if (!(o && o->parsed))
                        o = parse_object(sha1);
                if (!o)
                        die("oops (%s)", sha1_to_hex(sha1));
                if (o->type == OBJ_COMMIT) {
                        struct commit_list *parents;
                        if (o->flags & THEY_HAVE)
                                return 0;
                        o->flags |= THEY_HAVE;
                        for (parents = ((struct commit*)o)->parents;
                             parents;
                             parents = parents->next)
                                parents->item->object.flags |= THEY_HAVE;
                }
                memcpy(has_sha1[nr_has++], sha1, 20);

-- snap --

is inserted after (-recur), instead of before (-recursive), the clashing block

-- snip --

        o = lookup_object(sha1);
        if (!(o && o->parsed))
                o = parse_object(sha1);
        if (!o)
                die("oops (%s)", sha1_to_hex(sha1));
        if (o->type == TYPE_COMMIT) {
                struct commit_list *parents;
                if (o->flags & THEY_HAVE)
                        return 0;
                o->flags |= THEY_HAVE;
                for (parents = ((struct commit*)o)->parents;
                     parents;
                     parents = parents->next)
                        parents->item->object.flags |= THEY_HAVE;

-- snap --

So, the order is actually saner, since one expects the upstream (newer) version to come after the "====" line.

I fail to see how this is worse than -recursive...

Ciao, Dscho