Как получить список добавленных и обновленных номеров строк из диапазона коммитов git?

Намерение: из-за большого количества устаревшего кода я хотел бы анализировать только строки, добавленные или измененные в моих запросах на включение, чтобы постепенно улучшать среду.

Входные данные: название базовой ветки (master), имя моей ветки PR (например, honzajavorek/my-cool-feature), хэш последней фиксации в функциональной ветке (например, 53253a3e8d9b1e3ed7d45b91e045c59d50aefdf0).

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

Я не ищу один лайнер, я могу написать короткий скрипт bash/Python/node.js для этого, но только с разумной сложностью (несколько строк).


Обновление: только что найдено Git diff с номерами строк (журнал Git с номерами строк). Кажется, это непростая задача :(


person Honza Javorek    schedule 06.09.2016    source источник


Ответы (2)


Я смог придумать наивный код на bash, который выдавал бы то, что вы хотите.

Наивность здесь заключается в том, что для этого требуется чистая (линейная) история между master и feature веткой, что не всегда так. На самом деле, вы должны использовать хэш коммита, который был мастером после того, как эта ветка была отклонена, вместо мастера в этом примере, или перебазировать ветку, прежде чем пытаться это сделать.

Кроме того, он был протестирован только с чистым рабочим каталогом, ветвь функции проверена.

for COMMIT in $(git log --pretty=format:%h master...feature); do
  for FILE in $(git ls-tree -r feature --name-only); do
    for NUMBER in $(git blame --line-porcelain "$FILE" | egrep ^$COMMIT | cut -d' ' -f3); do
      echo "$FILE":$NUMBER
    done
  done
done

Первый цикл проходит все коммиты между мастером и ветвью функций.

Второй цикл обходит все отслеживаемые файлы в функциональной ветке.

И третий (самый внутренний) цикл находит все строки, которые обвиняются хэшем коммита, предоставленным в этом контексте.

В итоге вы должны получить следующий вывод:

points.yml:32
points.yml:33
points.yml:34
points.yml:37
site.py:12

Формат очевиден.

person hroncok    schedule 14.09.2016
comment
Я думаю, что это слишком много циклов - самый внешний цикл можно разделить на части и сгенерировать одно регулярное выражение для egrep - person MacHala; 14.09.2016
comment
Вы должны иметь возможность комбинировать git diff --name-only master..feature, а затем git blame -b master..feature аналогичным образом для более надежного решения. - person Petr Viktorin; 15.09.2016

Попробуйте https://unix.stackexchange.com/questions/34874/diff-output-line-numbers для одного из возможных способов получения подходящего вывода различий, а затем сделать эту часть пользовательского драйвера различий Git, чтобы вы могли выполнить все свои действия по очистке?

person Philip Oakley    schedule 06.09.2016