[devel] git -- хитрая задачка

[devel] git -- хитрая задачка

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 972 bytes --]

Имеется множество git-репозиториев (около тысячи).
Большая часть их них -- устаревшие backup'ы, но какие определить
по имени или еще каким-либо очевидным характеристикам невозможно.
Разобраться в этом кошмаре вручную -- тем более.

Задача -- выявить и удалить старье (которого там процентов 90).

Лобовое решение: прогнать для каждого бранча каждого репозитория git log,
положить результат в sqlite (commit id/путь к репо/бранч). Также положить
в базу последний commit id каждого бранча каждого репозитория.

После этого я могу легко определить есть ли такой commit id в другом
репозитории. И если есть, и это не последний коммит в бранче -- то наш
бранч явно стухший и его можно удалить.

Такое решение мне не нравится тем, что придется строить базу по миллионам
commit'ов.

Можно ли придумать что-то значительно шустрее?

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] git -- хитрая задачка

[Андрей Черепанов]

24 августа 2010 Денис Смирнов написал:
> Имеется множество git-репозиториев (около тысячи).
> Большая часть их них -- устаревшие backup'ы, но какие определить
> по имени или еще каким-либо очевидным характеристикам невозможно.
> Разобраться в этом кошмаре вручную -- тем более.
> 
> Задача -- выявить и удалить старье (которого там процентов 90).
> 
> Лобовое решение: прогнать для каждого бранча каждого репозитория git log,
> положить результат в sqlite (commit id/путь к репо/бранч). Также положить
> в базу последний commit id каждого бранча каждого репозитория.
> 
> После этого я могу легко определить есть ли такой commit id в другом
> репозитории. И если есть, и это не последний коммит в бранче -- то наш
> бранч явно стухший и его можно удалить.
> 
> Такое решение мне не нравится тем, что придется строить базу по миллионам
> commit'ов.
> 
> Можно ли придумать что-то значительно шустрее?
Как насчёт даты последней модификации?

-- 
Андрей Черепанов
ALT Linux
cas@altlinux.ru

Re: [devel] git -- хитрая задачка

[Alexander Myltsev]

2010/8/24 Денис Смирнов <mithraen@altlinux.ru>:
> Такое решение мне не нравится тем, что придется строить базу по миллионам
> commit'ов.

Миллион вроде не очень большое число (см. "мегагерц", "мегабайт"). Я
бы попробовал.

> Можно ли придумать что-то значительно шустрее?

Можно воспользоваться тем, что родственные репозитории всегда имеют
общие корни (коммиты без родителей). То есть сначала находим во всех
репозиториях все корни, а потом решаем задачу только в "родственных
группах". (Правда, будет ли это сильно шустрее -- неизвестно.)

-- 
AVM

Re: [devel] git -- хитрая задачка

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 298 bytes --]

On Tue, Aug 24, 2010 at 01:17:38PM +0400, Андрей Черепанов wrote:

АЧ> Как насчёт даты последней модификации?

Она не позволит выявить связаны репозитории или нет. 

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] git -- хитрая задачка

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 891 bytes --]

On Tue, Aug 24, 2010 at 01:39:31PM +0400, Alexander Myltsev wrote:

AM> Миллион вроде не очень большое число (см. "мегагерц", "мегабайт"). Я
AM> бы попробовал.

Просто все алгоритмы которые мне приходили в голову отнюдь не линейные по
количеству необходимых операций от количества репозиториев.

AM> Можно воспользоваться тем, что родственные репозитории всегда имеют
AM> общие корни (коммиты без родителей). То есть сначала находим во всех
AM> репозиториях все корни, а потом решаем задачу только в "родственных
AM> группах". (Правда, будет ли это сильно шустрее -- неизвестно.)

Это гениально! Спасибо! В родственных группах можно уже не строить базу.

А есть ли какой то способ зная id коммита определить есть ли он в истории
некоего коммита?

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] git -- хитрая задачка

[Alexander Myltsev]

2010/8/24 Денис Смирнов <mithraen@altlinux.ru>:
> В родственных группах можно уже не строить базу.
>
> А есть ли какой то способ зная id коммита определить есть ли он в истории
> некоего коммита?

Нет, базу строить всё-таки придётся :-).

-- 
AVM

Re: [devel] git -- хитрая задачка

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 463 bytes --]

