Система контроля версий и бекап для распределенных бекапов
Добрый день,
посоветуйте, пожалуйста, бесплатный сабж. Имеется 4-6 пользователей под линукс (убунта), которые совместно девелопят проект, в котором не только много данных и компиляторов (используется веб, С/С++, ембеддед, плиски, питон, скрипты), но и имеется много (терабайты) данных. Пока все на общественных началах, поэтому на старье, что у кого было под рукой.
Имеется небольшой сервер в сети (300ГБ есть свободных) и есть переносные системы бекапов, в которые можно вставлять старые, но еще живые HDD суммарно на 50ТБ, у каждого есть просто свой лаптоп (не новый, а какой есть).
Что хочется.
Иметь какой-то разумный список дирректорий на каждом лаптопе, для которых писать какие-то атрибуты, и на основе решать следующие задачи:
1. Поддерживать контроль версий для разработки софта, там данных мало, до миллиона строк кода мы врят ли добежим, но больше ста тысяч строк будет однозначно.
2. Компиляторы: у нас нет возможности купить все лицензии на каждого, поэтому планируется, что на каждом компе свой зоопарк, но этот зоопарк разумно тоже как-то бекапить и иметь доступ компилировать удаленно.
3. Поддерживать бекапность и распределение данных для самих данных, то есть у каждого пользователя есть данное, и, при необходимости он может его синхронизовать с кем-то, или удалить у себя, чтобы на свободное место закинуть что-то другое.
4. Надо также иметь обычный бекап раз в день и раз в месяц, желательно всех данных и софта.
5. Данных за день может нагенериться на пару терабайт, иногда данные надо распределять друг между другом, иногда, по прошествии какого-то времени выбрасывать. У каждого разные лаптопы, у кого-то всего с системой 500ГБ, у кого-то 4ТБ.
6. Не всегда у всех есть доступ к интернету или к быстрому интернету. Грубо говоря, много данных генерятся в полевых испытаниях (компьютер вижн и кучи спец сенсоров от бегающей собачки-спота по полю), и иногда надо это сохранять, иногда распределять между всеми, а иногда, по прошествии какого-то время или бекапить, или выкидывать.
Я понимаю, что перфекционистского решения нет, и его разработка под нашу задачу потянет на год, но уверен, что можно не совсем перфекционистское решение быстро собрать.
Посоветуйте, пожалуйста, на каких системах контроля версий или подобных системах это было бы правильнее делать?
Спасибо!
Для начала давайте делить задачи... Или хочется всё в одном?
на каких системах контроля версий
Думаю git вполне подойдет для исходников и не очень больших бинов.
Сделал общий репозиторий, скачал копию себе и ушел. после синхронизация
Компиляторы
Видимо докер. Сделал оригинальный снимок и пользуй где нужно.
бекап
https://www.2brightsparks.com/syncback/sbpro.html давно пользуюсь очень доволен и цена божеская
Спасибо за ответ!!!
Для начала давайте делить задачи... Или хочется всё в одном?
вообще-то да. Ибо есть проблемка - данные могут быть большими, канал - тонким, а полной репы может не быть рядом. В результате народ начнет рукоблудить и все поедет юзом.
То есть пример - двое из команды со своими лаптопами (500ГБ и 4ТБ) наснимали данных суммарно на 2ТБ где-то в поле без доступа к интернету (в Швейцарии роуминг и народ пожмотил), тот, у кого 4ТБ - сохранился у себя, другой сохранил часть, что посчитал нужной для него. Они разъехались, отослали на сервер сорсы апдейтов и док репорта, остальные через время захотели вытащить данные посмотреть, но тот, кто у себя взял все, уже успел забыть отчекить это куда-то,
да и не куда, на сервере в сети есть только 300ГБ, а на внешних дисках, что туда-сюда из рук в руки передаются, кто-то чего-то подзабыл сохранить. Потом получилась неразбериха и все поругались обвиняя друг друга в раздолбайстве.
То есть я хочу, чтобы все эти сценарии разумно поддерживались бы и поддерживалась ситуация, когда данные на столько большие, что при попытке чекина тебе говорят, может ты все-таки не по ваейрлесу чекиться будешь, а ножками до сервера дойдешь и проводок воткнешь иначе это на денек может затянуться.
А для сорсов да, что-то вроде гита, или все-таки cvs - это верно. Но не хочется кучи всего и разного, а хочется из одного флакона. И чтоб сравнения данных умело делать не качая данные по сети. То есть грубо говоря у двух на лаптопах есть даные по 200ГБ, и система по контрольной сумме детектировала, что это - одно и то же, и если у одного не хватает места, он может бросить запрос с фразой "можно я у себя удалю" чтобы локально новые данные нагенерить, но чтобы потом при необходимости эти данные к нему, если это нужно, снова приедут.
https://www.2brightsparks.com/syncback/sbpro.html давно пользуюсь очень доволен и цена божеская
Спасибо большое за ссылку, как я понимаю, они линукс не поддерживают? К сожалению, дальше не смотрел из-за этого.
они линукс не поддерживают?
никогда не интересовался. Там другой мир...
Ибо есть проблемка - данные могут быть большими
Не думаю, что есть что то готовое. Возможно что то свое с гитом скрестить.
Типа для больших файлов делаем файл ссылку: (контрольная сумма, у кого оригинал, где будет копия, и т.п.)
может проще micro sd card по почте слать?
на сервере в сети есть только 300ГБ
А что мешает сделать больше? Буквально на неделе искал хороший 7200 диск, меньше 2 терабайт не нашел. 4-6 Tb стоят не очень много сейчас + синологи= нормальный домашний сервер.
может проще micro sd card по почте слать?
я лет 10 назад как раз участвовал в проекте, где данные по почте были. Раз в неделю приходила посылка с двухтерабайтником, или двумя такими дисками, а после обработки, я эти диски назад отправлял. Тогда была иерархия - точка-в-точку, особо не требовало усилий.
А что мешает сделать больше? Буквально на неделе искал хороший 7200 диск, меньше 2 терабайт не нашел. 4-6 Tb стоят не очень много сейчас + синологи= нормальный домашний сервер.
Сейчас данных может быть много. Как я уже писал, есть 50 терабайт, скорей всего будет еще докупаться. И основная проблема не в том, где найти на домашнем сервере столько места, а как не запутанно организовать способ сохранения и бекапов, чтобы команда без простоя работала и не сралась из-за не понимания где есть данные. Технически почти всегда какая-то обработка данных может быть произведена и удаленно, но, грубо говоря, это тоже надо администрить. То есть если кто-то обнаружит, что ему нужные данные есть у меня на лаптопе, качнет свой софт мне, и у меня запустит обработку, а я, не зная, что это произошло, возьму и закрою крышку лаптопа.
Да и качнуть терабайт с одного
пользователя другому по домашней сетке может быть сложно хотя бы из-за того, что провайдер может на дыбы встать. А по мобильнику - так совсем. Тем более в Германии, с ужасно плохой инфраструктурой сетей. Я, кстати, несколько лет назад, когда у меня был ужасно медленный интернет, как-то попросил знакомого качнуть где-то 400ГБ на мой сервер, так его проводной провайдер (1&1) ему потом слал кучу макулатуры на подпись, что он не торрентил.
Сейчас данных может быть много
В любом случае их нужно где то хранить в одном месте.
И если по интернету сложно, то остается только физическая пересылка.
как не запутанно организовать способ сохранения
Это будет проблема N1. Что именно хотим хранить? Большие данные или только "ссылки" на них?
и бекапов,
Это будет проблема N2 - почти уверен что под никсами есть полно софта для этого.
https://www.cyberciti.biz/open-source/awesome-backup-softw...
- Git-сервер - наше всё! Забиваем на облака, ставим свой GitLab прям на нашем серваке. Контроль версий, задачи, вики – весь пакет. Работаем круто и без шума.
- Git на каждом лаптопе: Чтобы каждый был сам по себе хакер, настраиваем локальные репы Git. Оффлайн? Не беда, всё синхронизируем потом.
- Docker – наше спасение: Каждый со своими компиляторами, как в зоопарке, но без головняка. Docker на помощь – контейнеры туда-сюда, и всё гладко.
- Бекапы? Есть! Берем rsync или что посерьезнее типа Bacula, и настраиваем автомат бекапов на сервер и внешние HDD. Пусть крутится!
- Синхронизация – по пацански: В оффлайне? Не вопрос, Wi-Fi сеть в студию, Syncthing и всё такое. Обмениваемся данными, как настоящие гуру.
- Шифрование и VPN: Чтобы никто не подсматривал, шифруем данные и ставим VPN. Безопасность превыше всего!
- Управление доступом: Кто куда может – строго по списку. Никаких лишних глаз и рук.
Вот такой план, бро. Работаем круто, быстро и без шума. Пацаны в теме! 🤟
вон тебе совет от ChatGPT :)
- Git-сервер - наше всё! Забиваем на облака, ставим свой GitLab прям на нашем серваке. Контроль версий, задачи, вики – весь пакет. Работаем круто и без шума.
- Git на каждом лаптопе: Чтобы каждый был сам по себе хакер, настраиваем локальные репы Git. Оффлайн? Не беда, всё синхронизируем потом.
- Docker – наше спасение: Каждый со своими компиляторами, как в зоопарке, но без головняка. Docker на помощь – контейнеры туда-сюда, и всё гладко.
- Бекапы? Есть! Берем rsync или что посерьезнее типа Bacula, и настраиваем автомат бекапов на сервер и внешние HDD. Пусть крутится!
- Синхронизация – по пацански: В оффлайне? Не вопрос, Wi-Fi сеть в студию, Syncthing и всё такое. Обмениваемся данными, как настоящие гуру.
- Шифрование и VPN: Чтобы никто не подсматривал, шифруем данные и ставим VPN. Безопасность превыше всего!
- Управление доступом: Кто куда может – строго по списку. Никаких лишних глаз и рук.
Ладно, ребята. Недавно узнал, что поправить комменты к запушенному коммиту в Гите просто так нельзя. Нужно делать разную магию, любая из которой не рекомендуется. Например, можно создать новую ветку, с места до коммита, в котором хочешь исправить коммент, сделать в этой новой ветке изменения, аналогичные коммиту, где хочешь исправить коммент, написать правильный коммент, запушить коммит в новой ветке, затем замёрджить новую ветку с той, в последнем коммите которой хочешь исправить коммент. Фича простого исправления коммента в коммите достаточно востребованная, но сколько лет прошло - ничего не сделано для неё. Поэтому все просто забивают на исправление комментов, если это что-то не слишком уж важное, типа исправить опечатки или добавить-удалить описание коммита.
Торвальдс там чем думал, когда такое творил?
Хранение данных. Совместима с Амазоновским S3 https://github.com/minio/minio
Версионирование данных. https://github.com/iterative/dvc Довольно популярная штука, хотя я не уверен, что это хорошо. Какие-то наши сделали и весной-летом подняли финансирование и искали работников на удаленку.
Обработка данных. https://github.com/ray-project/ray Это просто огонь. Я покурил немного доки и впечатлился. Spark отдыхает. Для обработки и анализа данных. Уже есть на AWS и Azure, хотя относительно новая штука.
если можно будет поправить комменты?Давайте начнем немного с другого.
Закомитил я проект и вдруг вижу, что в описании ошибка. Как ее исправить? Нужно видимо отредактировать файл readme в коммите.
Хочу редактировать - фиг вам, низзя - почему?
Вы смешали коммит и его описание. Исправить коммит - это исправить код. Это через другой коммит. А описание коммита это не код. И его должно быть можно исправить без проблем. То, что Торвальдс не разделил это - его недоработка.
А что, править коммент коммита можно только через другой коммит? А как? Делать пустой коммит с правильным комментом? Это же чушь - коммент относится к коммиту, т.к. комментирует то, что сделано в коммите.
коммент относится к коммиту
вот именно! Это и есть концепт.
И представьте, что коммент - это специальный невидимый файл в коммите.
Если очень хочется можно представить, что будет если разрешить редактировать любой коммент.
1й чел. забрал и отредактировал.
2й чел. забрал и отредактировал тот же коммент.
Какие нужны будут операции на сервере, когда оба захотят сохранить...
представьте, что коммент - это специальный невидимый файл в коммите.
Какая разница, как это сейчас реализовано? Главное, как нужно было. Торвальдс недоработал. "Мы не можем это сделать - у нас реализация не позволяет". Ну так сделай, чтобы позволяла. Или нимб над головой мешает, а личные, персональные фанаты и не сильно требуют?
Если очень хочется можно представить, что будет если разрешить редактировать любой коммент.
1й чел. забрал и отредактировал.
2й чел. забрал и отредактировал тот же коммент.
Какие нужны будут операции на сервере, когда оба захотят сохранить...
Вопросы синхронизации человечество решило уже давным давно. Как и вопросы прав доступа. Или Торвальдс недоработал и тут?
А что, править коммент коммита можно только через другой коммит? А как? Делать пустой коммит с правильным комментом? Это же чушь - коммент относится к коммиту, т.к. комментирует то, что сделано в коммите.
Концепт предельно прост - все, что сохраняется не может быть изменено.
Так сказать "написаное пером не вырубить топором". И если человек хочет внести какие-то изменения, то ему предоставили способ эти изменения сделать. Но при этом должно быть видно, что были изменения.
Концепт предельно прост - все, что сохраняется не может быть изменено.
Я и говорю - сделано на отъебись, proof of concept, не подумав дальше носа. А потом забронзовело, как и создатель этого. )))
Главное, как нужно было.
Сделано именно так как нужно.
А то, что кому то хочется по другому...
Вроде бы казалось, концепт понятен стал, но нет - разработчик придурок.
Вопросы синхронизации человечество решило уже давным давно.
Интересно, поделитесь знаниями. Как конкретно будем синхронизировать изменения одного и того же коммента от разных людей?
Коммент синхронизировать не надо
Интересно, редактировать хочу, а синхронизировать не надо.
На коммент имеется право доступа
Значит добавляем еще права доступа к комменту, историю изменений коммента и синхронизацию изменений со всеми приложениями которые пользуют комменты.
А синхронизировать - так же, как и коммиты
А конфликты вручную еще не приходилось править? При этом не забываем, что изменения записываются всегда в новый коммит, а не в старый.
Кстати, хочу еще rollback изменений коммента 
Коммент синхронизировать не надо. На коммент имеется право доступа - у его создателя и администратора. А синхронизировать - так же, как и коммиты, не?
Я имел ввиду, что позволяется редактировать коммент тем, у кого есть права, а синхронизируют их как обычно - как и коммиты.
У кода есть версии, обновляемые в виде коммитов, а у комментов - нет - их можно редактировать напрямую. Вот и вся разница. Для коммитов есть история, для комментов - в принципе, тоже можно придумать, но не обязательно.
Ладно, проехали - не надо, так не надо. Мне надо. Но если нельзя - ну и хрен с ним.
Нельзя, но если очень хочется, то можно.
Можно, но если трудно сделать, то нельзя. ))
"Сперва добейся"
Я ж тебе уже говорил пару раз, что ты не очень разумный человек, да?
У тебя есть open source проект (прикинь?) тебе не нравится какая-то фича (или отсутствие какой-то фичи). Ты долго и нудно воняешь по этому поводу. Все тебя посылают, потому что считают твою вонь просто проявлением тупости. Ну так докажи всем. Сделай форк и добавь эту фичу. Глядишь, поймёшь почему камменты менять нельзя. Хотя, вряд ли, конечно.
Ваше "опенсорс" не нужно 99,99% людей. Они хотят просто пользоваться готовым и чтобы работало как надо. Может даже заплатят что-то за это, но то меньшинство. Но если не работает - те же 99,99% просто смирятся или пройдут мимо, может даже выскажут претензии. Но исправлять ничего не будут, т.к. игра не стоит свечь.
Спрошу здесь. В Гите можно посмотреть все файлы проекта на текущий коммит? Не лишь изменённые, а все. При этом не загрузить себе весь проект, а лишь из списка файлов глянуть нужные. Глянуть историю коммитов для конкретного файла можно, но этого мало - мне нужно глянуть, как некоторые взаимозависымые файлы - изменённые и нет - выглядели при том или другом коммите.
В TFS майкрософтовском на каждый коммит можно было смотреть все файлы - изменённые и нет.
Типа так для любого коммита?
Да. Что это за утилита. В Студию встраивается?
Кстати, любителям консоли. А как в консольных клиентах Гита реализована демонстрация тех же списков файлов коммита, комменты, ещё что-то? Всё прямо в консоли пытаются изобразить костыльными средствами форматирования текста?
... все файлы проекта на текущий коммит? Не лишь изменённые, а все. При этом не загрузить себе весь проект, а лишь из списка файлов глянуть нужные.
Так все файлы или нужные? Что значит "глянуть"? Посмотреть на имена или на содержание? Если на содержание, чтобы посмотреть на него, его придётся того... Загрузить с удалённого сервера. Удивился?
git archive тебе в помощь. "Не загружая весь проект", в смысле не клонируя и не стягивая всю историю, просто скопировать состояние проекта на определённый коммит.
Или пользуйся серверами гит вроде гитлаб, гитхаб, битбакет. У них у всех есть веб-интерфейс, покажут тебе состояние проекта в любом коммите.
Кстати, любителям консоли. А как в консольных клиентах Гита реализована демонстрация тех же списков файлов коммита, комменты, ещё что-то? Всё прямо в консоли пытаются изобразить костыльными средствами форматирования текста?
Оооо... Отсталый виндузятнег. Уже лет 10 как напрямую в мозг проецируют, лошара.
Так-то вопрос, конечно, дебильный. В консоли - консольными средствами. Форматированием текста. А чем ещё можно пользоваться в консоли?
Предваряя твои "хитрые" вопросы, открою тебе страшную тайну: если человек умеет пользоваться консолью, то у него есть мозги. Он может выбирать себе подходящие инструменты. И с гуём он справится. Обратное не верно.
Чтобы посмотреть сложную историю, лично я беру SourceTree. Имхо лучше всего показывает. Быстро глянуть на 2-3 ветки достаточно и текста в консоли.
Список файлов коммита... А без свистоперделок ты уже имена файлов в текстовом виде не воспринимаешь? Без иконок несчитово? В обычной работе я посмотрю коммит в IDE. Если прибегают кнопкожмяки с "памагити паламалась", то смотрю в консоли, быстрее, надёжнее.
... все файлы проекта на текущий коммит? Не лишь изменённые, а все. При этом не загрузить себе весь проект, а лишь из списка файлов глянуть нужные.Так все файлы или нужные? Что значит "глянуть"? Посмотреть на имена или на содержание? Если на содержание, чтобы посмотреть на него, его придётся того... Загрузить с удалённого сервера. Удивился?
git archive тебе в помощь. "Не загружая весь проект", в смысле не клонируя и не стягивая всю историю, просто скопировать состояние проекта на определённый коммит.
Или пользуйся серверами гит вроде гитлаб, гитхаб, битбакет. У них у всех есть веб-интерфейс, покажут тебе состояние проекта в любом коммите.
Мне нужен список всего в проекте на каждый коммит - как в окошке Solution Explorer в Студии. Но чтобы я мог открыть любой файл. Как оно там будет сделано внутри - всё загрузит или не всё - мне пофиг. Я хочу как в Solution Explorer, но на каждый коммит. Буду я открывать все файлы или только один - моё дело. Но чтобы список всего был доступен как в Solution Explorer. И чтобы мне не пришлось выгружать текущую версию проекта и загружать просматриваемый коммит.
git archive тебе в помощь. "Не загружая весь проект", в смысле не клонируя и не стягивая всю историю, просто скопировать состояние проекта на определённый коммит.
И дальше что? Я ввёл это в консоли, он скопировал, теперь я должен открыть проект и смотреть в Студии? А если я не хочу закрывать текущий проект или его состояние? Насколько я знаю, Гит не может держать несколько копий проекта одновременно. Раньше я тут спрашивал - а как загрузить сразу несколько версий проекта в разные папки? А мне ответили (вроде даже вы) - Гит не про это, он про хранение лишь одной версии. Т.е. открыть один и тот же проект в разных состояниях на двух параллельно запущенных IDE он тоже не позволяет.
А как в такой системе смотреть сравнение файлов разных версий?
Или пользуйся серверами гит вроде гитлаб, гитхаб, битбакет. У них у всех есть веб-интерфейс, покажут тебе состояние проекта в любом коммите.
Т.е. Гит сам по себе нихрена не умеет, кроме как хранить историю изменений? Без обвеса кучей далеко не консольных утилит он имеет мало толку, т.к. просто хранить версии - полдела, нужно ещё и ПОКАЗЫВАТЬ. Тогда чего ж вы все, линуксойды, дрочите на эту сраную консольку? Нахрена осваивать консоль И гуй, если можно просто гуй, где будут к коммиты, и пуши, и сравнения версий, и ссылки на вики по проекту, привязка к таскам, и всё остальное?
))
Предваряя твои "хитрые" вопросы, открою тебе страшную тайну: если человек умеет пользоваться консолью, то у него есть мозги. Он может выбирать себе подходящие инструменты. И с гуём он справится. Обратное не верно.
Чтобы посмотреть сложную историю, лично я беру SourceTree. Имхо лучше всего показывает. Быстро глянуть на 2-3 ветки достаточно и текста в консоли.
Список файлов коммита... А без свистоперделок ты уже имена файлов в текстовом виде не воспринимаешь? Без иконок несчитово? В обычной работе я посмотрю коммит в IDE. Если прибегают кнопкожмяки с "памагити паламалась", то смотрю в консоли, быстрее, надёжнее.
Линукс way - обложиться кучей разной мелокозаточенной хрени, каждая на свой случай жизни, у каждой свой подход и видение её создателя, который всех считает говном, кроме себя. Какая-то торвальдсовская болезнь, которую он перенёс на все свои поделия и на всех своих сектантов. ))
Т.е. Гит сам по себе нихрена не умеет, кроме как хранить историю изменений?
Совершенно верно. Ещё немного и у тебя наступит просветление (хотя нет, не наступит, для этого надо думать, прости). Это философия такая. Каждый занимается своим делом и не пытается объять необъятное. Утилитка делает одно дело, но делает его хорошо.
Мне нужен список всего в проекте на каждый коммит - как в окошке Solution Explorer в Студии. Но чтобы я мог открыть любой файл.
Как и что происходит в Solution Explorer я не знаю, поэтому "чтоб работало как там" мне не поможет ответить на вопрос.
Предположу. Есть клонированная репо. Она у тебя открыта в студии. Ты хочешь увидеть состояние всего проекта в определённый коммит. Так?
Пользуйся checkout. Как его обозвали гуеделы в твоей студии - найди сам. Обычно его прячут под "switch" (типа переключиться не ветку). Вот в этом чекауте просто выбираешь не имя ветки, а хэш (ид) коммита. Всё. Твой воркспейс будет содержать состояние проекта в этом коммите.
P.S. Почему кнопкожмяки не в состоянии использовать терминологию утилиты, вокруг которой они хреновертят свои
красоты я не знаю.
И чтобы мне не пришлось выгружать текущую версию проекта и загружать просматриваемый коммит.
Куда выгружать, откуда загружать - не понятно. Попроще давай. Не используй термины, которых не понимаешь.
И дальше что? Я ввёл это в консоли, он скопировал, теперь я должен открыть проект и смотреть в Студии? А если я не хочу закрывать текущий проект или его состояние?
А дальше ты морщишь мозг и читаешь что делает git archive. А если не хочешь закрывать - ну не закрывай. Кто ж тебя заставляет.
Раньше я тут спрашивал - а как загрузить сразу несколько версий проекта в разные папки? А мне ответили (вроде даже вы) - Гит не про это, он про хранение лишь одной версии.
Бля... Система контроля версий "про хранение одной версии". Перечитывай что пишешь, глаза болят читать.
Хочешь "загружать" разные версии в разные папки? Да хоть обзагружайся. Хочешь - полностью клонируй, хочешь - "неполный" клон (shallow), хочешь - архивом версию выдерай.
Ты во всех этих "версиях проекта" изменения делать хочешь? Или один раз посмотрел и стёр?
Т.е. открыть один и тот же проект в разных состояниях на двух параллельно запущенных IDE он тоже не позволяет.
Мнэ. Т.е. гит ещё и твоими IDE управлять должен? Бросай ты эту работу. Вали в америку, магазины обносить.
А как в такой системе смотреть сравнение файлов разных версий?
git diff
Пользуйся checkout. Как его обозвали гуеделы в твоей студии - найди сам. Обычно его прячут под "switch" (типа переключиться не ветку). Вот в этом чекауте просто выбираешь не имя ветки, а хэш (ид) коммита. Всё. Твой воркспейс будет содержать состояние проекта в этом коммите.
P.S. Почему кнопкожмяки не в состоянии использовать терминологию утилиты, вокруг которой они хреновертят свои красоты я не знаю.
Потому что я работаю над текущей задачей, и иногда нужно глянуть, что там было раньше. Не закрывая и не прерывая текущую задачу.
Т.е. Гит сам по себе нихрена не умеет, кроме как хранить историю изменений?
Совершенно верно. Ещё немного и у тебя наступит просветление (хотя нет, не наступит, для этого надо думать, прости). Это философия такая. Каждый занимается своим делом и не пытается объять необъятное. Утилитка делает одно дело, но делает его хорошо.
Я шатал такую философию...
Потому что я работаю над текущей задачей, и иногда нужно глянуть, что там было раньше. Не закрывая и не прерывая текущую задачу.
А что, в студии нет "Compare to" (или with) для всего проекта?
Вот так это выглядит в древнем эклипсе:
И что оно мне В КОНСОЛИ покажет, без подключенного какого-нибудь визуального движка?
Шайтан! Буковки покажет. Даже разными цветами. А если параметры подучить то можно ещё и под свои хотелки подстроить.
Если изменений много, то удобнее их, конечно, в IDE изучать.
смотреть сравнение файлов разных версий?
Не все будут довольны, но есть менюшка
https://github.com/gitextensions/gitextensions - как с VS2022, не знаю.
Для сравнения тоже есть софтик, но не бесплатный
Она то, что получает, представляет в более удобном виде, чем консольный Гит. МС смог, а Линус - наплевал. Потому что он ублюдок и эгоист, поэтому линускойды должны страдать. ))
Она то, что получает, представляет в более удобном виде, чем консольный Гит.
Ололёшенька, ты - тупой. А я - добрый. Повторю для тебя в очередной раз. Утилиты занимаются своим делом. Хочешь гуёвых красот - можешь настроить гит чтобы он использовал твой любимый diff. Тот же beyond compare. Если мозгов хватит, конечно.
Для сравнения какого угодно состояния используется git diff .. <файл или каталог>. Настроишь bc он тебе не в консоли покажет, а bc запустит. Если у тебя этот проект уже в IDE, пользуйся IDE, кто ж тебе мешает. Только ради бога, не пытайся сделать в своём IDE что-то вроде interactive rebase. Сломаешь всё.
Или хотя бы так.
Лапонька, а ты тупее, чем я думал. Ты хотя б посмотрел откуда
ты это картинку спёр? Со стековерфлоу. Как пример работы git diff с включенным diff-highlight.
Так что оказывается текстовый вывод diff-а тебя устраивает. Ой.
А почему ж в моём примере не было подсвеченных изменений? А патамушта там целиком строки менялись. Какая досада.
Она то, что получает, представляет в более удобном виде, чем консольный Гит.Ололёшенька, ты - тупой. А я - добрый. Повторю для тебя в очередной раз. Утилиты занимаются своим делом. Хочешь гуёвых красот - можешь настроить гит чтобы он использовал твой любимый diff. Тот же beyond compare. Если мозгов хватит, конечно.
Для сравнения какого угодно состояния используется git diff .. <файл или каталог>. Настроишь bc он тебе не в консоли покажет, а bc запустит. Если у тебя этот проект уже в IDE, пользуйся IDE, кто ж тебе мешает. Только ради бога, не пытайся сделать в своём IDE что-то вроде interactive rebase. Сломаешь всё.
Вы же тут топили за консоль, а кто не в консоли, тот типа тупой? Нельзя в гуе диффы показывать - отупеешь.
Или хотя бы так.Лапонька, а ты тупее, чем я думал. Ты хотя б посмотрел откуда ты это картинку спёр? Со стековерфлоу. Как пример работы git diff с включенным diff-highlight.
Так что оказывается текстовый вывод diff-а тебя устраивает. Ой.
А почему ж в моём примере не было подсвеченных изменений? А патамушта там целиком строки менялись. Какая досада.
Еретик, нельзя божественный ванильный гит осквернять всякими левыми надстройками! Если Линус посчитал, что это не надо, и не встроил, значит это идеал. А мимикрировать консоль под гуй - это становиться тупым по вашей идеологии.
Так-то я сказал "хотя бы", т.е. некоторая минималка, которую при первой возможности лучше заменю на вариант в той же Студии. Собственно, студийный вариант и использую. А раскрашивать консоль разномастными надстройками - это какие-то шизоидные полумеры. Если очевидно, что нужен гуй, надо делать гуй, а не пытаться и рыбку съесть, и в воду не влезть.