Git виноват предыдущие коммиты?

git blame -L 10,+1 fe25b6d^ -- src/options.cpp

Вы можете указать версию для git blame, с которой нужно начинать поиск (вместо значения по умолчанию HEAD); fe25b6d^ является родительским элементом fe25b6d.

Изменить: впервые в Git 2.23 у нас есть --ignore-rev опция добавлена ​​в git blame:

git blame --ignore-rev fe25b6d

Хотя это не отвечает на вопрос OP о предоставлении стека коммитов (для этого вы будете использовать git log, в соответствии с другим ответом), это лучший способ этого решения, поскольку вы потенциально не ошибетесь в других строках.

Вы можете использовать git log -L для просмотра эволюции ряда строк.

Например :

git log -L 15,23:filename.txt

означает «проследить эволюцию строк с 15 по 23 в файле с именем filename.txt».

Ответ Эмбер правильный, но мне он показался неясным; Синтаксис:

git blame {commit_id} -- {path/to/file}

Примечание: -- используется для отделения древовидной формы sha1 от относительных путей к файлам. ¹

Например:

git blame master -- index.html

Полная благодарность Amber за то, что он все знает! :)

Возможно, вы захотите проверить:

git gui blame <filename>

Дает вам красивое графическое отображение изменений, таких как «git blame», но с интерактивными ссылками на строку для перехода к более ранним коммитам. Наведите указатель мыши на ссылки, чтобы открыть всплывающее окно с подробностями о фиксации. Не мои кредиты ... нашел здесь:

http://zsoltfabok.com/blog/2012/02/git-blame-line-history/

git gui - это графический интерфейс Tcl / Tc для git. Без каких-либо других параметров он запускает довольно простое, но полезное графическое приложение для фиксации файлов, фрагментов или даже отдельных строк и других подобных команд, таких как исправление, возврат, нажатие ... Это часть набора git stock. В Windows он включен в установщик. На debian - я не знаю о других системах * nix - его нужно устанавливать отдельно:

apt-get install git-gui

Из документов:

https://git-scm.com/docs/git-gui

ОПИСАНИЕ

Графический пользовательский интерфейс для Git на основе Tcl / Tk. git gui фокусируется на том, чтобы позволить пользователям вносить изменения в свой репозиторий, делая новые коммиты, изменяя существующие, создавая ветки, выполняя локальные слияния и извлекая / отправляя в удаленные репозитории.

В отличие от gitk, git gui фокусируется на генерации коммитов и аннотации одного файла и не показывает историю проекта. Однако он предоставляет действия меню для запуска сеанса gitk из git gui.

Известно, что git gui работает во всех популярных системах UNIX, Mac OS X и Windows (как Cygwin, так и MSYS). Насколько это возможно, соблюдаются рекомендации по пользовательскому интерфейсу для конкретных ОС, что делает git gui довольно родным интерфейсом для пользователей.

КОМАНДЫ

виноват

Запустить программу просмотра обвинений для указанного файла в данной версии (или в рабочем каталоге, если он не указан).

браузер

Запустите древовидный браузер, показывающий все файлы в указанной фиксации. Файлы, выбранные в браузере, открываются в программе просмотра обвинений.

citool

Запустите git gui и сделайте ровно одну фиксацию перед выходом и возвратом в оболочку. Интерфейс ограничен только фиксацией действий, что немного сокращает время запуска приложения и упрощает строку меню.

версия

Показать текущую версию git gui.

Основываясь на предыдущем ответе, этот однострочный пакет bash должен дать вам то, что вы ищете. Он отображает историю ошибок git для конкретной строки определенного файла за последние 5 ревизий:

LINE=10 FILE=src/options.cpp REVS=5; for commit in $(git rev-list -n $REVS HEAD $FILE); do git blame -n -L$LINE,+1 $commit -- $FILE; done

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

Это часто указывает на то, что строка была добавлена ​​впервые после этого конкретного коммита. Это также могло означать, что строка была перемещена из другой части файла.

Также есть recursive-blame. Его можно установить с помощью

npm install -g recursive-blame

Уникальное решение этой проблемы - использование git log, как объяснил Андре здесь:

git log -p -M --follow --stat -- path/to/your/file

Если вы используете JetBrains Idea IDE (и производные), вы можете выбрать несколько строк, щелкнуть правой кнопкой мыши для контекстного меню, затем Git -> Показать историю для выбора. Вы увидите список коммитов, которые повлияли на выбранные строки:

Начиная с Git 2.23, вы можете использовать git виноват --ignore-rev

Для примера, приведенного в вопросе, это будет:

git blame -L10,+1 src/options.cpp --ignore-rev fe25b6d

(однако это вопрос с подвохом, потому что fe25b6d - первая ревизия файла!)

Основываясь на ответе Уилла Шепарда, его выходные данные будут включать повторяющиеся строки для коммитов, в которых не было изменений, поэтому вы можете отфильтровать их следующим образом (используя это ответ)

LINE=1 FILE=a; for commit in $(git rev-list HEAD $FILE); do git blame -n -L$LINE,+1 $commit -- $FILE; done | sed '$!N; /^\(.*\)\n\1$/!P; D'

Обратите внимание, что я удалил аргумент REVS, и это относится к корневой фиксации. Это связано с наблюдением Макса Нанаси выше.

Основываясь на ответе DavidN, и я хочу следить за переименованным файлом:

LINE=8 FILE=Info.plist; for commit in $(git log --format='%h%%' --name-only --follow -- $FILE | xargs echo | perl -pe 's/\%\s/,/g'); do hash=$(echo $commit | cut -f1 -d ','); fileMayRenamed=$(echo $commit | cut -f2 -d ','); git blame -n -L$LINE,+1 $hash -- $fileMayRenamed; done | sed '$!N; /^\(.*\)\n\1$/!P; D'

ref: красиво отображать историю переименований файлов в журнале git

Я использую этот небольшой сценарий bash, чтобы посмотреть историю обвинений.

Первый параметр: файл для просмотра

Последующие параметры: переданы в git blame.

#!/bin/bash
f=$1
shift
{ git log --pretty=format:%H -- "$f"; echo; } | {
  while read hash; do
    echo "--- $hash"
    git blame $@ $hash -- "$f" | sed 's/^/  /'
  done
}

Вы можете указать параметры обвинения, такие как -L 70, + 10, но лучше использовать поиск по регулярным выражениям git blame, потому что номера строк обычно "меняются" со временем.

Используйте ответ на основе stangls , я поместил этот скрипт в свой PATH (даже в Windows) как git-bh:

Это позволяет мне искать все коммиты, в которых было задействовано слово:

git bh path/to/myfile myWord

Сценарий:

#!/bin/bash
f=$1
shift
csha=""
{ git log --pretty=format:%H -- "$f"; echo; } | {
  while read hash; do
    res=$(git blame -L"/$1/",+1 $hash -- "$f" 2>/dev/null | sed 's/^/  /')
    sha=${res%% (*}
    if [[ "${res}" != "" && "${csha}" != "${sha}" ]]; then
      echo "--- ${hash}"
      echo "${res}"
      csha="${sha}"
    fi
  done
}

Я написал ublame инструмент python, который возвращает наивную историю фиксации файла, которая повлияла на данный поисковый запрос, вы найдете дополнительную информацию на þпроектировать страницу.