On Tue, Aug 24, 2010 at 01:42:47PM +0400, Денис Смирнов wrote:
> А есть ли какой то способ зная id коммита определить есть ли он в истории
> некоего коммита?
git merge-base первый второй
Вернёт "первый", если он является предком второго. МОжет есть проще, не
знаю.

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(6):

В локалке шифрование тоже не помешает.
Популяция ангелов в локалке очень малочисленна.
		-- mrkooll in community@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [devel] git -- хитрая задачка

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1096 bytes --]

On Tue, Aug 24, 2010 at 12:31:38PM +0400, Денис Смирнов wrote:
> Имеется множество git-репозиториев (около тысячи).
> Большая часть их них -- устаревшие backup'ы, но какие определить
> по имени или еще каким-либо очевидным характеристикам невозможно.
> Разобраться в этом кошмаре вручную -- тем более.
> 
> Задача -- выявить и удалить старье (которого там процентов 90).
> 
> Лобовое решение: прогнать для каждого бранча каждого репозитория git log,
> положить результат в sqlite (commit id/путь к репо/бранч). Также положить
> в базу последний commit id каждого бранча каждого репозитория.
> 
> После этого я могу легко определить есть ли такой commit id в другом
> репозитории. И если есть, и это не последний коммит в бранче -- то наш
> бранч явно стухший и его можно удалить.

Самый лобовой способ: зафетчить в каждый репозиторий соответствующий ему
"другой", апстримный репозиторий, после чего пройтись git for-each-ref'ом
по refs/heads и выяснить (git log -n1 --pretty=format:1 ^l_ref r_ref),
есть ли в репозитории хотя бы один актуальный локальный бранч.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] git -- хитрая задачка

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 467 bytes --]

On Tue, Aug 24, 2010 at 03:49:07PM +0600, Andrey Rahmatullin wrote:
> On Tue, Aug 24, 2010 at 01:42:47PM +0400, Денис Смирнов wrote:
> > А есть ли какой то способ зная id коммита определить есть ли он в истории
> > некоего коммита?
> git merge-base первый второй
> Вернёт "первый", если он является предком второго. МОжет есть проще, не
> знаю.

http://git.altlinux.org/people/ldv/packages/?p=girar-builder.git;a=blob;f=gb-task-check-girar#l13


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] git -- хитрая задачка

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 754 bytes --]

On Tue, Aug 24, 2010 at 01:53:49PM +0400, Dmitry V. Levin wrote:

DVL> Самый лобовой способ: зафетчить в каждый репозиторий соответствующий ему
DVL> "другой", апстримный репозиторий, после чего пройтись git for-each-ref'ом
DVL> по refs/heads и выяснить (git log -n1 --pretty=format:1 ^l_ref r_ref),
DVL> есть ли в репозитории хотя бы один актуальный локальный бранч.

Хотелось бы во время всех этих проверок не модифицировать сами
репозитории. Хотя можно, конечно, копии делать...

А есть способ просто ответить на вопрос "есть ли в этом репозитории коммит
с таким-то id, и если есть, то в истории каких бранчей"?

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] git -- хитрая задачка

[Alexander Myltsev]

2010/8/24 Денис Смирнов <mithraen@altlinux.ru>:
> А есть способ просто ответить на вопрос "есть ли в этом репозитории коммит
> с таким-то id,

Конечно, коммит -- это просто такой объект. git show его.

> и если есть, то в истории каких бранчей"?

А вот чтобы найти его в истории бранча, надо спускаться к нему от верхушки.

-- 
AVM

Re: [devel] git -- хитрая задачка

[Andrey Rahmatullin]

[-- Attachment #1: Type: text/plain, Size: 432 bytes --]

On Tue, Aug 24, 2010 at 03:35:10PM +0400, Денис Смирнов wrote:
> А есть способ просто ответить на вопрос "есть ли в этом репозитории коммит
> с таким-то id, и если есть, то в истории каких бранчей"?
git branch --contains

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(6):

Боюсь, статическая сборка объявлена ересью, и каждый, кто
пытается делать ее, будет подвержен анафеме.
		-- morozov in sisyphus@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [devel] git -- хитрая задачка

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 238 bytes --]

On Tue, Aug 24, 2010 at 05:43:04PM +0600, Andrey Rahmatullin wrote:

AR> git branch --contains

Спасибо!

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] git -- хитрая задачка

[Ildar Mulyukov]

On 24.08.2010 17:35:10, Денис Смирнов wrote:
> On Tue, Aug 24, 2010 at 01:53:49PM +0400, Dmitry V. Levin wrote:
> 
> DVL> Самый лобовой способ: зафетчить в каждый репозиторий  
> соответствующий ему
> DVL> "другой", апстримный репозиторий, после чего пройтись git  
> for-each-ref'ом
> DVL> по refs/heads и выяснить (git log -n1 --pretty=format:1 ^l_ref  
> r_ref),
> DVL> есть ли в репозитории хотя бы один актуальный локальный бранч.
> 
> Хотелось бы во время всех этих проверок не модифицировать сами
> репозитории. Хотя можно, конечно, копии делать...

есть замечательная вещь - git new-workdir. Как раз оно. Лежит в  
git-contrib.
-- 
Ildar

Re: [devel] git -- хитрая задачка

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 506 bytes --]

On Tue, Aug 24, 2010 at 05:52:26PM +0600, Ildar Mulyukov wrote:

IM> есть замечательная вещь - git new-workdir. Как раз оно. Лежит в  
IM> git-contrib.

При любой модификации копии репозитория будет модифицирован оригинал. Ибо
new-workdir просто делает симлинки на все подряд, кроме HEAD и index.

В принципе можно использовать git clone -s --bare -- это будет быстро.

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] git -- хитрая задачка

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 429 bytes --]

On Tue, Aug 24, 2010 at 03:41:13PM +0400, Alexander Myltsev wrote:

AM> Конечно, коммит -- это просто такой объект. git show его.

Спасибо.

AM> А вот чтобы найти его в истории бранча, надо спускаться к нему от верхушки.

т.е:

git log --oneline --abbrev=40 <branch> | grep ^commit-id

?

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] git -- хитрая задачка

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 759 bytes --]

On Tue, Aug 24, 2010 at 03:49:07PM +0600, Andrey Rahmatullin wrote:

AR> git merge-base первый второй
AR> Вернёт "первый", если он является предком второго. МОжет есть проще, не
AR> знаю.

70ms для репо с >8k коммитов лежащем в дисковом кэше.

Да еще и код ошибки возвращает (0 -- если нашел, 1 -- если объект есть но
в другом бранче, 128+матюк об ошибке -- если такого объекта нет в репо).

Проще уже разве что со встроенным телепатическим модулем. Спасибо!

Для того чтобы найти "корень" (первый коммит) бранча что-нибудь проще чем:

git log --oneline --first-parent --abbrev=40 <branch> | tail -1

существует?

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] git -- хитрая задачка

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 489 bytes --]

On Tue, Aug 24, 2010 at 01:58:26PM +0400, Dmitry V. Levin wrote:

>> git merge-base первый второй
>> Вернёт "первый", если он является предком второго. МОжет есть проще, не
>> знаю.
DVL> http://git.altlinux.org/people/ldv/packages/?p=girar-builder.git;a=blob;f=gb-task-check-girar#l13

А чем это лучше git merge-base (при том что он код возврата дает)?

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] git -- хитрая задачка

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 484 bytes --]

On Tue, Aug 24, 2010 at 09:58:25PM +0400, Денис Смирнов wrote:
> Для того чтобы найти "корень" (первый коммит) бранча что-нибудь проще чем:
> 
> git log --oneline --first-parent --abbrev=40 <branch> | tail -1
> 
> существует?

В общем случае таких корней может быть несколько (git позволяет
объединять независимо начатые ветки).  Найти их можно, например, так:

  git log --pretty=tformat:'%H:%P' | sed -ne 's/:$//p'

Например, в репозитории самого git таких коммитов 6.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] git -- хитрая задачка

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 768 bytes --]

On Tue, Aug 24, 2010 at 10:00:17PM +0400, Денис Смирнов wrote:
> On Tue, Aug 24, 2010 at 01:58:26PM +0400, Dmitry V. Levin wrote:
> 
> >> git merge-base первый второй
> >> Вернёт "первый", если он является предком второго. МОжет есть проще, не
> >> знаю.
> DVL> http://git.altlinux.org/people/ldv/packages/?p=girar-builder.git;a=blob;f=gb-task-check-girar#l13
> 
> А чем это лучше git merge-base (при том что он код возврата дает)?

