Revision tree отдельного файла

Ты не понимаешь как устроен гит, отсюда совершенно безграмотные вопросы.

Ты сам не понимаешь как устроен git. Отсюда совершенно безграмотное заявление о сравнивании двух объектов типа commit в контексте моего вопроса о сравнивании одного файла.

По ходу топика ты меняешь условия задачи: в исходном посте решение git diff <branchname:filename> <branchname:filename>. Теперь же тебе потребовалось «выбрать два произвольных коммита на графе и сравнить их между собой».

Условие задачи не менялось: «и сравнить его с другой версией из другого бранча». Научись понимать прочитанное, тогда и глупых ответов от тебя будет меньше.

Опять безграмотное требование. Нет никакой технической мотивации сравнивать два объекта типа commit.

Не «два объекта типа commit», а две версии одного файла. И мотивация очень простая - посмотреть чем они отличаются.

Специально для каких так ты есть форма git diff <commit> <commit> — <filename>, что и является решением.

Это не решение, а лишь одна из нескольких команд, которые мне нужно запустить для решения поставленной задачи в CLI. До этого нужно запустить git --all --graph — path/to/file, выбрать два произвольных коммита с участием данного файла, сохранить в сторонке их хеши и лишь потом запускать git diff hash1 hash2 — path/to/file. Это неудобно и непродуктивно. Мне нужно интерактивное решение, которое делает всю чёрную работу за меня. Я уже нашёл это решение в gitk.

Для того чтобы выбрать два произвольных коммита есть команда git blame <branchname> — <filename>

Ещё одно безграмотное заявление от тебя. Эта команда всего лишь показывает последнюю версию файла из указанного бранча (или другой указанный revision) с добавлением анотации, показывая какой коммит последним изменял ту или иную строку этого файла.

Резюмируя. Опять гит-тролли жидко просрались.

Полностью согласен. Учитывая то, что git тролли - это такие как ты или q11q11.

а две версии одного файла

Прежде чем задавать вопросы, нужно хотя бы примерно овладеть терминами предметной области. Иначе: а) тебя не поймут; б) ты ответа не поймешь.

Нет такого понятия в гите как «две версии одного файла»! Ну нет, хоть ты тресни. Есть коммиты, деревья и блобы.

Чтобы найти нужный блоб нужно найти нужное дерево, чтобы найти нужное дерево нужно найти нужный коммит. Другого способа нет.

Если не нравится такая архитектура — не пользуйся.

Послушай себя: «У меня задача сравнить два блоба, так ведь для этого нужно эти два блоба указать команде сравнения, а это плохо. Мне нужно интерактивное решение на базе libastral.so». Это называется просто: клиника.

Если решение, найденной в gitk тебя устраивает, то тебе нафиг SCM, тем более гит, не нужны. Для навигации в трёх соснах навигатор не нужен. А вот запороть репозиторий так что потом коллеги настучат тапочкой по мордасам, во всяких гуях (тем более в гитк) — элементарно. Нет, конечно всё рано или поздно распутывается... Но вот потерянные вермя и силы могут оказаться весьма критичными.

Дык, появятся *технические* вопросы: обращайся. Но, чувствую, скоро я увижу ещё одного пятизвездочника, забаненного за хронический тупняк и неадекват.

Звёзды

Нет такого понятия в гите как «две версии одного файла»! Ну нет, хоть ты тресни. Есть коммиты, деревья и блобы.

Ты плохо читал документацию или не сумел её понять. Коммиты, деревья и блобы - это просто те объекты, с которыми работает git. При этом у файлов есть версии. Это логическое и к тому же общепринятое понятие.

Несколько цитат из https://git-scm.com/book/en/v2/Git-Internals-Git-Objects

Your database contains the two new versions of the file as well as the first content you stored there:

Now you can revert the file back to the first version

Напиши им, что они пользуются неправильной терминологией и ты их не понимаешь.

Чтобы найти нужный блоб нужно найти нужное дерево, чтобы найти нужное дерево нужно найти нужный коммит. Другого способа нет.

Если не нравится такая архитектура — не пользуйся.

Архитектура git не определяет должен ли я пользоваться исключительно CLI.

Послушай себя: «У меня задача сравнить два блоба, так ведь для этого нужно эти два блоба указать команде сравнения, а это плохо. Мне нужно интерактивное решение на базе libastral.so». Это называется просто: клиника.

Клиникой является подобная подмена понятий.

Если решение, найденной в gitk тебя устраивает, то тебе нафиг SCM, тем более гит, не нужны.

gitk делает ровно то же самое, но быстрее и удобнее.

Для навигации в трёх соснах навигатор не нужен.

Для навигации в большом графе бранчей и коммитов нужны удобные и продуктивные инструменты.

А вот запороть репозиторий так что потом коллеги настучат тапочкой по мордасам, во всяких гуях (тем более в гитк) — элементарно.

Запороть репозиторий чтением репозитория? И давно ты наркоман?

Та команда, которую предложил ты, просто показывает два коммита и что изменилось в каждом из них в отдельности, а не сравнивает их между собой.

Ну вот ты подтверлил что не понял как оно работает, или не знаешь git, или (что более вероятно) по синтаксису команды пытался понять какой должен быть результат без того чтоб попробовать на реальном примере.
Команда которую предложил я показывает изменения файла в КАЖДОМ из коммитов на промежутке hash1..hash2 (намекаю - промежутком может быть хоть всё дерево), а не твоё «два коммита и что изменилось в каждом из них в отдельности».

