Re: The most efficient way to test if repositories share the same objects

[Ævar Arnfjörð Bjarmason]

On Fri, Mar 23 2018, Konstantin Ryabitsev wrote:

> On 03/22/18 17:44, Junio C Hamano wrote:
>> Wouldn't it be more efficient to avoid doing so one-by-one?
>> That is, wouldn't
>>
>>  rev-list --max-parents=0 --all
>>
>> be a bit faster than
>>
>>  for-each-ref |
>>  while read object type refname
>>  do
>>  rev-list --max-parents=0 $refname
>>  done
>>
>> I wonder?
>
> Yeah, you're right -- I forgot that we can pass --all. The check takes
> 30 seconds, which is a lot better than 12 hours. :) It's a bit heavy
> still, but msm kernel repos are one of the heaviest outliers, so let me
> try to run with this.
>
> Thanks for the suggestion!

Unless you have just one CPU core your script would probably benefit
from being wrapped in GNU parallel. I.e.:

parallel 'stuff-to-do {}' ::: $(list-of-repos)

Or something similar.

Re: The most efficient way to test if repositories share the same objects

[Konstantin Ryabitsev]

On 03/22/18 17:44, Junio C Hamano wrote:
> Wouldn't it be more efficient to avoid doing so one-by-one?  
> That is, wouldn't
> 
>   rev-list --max-parents=0 --all
> 
> be a bit faster than
> 
>   for-each-ref |
>   while read object type refname
>   do
>   rev-list --max-parents=0 $refname
>   done
> 
> I wonder?

Yeah, you're right -- I forgot that we can pass --all. The check takes
30 seconds, which is a lot better than 12 hours. :) It's a bit heavy
still, but msm kernel repos are one of the heaviest outliers, so let me
try to run with this.

Thanks for the suggestion!

Best,
-- 
Konstantin Ryabitsev
Director, IT Infrastructure Security
The Linux Foundation



signature.asc
Description: OpenPGP digital signature

Re: The most efficient way to test if repositories share the same objects

[Junio C Hamano]

Konstantin Ryabitsev  writes:

> $ time git rev-list --max-parents=0 HEAD
> a101ad945113be3d7f283a181810d76897f0a0d6
> cd26f1bd6bf3c73cc5afe848677b430ab342a909
> be0e5c097fc206b863ce9fe6b3cfd6974b0110f4
> 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
>
> real0m6.311s
> user0m6.153s
> sys 0m0.110s
>
> If I try to do this for each of the 7700 heads, this will take roughly
> 12 hours.

Wouldn't it be more efficient to avoid doing so one-by-one?  
That is, wouldn't

rev-list --max-parents=0 --all

be a bit faster than

for-each-ref |
while read object type refname
do
rev-list --max-parents=0 $refname
done

I wonder?

Re: The most efficient way to test if repositories share the same objects

[Konstantin Ryabitsev]

On 03/22/18 15:35, Junio C Hamano wrote:
> I am not sure how Konstantin defines "the most efficient", but if it
> is "with the smallest number of bits exchanged between the
> repositories", then the answer would probably be to find the root
> commit(s) in each repository and if they share any common root(s).
> If there isn't then there is no hope to share objects between them,
> of course.

Hmm... so, this a cool idea that I'd like to use, but there are two
annoying gotchas:

