Кто удалил мои изменения в git?

Question

Вот моя проблема за последние 30 минут: у меня была пара изменений, которые исчезли в одном из моих файлов, и я не знаю, когда это произошло.И я хочу знать, кто это сделал!

Я начал искать ревизии с моими файлами:

git grep <searched_string> $(git rev-list --all) -- <file>

- это путь к файлу или подстановочный знак типа * .gsp

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

git rev-list --children <revision_id>

- это 40символы с начала последней строки предыдущей команды

Близко!Я смотрю на начало вывода и беру первого потомка, а затем запускаю

git log <revision_id_s_first_child> --stat

Затем я смотрю на вывод и нахожу свой файл и кто внес изменения!(оказалось, я был виноват ...)

Есть ли способ сделать это быстрее (Git Blame не покажет, что было удалено)?

Answer 1

git blame имеет опцию --reverse, которая принимает диапазон коммитов и показывает вам последний коммит, где существовала строка перед ее удалением. Итак, вы нашли коммит, который, как вы знаете, были там, например, abcdef01, и чтобы показать последний коммит перед удалением, выполните:

git blame --reverse abcdef01..HEAD -- <file>

Answer 2

Если вы знаете некоторую подстроку, которая была бы в строке, которая была удалена, то вы можете использовать опцию -G для git log, чтобы найти коммиты, которые внесли изменения, которые добавили или удалили строки, содержащие эту подстроку. например если вы знали, что слово «пандемия» было в исчезнувшей строке, вы можете сделать:

git log -Gpandemic -p

(Параметр -G может быть регулярным выражением.) Этот параметр был добавлен в Git относительно недавно - если он не работает, попробуйте вместо этого -S, который имеет немного другую семантику, но должен иметь аналогичную эффект.

Answer 3

Обратите внимание, что начиная с Git 2.11 (4 квартал 2016 года), вам не нужно указывать ..HEAD, если вы хотите посмотреть коммиты между конкретной и текущей единицей.

Итак Карл Билефельдт ответ будет тогда:

 git blame --reverse abcdef01 -- <file>

См. commit d993ce1 (14 июня 2016 г.) от Junio ​​C Hamano (gitster) .
^{(Объединено с Junio ​​C Hamano - gitster - в коммит 1172e16 , 10 октября 2016 г.)}

вина: dwim "blame --reverse OLD" как "blame --reverse OLD.."

Распространенной ошибкой является выражение "git blame --reverse OLD path", предполагая, что командная строка выключена, как будто спрашивает, как строки в пути в старой редакции OLD сохранились до текущего коммита.

Вместо того, чтобы всегда требовать оба конца диапазона, мы могли бы DWIM "OLD", который мог быть ошибкой "OLD..", быть диапазоном, который заканчивается на текущем коммите.

git blame --reverse теперь включают:

--reverse <rev>..<rev>:

Ходить историю вперед, а не назад.
Вместо того, чтобы показывать ревизию, в которой появилась строка, она показывает последнюю ревизию, в которой существовала строка. Для этого требуется диапазон редакций, например START..END, где путь к обвинению существует в START.
git blame --reverse START принимается за git blame --reverse START..HEAD для удобства .

(Примечание к примечанию: "dwim" - это сокращение от "Делай, что я имею в виду" (не то, что я говорю) )

Answer 4

git blame --reverse может приблизить вас к месту удаления строки. Но на самом деле это не указывает на ревизию, в которой строка удалена . Он указывает на последнюю редакцию , где строка была присутствует . Тогда, если следующая ревизия является простым коммитом , вам повезло, и вы получили ревизию удаления. OTOH, если следующая ревизия - коммит слияния , то все может стать немного диким. В рамках усилий по созданию difflame я решил эту проблему, поэтому, если на вашем компьютере уже установлен python и вы хотите попробовать его, не ждите больше и дайте мне знать как дела.

https://github.com/eantoranz/difflame