Message ID | 20181011194605.19518-1-rstrain@swri.org (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
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.
diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh index 1c157dbd9..7dd643998 100755 --- a/contrib/subtree/git-subtree.sh +++ b/contrib/subtree/git-subtree.sh @@ -633,7 +633,7 @@ process_split_commit () { else # processing commit without normal parent information; # fetch from repo - parents=$(git show -s --pretty=%P "$rev") + parents=$(git log --pretty=%P -n 1 "$rev") extracount=$(($extracount + 1)) fi