TL; DR: -G не совсем делает то, что вы хотите, но смотрите Регулярное выражение для соответствия строке, которая не содержит слова? и обратите внимание, что -G использует POSIX "расширенный синтаксис регулярного выражения.
Длинный
Вам нужно решить две разные проблемы (плюс некоторая бесполезная документация из Git).Одной из таких проблем является написание регулярного выражения, которое выбирает то, что вы хотите. Ответ RomainVALERI нацелен на это (но, к сожалению, отсутствует), игнорируя другую проблему: -G не вполне сделает то, что вы хотите.Позвольте мне вначале разобраться с этим.
Команды git diff и git log (которые являются совершенно разными командами) совместно используют некоторый исходный код и некоторую документацию.И -G, и -S активируют то, что Git называет киркой , которая описана на отдельной странице под названием gitdiffcore .
Когда мы запускаем git log,у нас общая проблема: он показывает нам слишком много коммитов.Мы хотим видеть меньше коммитов!В частности, мы хотим увидеть коммиты, которые повлияли на некоторые части нашего кода.Вот где -G и -S являются наиболее полезными: git log -G<regex> или git log -S<text> находят коммиты, где, если мы запустим git show на этих коммитах, мы увидим изменение, которое повлияет накод, который мы просили найти.
Помните, git show <hash> запускает, более или менее, git diff <hash>^ <hash>, чтобы сравнить снимок в родительском элементе одного конкретного коммита с моментальным снимком в дочернем элементе.То есть каждый коммит хранит полный снимок, поэтому, сравнивая , что в родительском с , что в дочернем , мы можем узнать, что изменило в этом коммите. 1 Как только мы узнаем, что изменилось , мы можем искать через него некоторые конкретные изменения.
Итак, вернемся к git logна некоторое время: мы могли бы захотеть выяснить, какие коммиты изменили дату авторского права, чтобы посмотреть, изменили ли они что-нибудь еще.Таким образом, у нас было бы git log -S или git log -G find и list / show всех коммитов , которые содержат строку, содержащую слово copyright в их diff * .Вот для чего эти варианты особенно хороши.Но это не то, что вы пытаетесь сделать.
1 Это немного похоже на просмотр графика высокой температуры каждый день в течение последней недели и выяснение того, какиеднем температура изменилась больше всего: мы должны вычесть дневные пары;зная, что в понедельник было 24 ° C, а в среду - 18 ° C, мы ничего не говорим о том, что было во вторник, но если во вторник было 19 ° C, сейчас , мы знаем, что оно изменилось на 5 с понедельника по вторник., а затем на 1 от вт до ср.Аналогично, со снимками исходного кода мы должны вычесть снимок понедельника из вторника, чтобы увидеть, что изменилось во вторник.Мы должны вычесть вторник из среды, чтобы увидеть, что изменилось в среду.
Теперь, когда мы запускаем git diff на любых двух конкретных коммитах , например:
git diff <old-commit> <new-commit>
Git эффективно вычитает старый коммит из нового коммита, чтобы сказать нам, что отличается.Но коммит состоит из файлов .В каждом из двух коммитов может быть 10000 файлов.Разница покажет нам, что изменилось в каждом файле, и это может быть 1% файлов или 100 файлов, но нас могут интересовать только файлы, в которых в diff содержится слово "copyright ", например.
Это то, что делает кирка (-G или -S) при использовании с git diff: если git diff было покажите нам 100 файлов с различиями, кирка выбирает только те файлы, которые содержат конкретные изменения, которые мы просим найти .Таким образом, если бы git diff показал бы нам 100 файлов, но только десять файлов имеют слово "copyright" в их выводе diff, git diff -G copyright <old> <new> покажет нам эти десять файлов .
В вашем случае, когда вы найдете регулярное выражение, которое соответствует вещам, которые не являются"авторскими правами", вы можете сказать Git: Найти различия, которые изменили что-то кроме текста послеслово copyright. Если вы используете это с git diff, это покажет вам full diff - включая изменение авторских прав! - файлов, которые изменили строку, которую не содержит слово "авторское право".
Это не то, что вы сказали, что хотели.Впрочем, это может быть достаточно хорошо, потому что это то, что Git может дать вам.
Теперь давайте вернемся к поиску строки, содержащей изменение, которое не содержит слова "@copyright ", возможно, после буквального звездочки и пробела.Это сложнее, чем кажется!Я передам это на рассмотрение существующего вопроса на арене regex и его многочисленных ответов: Регулярное выражение для соответствия строке, не содержащей слова? Git использует POSIX расширенные регулярные выражения или ERE.Они не имеют отрицательного внешнего вида, поэтому метод в первом комментарии или этот ответ выполнит работу, а принятый ответ - нет.