Re: [PATCH v2 0/4] Multiple subtree split fixes regarding complex repos

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 12, 2018, 07:35 UTC
Message-ID: <xmqqk1mnbosr.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <20181011194605.19518-1-rstrain@swri.org>

Roger Strain <rstrain@swri.org> writes:

> After doing some testing at scale, determined that one call was
> taking too long; replaced that with an alternate call which
> returns the same data significantly faster.

Curious where the time goes.  Do you know?

> Also, if anyone has any other feedback on these I'd really love to
> hear it. It's working better for us (as in, it actually generates

The previous one is already in 'next'; please make it incremental with explanation as to why "show -s" is worse than "log -1" (but see below).

>                 # processing commit without normal parent information;
>                 # fetch from repo
> -               parents=$(git show -s --pretty=%P "$rev")
> +               parents=$(git log --pretty=%P -n 1 "$rev")

If you want to learn the parents of a given commit:

	$ git help revisions

says

       <rev>^@, e.g. HEAD^@
           A suffix ^ followed by an at sign is the same as listing all parents of <rev>
           (meaning, include anything reachable from its parents, but not the commit
           itself).

so

		parents=$(git rev-parse "$rev^@")

ought to be the most efficient way to do this, I suspect.