Для навигации в большом графе бранчей и коммитов нужны удобные и продуктивные инструменты.

В первую очередь нужны знания и мозг умеющий адекватно их применять, а если ты не понимаешь как это делать через CLI - никакой гуй тебе не поможет. Прицепился к проприетарщине и тупишь... а возьми и прояви гибкость, научись что-то делать несколькими способами, хуже тебе от этого не станет.

Команда которую предложил я показывает изменения файла в КАЖДОМ из коммитов на промежутке hash1..hash2

А мне эти изменения по отдельности вообще неинтересны. Мне нужно сравнить две версии. Для этого существует git diff hash1..hash2 — file. А до этого нужно найти эти hash1 hash2 в выхлопе git --all --graph — file. Но делать всё это в CLI вручную неудобно и непродуктивно. Сколько раз нужно повторять одно и тоже?

в первую очередь нужны знания и мозг умеющий адекватно их применять, а если ты не понимаешь как это делать через CLI - никакой гуй тебе не поможет.

Я прекрасно знаю как это делать при помощи git log и git diff. Но неадекваты вроде тебя занимаются распальцовкой и троллингом в комментариях. Решение я уже нашёл, успокойся.

Но делать всё это в CLI вручную неудобно и непродуктивно

И с чего ты взял что вручную? Не умеешь грепать less?
А в гуйне, я так понимаю, ты мышкой поскроллил дерево коммитов за 5 лет и продуктивненько так зрительно нашёл нужные тебе хэши, да?

Я прекрасно знаю как это делать при помощи git log и git diff.

читая твои каменты закрадывается сомнение

И с чего ты взял что вручную? Не умеешь грепать less?

С того, дорогой тролль, что выбор интесующих меня коммитов в выводе git log --all --graph — file я делаю глазами, тоесть интерактивно. Грепать то, что я ещё не видел, я не умею.

А ты перестань троллить, тогда и читать научишься.

Грепать то, что я ещё не видел, я не умею.

мммм, тогда расскажи мне каким образом гуй деалет поиск хэшей более продуктивным?

Спасибо, я уже на первой странице нашёл как пользоваться gitk.

мммм, тогда расскажи мне каким образом гуй деалет поиск хэшей более продуктивным?

Он вообще избавляет от поиска хешей. В пылу своего троллинга ты пропустил решение, которое я нашёл в gitk

Revision tree отдельного файла (комментарий)

gitk --all path/to/file

Делает ИДЕНТИЧНО то же что и я предложил через

git log -p --all --graph hash1..hash2 -- path/to/file

git log -p --all --graph $(git rev-list --all) -- path/to/file

Опять мимо, опять не сумел осилить простой текст. Сама по себе команда gitk --all path/to/file просто запускает gitk на определённый файл и на все бранчи, где он есть. А чтобы сравнить две произвольные версии этого файла нужно сделать то, до чего ты либо не дочитал, либо не понял прочитанное.

у меня простыня в консоли, которую кстати очень удобно грепать

И которая поставленную задачу не решает.

а вот в gitk я так и не смог разобраться как искать по содержимому всех этих коммитов.

Напишу схематически, надеюсь найдёшь

Find v^ commit [выбрать] [то что ты ищешь] [выбрать] [выбрать]

При этом у файлов есть версии. Это логическое и к тому же общепринятое понятие.

Да нет же! Нет никаких файлов. Нет никаких версий. Ну неужели так сложно понять? Хотя ладно. Спорить не собираюсь.

gitk делает ровно то же самое, но быстрее и удобнее.

Когда у тебя три коммита и два бранча — удобнее. Во всех остальных случаях от гуя вскипят мозги и стекут на клавиатуру.

Запороть репозиторий чтением репозитория?

Намного легче чем ты думаешь.

Да нет же! Нет никаких файлов. Нет никаких версий. Ну неужели так сложно понять?

Ты уже написал свои негодования авторам официальной документации?

> gitk делает ровно то же самое, но быстрее и удобнее.

Когда у тебя три коммита и два бранча — удобнее. Во всех остальных случаях от гуя вскипят мозги и стекут на клавиатуру.

У тебя они уже кипят.

> Запороть репозиторий чтением репозитория?

Намного легче чем ты думаешь.

Внимательно тебя слушаю.

до чего ты либо не дочитал, либо не понял прочитанное.

Дочитал и понял. То что ты нашёл в gitk - и есть то что я предложил с хэшами. ИДЕНТИЧНО.
Только ты мышкой скроллишь и кликаешь, а я набираю команду.
А теперь объясни каким образом зрительный поиск коммитов в гуе продуктивнее чем зрительный поиск коммитов в консоли?

Не идентично. В gitk я вижу результат git diff hash1 hash2 — file, а не то, что ты предложил. И в gitk делать это удобнее, потому что там мне не надо копировать эти hash1 hash2 из вывода git log. Но я уже устал объяснять это десятый раз подряд. Так что разговор окончен.

ты мозги заполоскал, я имел ввиду что твоё решение из gitk это и есть git diff hash1 hash2 — file, и искать хэши в гуи ничуть не продуктивнее

но факт в том что ты доковылял до гуишного решения которое тебе и так предложили в саааамом первом каменте, изворачивался, пыхтел, а в итоге вынужден делать ровно то, что предоставляет свободный софт, и ни капли более

Платиновые треды лора.