Подтвердить что ты не робот

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

Вот моя проблема за последние 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 вину не показывать, что было удалено)?

4b9b3361

ОТВЕТЫ

Ответ 1

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

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

Ответ 2

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

git log -Gpandemic -p

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

Ответ 3

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

Итак Karl Bielefeldt answer будет следующим:

 git blame --reverse abcdef01 -- <file>

См. commit d993ce1 (14 июня 2016 г.) Junio ​​C Хамано (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" - это аббревиатура "Do What я Mean" (не то, что я говорю))

Ответ 4

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

https://github.com/eantoranz/difflame