http://git.altlinux.org/people/ldv/packages/?p=gear.git;a=commitdiff;h=705d10e6596636220f65aa9c05f41a1ca69503de

Ну и, насколько я помню, в merge-all-branches из kernel-build-tools
аналогичный способ (точнее, через git rev-list --max-count=1) в
каких-то ситуациях работал существенно быстрее, чем через git
merge-base.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] git -- хитрая задачка

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1844 bytes --]

On Wed, Aug 25, 2010 at 12:18:02AM +0400, Sergey Vlasov wrote:
> On Tue, Aug 24, 2010 at 10:00:17PM +0400, Денис Смирнов wrote:
> > On Tue, Aug 24, 2010 at 01:58:26PM +0400, Dmitry V. Levin wrote:
> > 
> > >> git merge-base первый второй
> > >> Вернёт "первый", если он является предком второго. МОжет есть проще, не
> > >> знаю.
> > DVL> http://git.altlinux.org/people/ldv/packages/?p=girar-builder.git;a=blob;f=gb-task-check-girar#l13
> > 
> > А чем это лучше git merge-base (при том что он код возврата дает)?
> 
> http://git.altlinux.org/people/ldv/packages/?p=gear.git;a=commitdiff;h=705d10e6596636220f65aa9c05f41a1ca69503de

Там, кстати, в commit message вкралась опечатка, меняющая смысл.

> Ну и, насколько я помню, в merge-all-branches из kernel-build-tools
> аналогичный способ (точнее, через git rev-list --max-count=1) в
> каких-то ситуациях работал существенно быстрее, чем через git
> merge-base.

Да, я это тоже заметил.
Например, у меня в coreutils.git это выглядит так:

$ time git rev-list --max-count=1 ^master coreutils-current
0.00user 0.00system 0:00.00elapsed 160%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+494minor)pagefaults 0swaps

$ time git log -n1 --pretty=format:1 ^master coreutils-current > /dev/null 
0.00user 0.00system 0:00.00elapsed 160%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+500minor)pagefaults 0swaps

$ time git merge-base coreutils-current master
1d10eb8b1eeff9dd0fe1bbbc212e9535203acff0
0.71user 0.01system 0:00.72elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+9166minor)pagefaults 0swaps

Судя по статистике minor pagefaults, git rev-list --max-count=1 немного
дешевле чем git log -n1 --pretty=format:1, и любой из них существенно
дешевле и гораздо быстрее чем git merge-base.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] git -- хитрая задачка

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 640 bytes --]

On Tue, Aug 24, 2010 at 10:54:48PM +0400, Sergey Vlasov wrote:

SV> В общем случае таких корней может быть несколько (git позволяет
SV> объединять независимо начатые ветки).  Найти их можно, например, так:
SV> 
SV>   git log --pretty=tformat:'%H:%P' | sed -ne 's/:$//p'
SV> 
SV> Например, в репозитории самого git таких коммитов 6.

Спасибо!
А для того чтобы запросить корни от нескольких веток -- это решение
правильно отработает опцию --all для git log, или надо опрашивать каждую
ветку отдельно?

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] git -- хитрая задачка

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 865 bytes --]

On Thu, Aug 26, 2010 at 12:35:49AM +0400, Денис Смирнов wrote:
> On Tue, Aug 24, 2010 at 10:54:48PM +0400, Sergey Vlasov wrote:
> 
> SV> В общем случае таких корней может быть несколько (git позволяет
> SV> объединять независимо начатые ветки).  Найти их можно, например, так:
> SV> 
> SV>   git log --pretty=tformat:'%H:%P' | sed -ne 's/:$//p'
> SV> 
> SV> Например, в репозитории самого git таких коммитов 6.
> 
> Спасибо!
> А для того чтобы запросить корни от нескольких веток -- это решение
> правильно отработает опцию --all для git log, или надо опрашивать каждую
> ветку отдельно?

Должно работать и с --all (правда, в результате окажутся смешанными и
действительно независимые ветки, которые могли быть в репозитории).

Есть ещё один вариант реализации (хотя скорость примерно одинаковая):

  git rev-list --parents --all | grep -v ' '

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]