Комментарии 6
Исходная статья хороша, но перевод выглядит слишком механическим.
Соглашусь, что исходная хороша: иначе бы не брал. При редактировании ставил задачу, чтобы текст прежде всего работал как структурированная шпаргалка, которую можно быстро просмотреть. Поэтому выбрал механику.
Если бы сохранял эмоции и обороты как есть, то текст оказался бы перегруженным, а местами сложным и даже непонятным, как в случае со строкой про файл и синтаксис :, или с "системным файлом конфигурации".
Честно говоря, кое-что и так осталось непонятным. В частности, совершенно неясно, как у -L с двоеточием происходит поиск конца блока. Впрочем, прочтение справки гита и парочка проведённых экспериментов это тоже совершенно не прояснили… Да и с номерами строк неочевидно, ведь они в процессе правки файлов часто меняются.
Да, номера строк меняются, но Git то тоже не дурак) Будет искать и сопоставлять именно похожие блоки кода, а не только строки.
Что git не дурак — это понятно. Проблема в том, что возможны разные варианты "недурацкого" поведения, и пользователь не в курсе, какое из них правильное. Ну ладно blame, там показывается одна версия файла с конкретой фиксированной нумерацией строк. А вот в случае с git log, скажем, уже не так очевидно становится. Например, указал я строки 5-10. А в предыдущем коммите после строки номер 7 был удалён большой кусок кода и заменён на совсем другой большой кусок кода. То есть строки 8-10 из выбранного блока оказываются без какой бы то ни было исторической связки. И совершенно неясно, что git решит отобразить в таком случае, как он выберет конец блока для этого предыдущего коммита.
Живьём оно лучшем
Итак, вы думаете, что знаете Git? Часть первая: старый добрый Git