1. I cannot assume that refs/heads/master is meaningful -- my problem is
actually with something like
https://source.codeaurora.org/quic/la/kernel/msm-3.18 -- you will find
that master is actually unborn and there are 7700 other heads (don't get
me started on that unless you're buying me a lot of drinks).

2. Even if there is a HEAD I know I can use, it's pretty slow on large
repos (e.g. linux.git):

$ time git rev-list --max-parents=0 HEAD
a101ad945113be3d7f283a181810d76897f0a0d6
cd26f1bd6bf3c73cc5afe848677b430ab342a909
be0e5c097fc206b863ce9fe6b3cfd6974b0110f4
1da177e4c3f41524e886b7f1b8a0c1fc7321cac2

real0m6.311s
user0m6.153s
sys 0m0.110s

If I try to do this for each of the 7700 heads, this will take roughly
12 hours.

My current strategy has been pretty much:

git -C msm-3.10.git show-ref --tags -s | sort -u > /tmp/refs1
git -C msm-3.18.git show-ref --tags -s | sort -u > /tmp/refs2

and then checking if an intersection of these matches at least half of
refs in either repo:


#/usr/bin/env python
import numpy

refs1 = numpy.array(open('/tmp/refs1').readlines())
refs2 = numpy.array(open('/tmp/refs2').readlines())

in_common = len(numpy.intersect1d(refs1, refs2))
if in_common > len(refs1)/2 or in_common > len(refs2)/2:
print('Lots of shared refs')
else:
print('None or too few shared refs')


This works well enough at least for those repos with lots of shared
tags, but will miss potentially large repos where there's only heads
that can be pointing at commits that aren't necessarily the same between
two repos.

Thanks for your help!

Best,
-- 
Konstantin Ryabitsev
Director, IT Infrastructure Security
The Linux Foundation



signature.asc
Description: OpenPGP digital signature

Re: The most efficient way to test if repositories share the same objects

[Ævar Arnfjörð Bjarmason]

On Thu, Mar 22 2018, Junio C. Hamano wrote:

> Ævar Arnfjörð Bjarmason  writes:
>
>> But of course that'll just give you the tips. You could then use `git
>> cat-file --batch-check` on both ends to see what commits from the other
>> they report knowing about, in case they have branches that are
>> ahead/behind the other.
>
> I am not sure how you are envisioning to use "cat-file
> --batch-check" here.  Do you mean to take "rev-list --all" output
> from both and compare, or something?

By doing something like this:

(
cd /tmp &&
git clone http://github.com/gitster/git gitster-git;
git clone http://github.com/avar/git avar-git;
git -C gitster-git for-each-ref --format="%(object)" | git -C avar-git 
cat-file --batch-check|grep -E -o '(commit|missing)'|sort|uniq -c &&
git -C avar-git for-each-ref --format="%(object)" | git -C gitster-git 
cat-file --batch-check|grep -E -o '(commit|missing)'|sort|uniq -c
)

Which outputs:

673 commit
696 missing
374 commit
495 missing

Which of course, as noted, isn't going to be a good general solution in
all cases, but it's blindingly fast, and since the original question is
essentially that he's starting out with doing a rough equivalent of
that, but for tags only, maybe it'll work for his use-case.

> I am not sure how Konstantin defines "the most efficient", but if it
> is "with the smallest number of bits exchanged between the
> repositories", then the answer would probably be to find the root
> commit(s) in each repository and if they share any common root(s).
> If there isn't then there is no hope to share objects between them,
> of course.

Yes, that would probably be much better:

diff -ru <(git -C avar-git log --oneline --pretty=format:%H 
--max-parents=0) \
 <(git -C gitster-git log --oneline --pretty=format:%H 
--max-parents=0) &&
do_stuff_because_they_have_stuff_in_common

Re: The most efficient way to test if repositories share the same objects

[Junio C Hamano]

Ævar Arnfjörð Bjarmason  writes:

> But of course that'll just give you the tips. You could then use `git
> cat-file --batch-check` on both ends to see what commits from the other
> they report knowing about, in case they have branches that are
> ahead/behind the other.

I am not sure how you are envisioning to use "cat-file
--batch-check" here.  Do you mean to take "rev-list --all" output
from both and compare, or something?

I am not sure how Konstantin defines "the most efficient", but if it
is "with the smallest number of bits exchanged between the
repositories", then the answer would probably be to find the root
commit(s) in each repository and if they share any common root(s).
If there isn't then there is no hope to share objects between them,
of course.

Re: The most efficient way to test if repositories share the same objects

[Ævar Arnfjörð Bjarmason]

On Thu, Mar 22 2018, Konstantin Ryabitsev wrote:

> What is the most efficient way to test if repoA and repoB share common
> commits? My goal is to automatically figure out if repoB can benefit
> from setting alternates to repoA and repacking. I currently do it by
> comparing the output of "show-ref --tags -s", but that does not work for
> repos without tags.

If you're using show-ref already to get the tag tips, you can use
for-each-ref to get all tips.

But of course that'll just give you the tips. You could then use `git
cat-file --batch-check` on both ends to see what commits from the other
they report knowing about, in case they have branches that are
ahead/behind the other.