#c #git #git-diff
#c #git #git-diff
Вопрос:
Я использую git diff, чтобы выяснить, какие методы изменились. Очевидно, что он неправильно определяет заголовок hunk (как показано ниже), из-за чего я не могу найти способ получить список измененных методов.
@@ -22,7 22,7 @@ void func2(){
void func1(){
cout<<"Function 1"<<endl;
- int i=1000;
int i=100;
while(i>0){
func2();
i--;
Здесь изменение происходит в func1(), но заголовок hunk находится в func2() . Я попытался изменить некоторые тестовые функции, оказывается, он всегда выбирает строку / функцию над требуемой функцией в качестве заголовка фрагмента.
Я попытался создать файл .gitattributes в корневом каталоге и разместить *.cpp diff=cpp , чтобы включить cpp для diff, к сожалению, это не решило проблему.
Комментарии:
1. Является ли hunk словом из жаргона программирования? Кроме того, возможно, было бы полезно показать соответствующее содержимое файла в двух коммит, чтобы мы могли воспроизвести проблему.
2. Пожалуйста, определите «hunk»?
3. «Фрагмент» — это раздел из diff. Файл может сообщать о 1 или нескольких фрагментах в diff (на самом деле, возможно 0 фрагментов …. при изменении флагов, например)/
4. Что касается git diff, hunk — это раздел, который содержит изменения, а начало hunk определяется как заголовок hunk.
Ответ №1:
Проблема здесь в том, что это различие работает func2 .
Обратите внимание, что diff начинается с пустой строки, за которой следует определение функции func1 . Это определение находится внутри diff-hunk, поэтому diff-hunk начинается перед функцией. Предположительно, над пустой строкой мы найдем больше кода func2 . Это контекст, о котором git diff вам рассказывается: что предшествует diff .
Можно (довольно разумно!) Утверждать, что единственное изменение в diff находится внутри функции func2 , но тогда что Git должен делать с фрагментом diff, который читает, например:
T f1() {
new_call();
return somevalue;
}
T f2() {
- old_call();
return somevalue;
}
Здесь разница влияет на две функции, f1 и f2 , внутренне. Ответ Git на вопрос «как это обозначить» заключается в том, чтобы начать со всего текста и выполнить поиск в обратном направлении для некоторого регулярного выражения. Если это соответствует f0 , это метка, которая идет в diff.
(Примечание: встроенные регулярные выражения работают довольно хорошо, но не распознают все возможные определения разрешенных функций на всех языках. Изменение объема отображаемого контекста должно помочь в этом конкретном примере, хотя вам придется уменьшить его максимум до 1 строки.)
Комментарии:
1. Вы упомянули, что он выполняет поиск в обратном направлении для некоторого регулярного выражения, тогда почему он пропускает func1 и переходит к пути к функции выше этого. Также, когда над текущей функцией нет функции, тогда вывод является пустым.
2. Ваш фрагмент diff начинается со строки 22. Что находится в строке 21 и что в строках перед строкой 21? Вот где Git выполняет поиск: начиная со строки 21 и выше. Вот почему заголовок не имеет метки, когда нет более ранней функции.
3. Вы правы, строка 22 является пустой строкой, а перед ней — вся func2. Вот почему он подходит для func2. Есть ли какой-либо способ получить func1, т.Е. Метод, в котором присутствует изменение.
4. С Git, написанным так, как он есть, вы можете только попытаться уменьшить количество строк контекста, как я сказал в своем ответе. Если вы хотите, чтобы Git вел себя по-другому, что ж, у него открытый исходный код: клонируйте его и используйте код. 🙂
5. Один последний запрос, если это поведение git по умолчанию, то почему некоторые потоки рекомендуют использовать git diff или git log, чтобы узнать измененный метод, когда он всегда будет указывать на что-то выше метода. Кстати, я отмечаю ваш ответ, спасибо.