Re: [PATCH] fast-import: Do less work when given "from" matches current branch head
- From
Mike Hommey <mh@glandium.org>
- Date
- Jul 9, 2015, 22:30 UTC
- Message-ID
- <20150709223018.GA3403@glandium.org>
- In-Reply-To
- <xmqqk2u9uky9.fsf@gitster.dls.corp.google.com>
On Thu, Jul 09, 2015 at 01:37:02PM -0700, Junio C Hamano wrote:
Show 38 quoted lines
> Mike Hommey <mh@glandium.org> writes:
>
> Cc'ed a few people who appear at the top of "shortlog --no-merges";
> I think the end result is not incorrect, but I want to hear second
> opinions on this one. I do not know Shawn still remembers this
> code, but what is under discussion seems to have come mostly from
> ea5e370a (fast-import: Support reusing 'from' and brown paper bag
> fix reset., 2007-02-12).
>
> > if (!skip_prefix(command_buf.buf, "from ", &from))
> > return 0;
> >
> > - if (b->branch_tree.tree) {
> > - release_tree_content_recursive(b->branch_tree.tree);
> > - b->branch_tree.tree = NULL;
> > - }
> > + hashcpy(sha1, b->branch_tree.versions[1].sha1);
> >
> > s = lookup_branch(from);
> > if (b == s)
>
> The part that deals with a branch that is different from the current
> one is not visible in the context (i.e. when s = lookup_branch(from)
> returned a non-NULL result that is different from b) but it used to,
> and continues to with this patch, copy sha1 from branch_tree.sha1
> and branch_tree.versions[] from sha1 and branch_tree.versions[1] of
> the specified branch.
>
> That codepath used to release the contents of branch_tree.tree when
> it did so, but it no longer does so after this patch because of the
> removal we see above.
>
> Does that mean the original code was doing a release that was
> unnecessary? Or does it mean this patch changes what happens on
> that codepath, namely (1) leaking resource, and/or (2) keeping a
> tree of the original 'b' that does not have anything to do with the
> tree of 's', preventing the later lazy-load code from reading the
> tree of 's' and instead of building on top of a wrong tree content?I guess the question is whether branch_tree.tree can be in a state that doesn't match that of branch_tree.versions[1].sha1. If not, then if s and b have the same branch_tree.versions[1].sha1 for some reason, then keeping the old branch_tree.tree makes no practical difference from resetting it. Except it skips the busy-work.
Mike