Чи можу я використовувати Git для пошуку відповідних імен файлів у сховищі?

Просто скажіть, що у мене є файл: "HelloWorld.pm" у декількох підкаталогах у сховищі Git.

Я хотів би виконати команду, щоб знайти повні шляхи всіх файлів, що відповідають "HelloWorld.pm":

Наприклад:

/path/to/repository/HelloWorld.pm
/path/to/repository/but/much/deeper/down/HelloWorld.pm
/path/to/repository/please/dont/make/me/search/through/the/lot/HelloWorld.pm

Як я можу використовувати Git для ефективного пошуку всіх повних шляхів, що відповідають заданому імені файлу?

Я усвідомлюю, що можу це зробити за допомогою команди Linux / Unix find, але я сподівався уникнути сканування всіх підкаталогів, що шукають екземпляри імені файлу.

git ls-filesнадасть вам список усіх файлів у поточному стані сховища (кеш чи індекс). Ви можете передати шаблон, щоб отримати файли, що відповідають цьому шаблону.

git ls-files HelloWorld.pm '**/HelloWorld.pm'

Якщо ви хочете знайти набір файлів і переглянути їх вміст, ви можете зробити це за допомогою git grep:

git grep some-string -- HelloWorld.pm '**/HelloWorld.pm'

Хм, спочатку питання стосувалось сховища. Репозиторій містить більше 1 коміту (принаймні в загальному випадку), але відповіді, дані перед пошуком, здійснюються лише за допомогою одного коміту.

Оскільки я не зміг знайти відповідь, яка реально шукає всю історію комітів, я написав швидкий скрипт грубої сили git-find-by-name, який враховує (майже) усі коміти.

#! /bin/sh
tmpdir=$(mktemp -td git-find.XXXX)
trap "rm -r $tmpdir" EXIT INT TERM

allrevs=$(git rev-list --all)
# well, nearly all revs, we could still check the log if we have
# dangling commits and we could include the index to be perfect...

for rev in $allrevs
do
  git ls-tree --full-tree -r $rev >$tmpdir/$rev 
done

cd $tmpdir
grep $1 * 

Можливо, існує більш елегантний спосіб.

Зверніть увагу на тривіальний спосіб передавання параметра у grep, тому він буде відповідати частинам імені файлу. Якщо цього не бажано, закріпіть вираз пошуку та / або додайте відповідні параметри grep.

Для глибоких історій результат може бути занадто галасливим, я подумав про сценарій, який перетворює список версій у діапазон, як протилежне тому, що може зробити git rev-list. Але поки що це залишається думкою.

Спробуйте:

git ls-tree -r HEAD | grep HelloWorld.pm

git ls-files | grep -i HelloWorld.pm

Grep -i робить регістр grep нечутливим.

[Я визнаю, це трохи зловживання коментарями, але я поки що не можу коментувати і думав, що покращу відповідь @ uwe-geuder.]

#!/bin/bash
#
#

# I'm using a fixed string here, not a regular expression, but you can easily
# use a regular expression by altering the call to grep below.
name="$1"

# Verify usage.
if [[ -z "$name" ]]
then
    echo "Usage: $(basename "$0") <file name>" 1>&2
    exit 100
fi  

# Search all revisions; get unique results.
while IFS= read rev
do
    # Find $name in $rev's tree and only use its path.
    grep -F -- "$name" \
        <(git ls-tree --full-tree -r "$rev" | awk '{ print $4 }')
done < \
    <(git rev-list --all) \
    | sort -u

Знову ж, +1 до @ uwe-geuder для чудової відповіді.

Якщо вас цікавить сам BASH:

Якщо ви не гарантуєте розбиття слів у циклі for (як при використанні масиву, подібного до цього for item in "${array[@]}":), я настійно рекомендую використовувати, while IFS= read var ; do ... ; done < <(command)коли вихідні дані команди, які ви переглядаєте, відокремлені новими рядками (або read -d''коли вихідні дані розділені нульовий рядок $'\0'). Хоча git rev-list --allгарантовано використовувати 40-байтові шістнадцяткові рядки (без пробілів), я ніколи не люблю ризикувати. Тепер я можу легко змінити команду git rev-list --allна будь-яку команду, яка створює рядки

Я також рекомендую використовувати вбудовані механізми BASH для введення вхідних даних та фільтрування виводу замість тимчасових файлів.

Сценарій Уве Геудера (@ uwe-geuder) чудовий, але насправді немає необхідності скидати кожен з виходів ls-дерева у свій власний каталог, нефільтрований.

Набагато швидше і використовуючи менше місця для зберігання: запустіть grep на виході, а потім збережіть його, як показано в цій суті