Thread (1 message) 1 message, 1 author, 2018-10-12

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

From: Junio C Hamano <hidden>
Date: 2018-10-12 07:35:23

Roger Strain [off-list ref] 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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help