Доступен выпуск распределенной системы управления исходными текстами Git 2.29.0. Git является одной из самых популярных, надёжных и высокопроизводительных систем управления версиями, предоставляющей гибкие средства нелинейной разработки, базирующиеся на ответвлении и слиянии веток. Для обеспечения целостности истории и устойчивости к изменениям "задним числом" используются неявное хеширование всей предыдущей истории в каждом коммите, также возможно удостоверение цифровыми подписями разработчиков отдельных тегов и коммитов...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=53923
Читая чейнджлоги, мне каждый раз мерещится, что git из простой булки белого (или черного) хлеба превращается в трамвай. Надеюсь просто мерещится.
В какой момент git был простым? Довольно сложная VCS с момента рождения, просто он стал индустриальным стандартом.
Сложный он ровно до того момента, пока не проникнешься его философией. А дальше уже не понимаешь, как раньше жил до этого знакового знакомства. Потом, правда, приходится разбираться ещё с трактовками его фич разномастными хостингами, с их модно-молодёжными workflow's.
Имеется в виду что сначала нужно освоить vi и emacs и тогда уже гит будет казаться простым.
> пока не проникнешься его философией. А дальше уже не понимаешь, как раньше жилБешено плюсую.
Ну так про все что угодно можно сказать, haskel сложен пока не проникнешься его философией, многомерные пространства сложны пока не проникнешься их философией.Помню когда начал работать с git первые пол года перед каждым шагом делал tar czvf. До сих пор без заглядывания в заметки не смогу назвать команду для откатывания коммитов, путаю git clean и git reset. Пользуюсь гит с 2012 года.
> До сих пор без заглядывания в заметки не смогу назвать команду для откатывания коммитовЕсли ты заглядываешь в заметки и не можешь запомнить команды не потому, что тебе нужен аргумент в пользу того, что git слишком сложный, а по причине того, что на самом деле не получается, то я бы порекомендовал тебе выкинуть свои заметки и научится делать _всё_ при помощи команд branch и checkout.
Например, то о чём ты говоришь, можно сделать так:
git checkout <hash> # ставим HEAD на последний нужный коммит
git branch -D <branch> # удаляем ветку, которую "редактируем"
git branch <branch> # создаём её снова на текущем коммите
git checkout <branch> # переключаемся на неёТо есть, понятно, этими двумя командами обойтись не удастся -- тебе придётся использовать commit и add. Плюс что-нибудь нужно для того, чтобы писать внятную историю коммитов, тут я очень рекомендую rebase. Ограничься этими командами, и освой их. Сначала в каком-нибудь туториале, а потом попользуйся им недельку "в поле". Всякие там status/log и прочие заигнорь на старте, используй gitk или что-нибудь в этом роде вместо них
Чтобы в течение этой недели не спотыкаться о желание сделать что-нибудь, что не знаешь как сделать, пользуйся таким workflow:
1. с утра делаешь branch -b "today"
2. коммитишь так часто, как удастся, стараясь при этом писать внятные комментарии к тому, что сделано
3. откаты коммитов делаешь новыми коммитами
4. в течение дня не паришься об истории вовсе
5. вечером, за полчаса до окончания работы делаешь rebase, вынимая из today в master всё, что можно оформить в виде законченной работы, с логичными ортогональными коммитами и с красивыми комментами, а остальное складывая в ветку unfinished-work.Через неделю ты начнёшь оптимизировать этот workflow, и часть того вечернего rebase будешь выполнять в процессе работы -- возможно ты будешь вести несколько веток, возможно коммиты откатывать так, чтобы в today не оставалось бы их следов, возможно ещё что-то. А ещё через неделю ты свой собственный workflow придумаешь, который лучше всего подходит именно тебе. В процессе где-нибудь тебе надоест делать четыре команды, чтобы удалить коммит, и ты прочитаешь ман на git-reset и _поймёшь_ его в терминах команд checkout/branch, и будешь использовать как более короткий способ сделать то же самое.
Ах да, rebase сложно может быть понять по man'у, поэтому найти туториал, который даст тебе ещё и задачек, чтобы тут же попрактиковаться.
Если же тебе обязательно иметь аргумент в пользу сложности git, и поэтому ты лелеешь свои проблемы при использовании git, не позволяя им раствориться в опыте, то тут тебе ничто не поможет. Я б рекомендовал подумать об использовании другой vcs, которая не будет вызывать такого желания.
Как много текста ни о чем. У git сложный CLI. Чуть более предметно.Кейс 1:
Я случайно закомител лишний файл, но еще не отправил коммит на удаленный репозитарий. Как мне убрать лишний файл из последнего коммита?
Я могу только заглянуть в заметки и вытащить от туда команду: git reset 'HEAD@{1}', после которой я повторяю заново коммит без этого файла.
Кейс 2:
Я случайно добавил в индекс лишний файл, как его убрать из индекса не удалив. Я вот не помню, кажется через reset. Мне надо опять заглянуть в заметки.
> Я б рекомендовал подумать об использовании другой vcs, которая не будет вызывать такого желания.Так GIT стандарт, где не работал везде гит, я пользуюсь тем что есть.
Ну и раз я критикую, я хотел бы сказать какой CLI на мой взгляд был бы более понятным:git rm удалить файл с диска
git rmi удалить файл из индекса
git undo [N] - отменить последние N действий
git squash N - объединить последние N коммитов в один.
git squash 772e40f-fe89105 - объединить указанные коммиты в один.
> Ну и раз я критикую, я хотел бы сказать какой CLI на
> мой взгляд был бы более понятным:
> git rm удалить файл с диска
> git rmi удалить файл из индексаНапиши скрипт, проблем-то?
> git undo [N] - отменить последние N действий
Эмм... Это как? В список отменяемых действий включать переключение веток, например?
> git squash N - объединить последние N коммитов в один.
> git squash 772e40f-fe89105 - объединить указанные коммиты в один.git rebase тебе в помощь. Это более общий инструмент, который не только объединять умеет, но и разделять и переупорядочивать, но ты попробуй как-нибудь на досуге.
Я и пользуюсь rebase, в vi меняю строчки на squash нужных мне коммитов, только для этого мне приходится опять заглядывать в заметки, где я нахожу git rebase --interactive HEAD~N, потому что это запомнить нереально, CLI нисколько не помогает.GIT сложен, моя команда училась работе с ним пол года. Это слишком много для какой-то VCS. Если тул которым пользуешься каждый рабочий день требует столько времени для освоения, то значит он сложный.
Я не говорю что git плохой, но он сложный. Сложный как игра на гитаре, или gnu screen, или awk, sed, vi. Причем gnu screen и vi я умею пользоваться, и пользуюсь каждый день, но я никогда никому не будут рассказывать что они простые.
> Я и пользуюсь rebase, в vi меняю строчки на squash нужных мне коммитов, только для этого мне приходится опять заглядывать в заметки, где я нахожу git rebase --interactive HEAD~N, потому что это запомнить нереально, CLI нисколько не помогает.Прикинь, я впервые вижу команду "git rebase --interactive HEAD~N". Я даже не уверен, что она делает. То есть предполагаю, но всё же не уверен. Я обычно другим путём хожу: я создаю ветку и ребажу в неё, и когда мне это удастся, я потом уже с этой веткой делаю то, что сочту нужным. И при этом мне cli git'а нисколько не мешает. Истинно говорю тебе: выкини свои заметки, перечитай выше мой микромануал по освоению git'а с нуля, и воспользуйся им.
> GIT сложен, моя команда училась работе с ним пол года.
Твоя команда не умеет учиться. Это единственный вывод, который я могу сделать из сказанного. git осваивается за неделю в базовом варианте. За месяц до уровня, если не эксперта, то где-то рядом.
> Сложный как игра на гитаре, или gnu screen, или awk, sed, vi.
Ну ты сравнил. Это очень разные вещи.
Игра на гитаре требует сложных моторных навыков, в сочетании с развитием сенсорики, и это реально _годы_ ежедневной практики.
gnu screen требует знания нескольких кейбиндов, которые конечно же надо запомнить, но я чесслово никогда не парился с запоминанием, и разбирался по ходу дела каждый раз. Не проблема. Может быть там внутре запрятана куча возможностей, о которых я не знаю? Хз, я не парился даже выяснять, мне хватало нескольких кейбиндов для того, чтобы аттачиться/детачиться от терминалов, переключаться между ними и просматривать список. А что там ещё может быть? Разделение экрана между несколькими терминалами? Это ещё два кейбинда, да? Или три?
awk может быть проблемой, если раньше ты не сталкивался с языками схожего синтаксиса. Но после C это не проблема, надо лишь дать себе труд пролистать мануал, чтобы понимать что в языке есть.
sed сложно сказать -- я не пробовал с ним разбираться дальше команды s.
Сложность vi, на мой взгляд, сводится к тому, что пальцы на автомате заточены под emacs, vi же сталкиваясь с чем-нибудь типа C-c C-M-x (нажатыми на чистом автоматизме без грамма осознанности в действиях, ещё может быть до того, как цель этих нажатий была осознана) вваливается в какое-нибудь загадочное состояние, из которого вывести его может быть гораздо сложнее, чем просто выйти из vi. Даже элементарно понять, что произошло может быть сложно. Но это сложности _переучивания_, а не сложности научения. Проблемы с освоением, я подозреваю, такие же как и в emacs'е: без тысячи аддонов emacs гумно, а как из миллионов аддонов найти тысячу нужных -- это загадка, способ отсеять избранных от лошков.
git требует получаса с туториалом, неделю на закрепление усвоенного материала практикой, и потом ну, может быть, месяц на вырабатывание workflow, который заточен под тебя. Если речь идёт про команду, где workflow не совсем индивидуальный выбор (он должен быть совместим с тем, что использует команда) то после первой вводной недели, я бы скомпилировал список уже отточенных workflow и вынес бы их на обсуждение команде, с тем чтобы команда могла бы выбрать что-то, к чему затем подстраиваться. Ежели хочется реально заделаться экспертом, то через месяцок стоит почитать о том, что именно git хранит на диске и, может быть, для закрепления написать собственный нано-git.
> Игра на гитаре требует сложных моторных навыков, в сочетании с развитием сенсорики, и это реально _годы_ ежедневной практики.А можно знать три аккорда и играть боем.
> gnu screen
Использую как terminal multiplexer, наверное не больше 20 комбинаций.
С другой стороны я использую git каждый день и пользуюсь обычно менее 20 сочетаний команд+ключи. Я их запомнил так же как запомнил такой шаблон: find . -name "*.xml" ! -path "*/build/*" -exec grep -HEn "word" {} \;
awk я не помню, я изучал язык awk но забыл, только через доку смогу сделать что-то сложное.
> git требует получаса с туториалом, неделю на закрепление усвоенного материала практикой
Был 2012 год, первый месяц команда могла использовать только git stash/pop, git commit/push. Вся работа шла по workflow svn в одном общем бранче. На второй месяц все уже начали использовать бранчи но какой либо помощи никто не мог оказать, можно было запутаться в merge, rebase и произвольных командах из инета так что в истории бранча возникало какой-то путаный ахтунг слияний. Я пол года пользовался tar, перед любым rebase или merge.
Если сравнивать с svn то git намного сложнее.
Я вспомнил какой был svn workflow:git stash
git pull
git pop
<!- резолвинг конфликтов ->
git commit
git push
> Я вспомнил какой был svn workflow:
> git stash
> git pull
> git pop
> <!- резолвинг конфликтов ->
> git commit
> git pushууу... Откуда вы такой взяли? Какой-то "гений" придумал, а вы потом мучались.
Коллективно придумали за один день, в первый день был только один вопрос, как свои изменения залить на git когда есть конфликт?
>> Игра на гитаре требует сложных моторных навыков, в сочетании с развитием сенсорики, и это реально _годы_ ежедневной практики.
> А можно знать три аккорда и играть боем.Один член тут моторные навыки. Надо пальцами попадать по ладам в нужных местах, и медиатор держать так, чтобы не вываливался из пальцев. И да, баррэ -- ппц как сложно, когда не умеешь держать палец прямым и в нужном месте, вне зависимости от положения кисти.
> Был 2012 год, первый месяц команда могла использовать только git stash/pop, git commit/push. Вся работа шла по workflow svn в одном общем бранче. На второй месяц все уже начали использовать бранчи но какой либо помощи никто не мог оказать, можно было запутаться в merge, rebase и произвольных командах из инета так что в истории бранча возникало какой-то путаный ахтунг слияний. Я пол года пользовался tar, перед любым rebase или merge.
Это как раз свидетельство того, что философией не прониклись. Потому что команда из скрипт-киддисов, и не одного вдумчивого человека. Копировать команды из инета... Не, я всё понимаю, сам этим пользуюсь иногда, но ёмаё: я допустим не копирую команды из инета, если я не понимаю как они составлены. Если я копирую, то лишь как способ избавиться от перерывания документации, которую я не помню. Скажем, с ffpmeg я никогда не помню, как там сделать то или это, перерывать man в поисках того, как там нужные фильтры накладываются мне лень, поэтому я ищу и копирую. Но я понимаю команду найденную в интернете, когда я её читаю. Если бы у меня не было бы интернета, я бы залез в доку, нашёл бы то, что надо, и составил бы эту команду сам -- не проблема, просто это дольше выходит.
И да, полгода пользоваться tar? Я первую неделю-две имел две копии репа: в одной я работал, в другую потом pull'ом вытягивал то, что не хотелось случайно потерять. Это позволяло в случае чего, вытащить в другой реп ветку, после чего заниматься чем угодно с этим репом, и если всё необратимо испортилось, то можно удалить и склонировать заново. Через неделю я увидел отсутствие необходимости таких бекапов, потому как после факапа всегда можно выкрутиться на одном репе: коммиты из git никуда не деваются, они все там, по-крайней мере до сборки мусора. Потерянную последовательность коммитов всегда можно найти обратно, если знать хеш. Нет никаких проблем этот хеш скинуть в файл (или даже скопипастить в *scratch* emacs'а, чтобы не плодить файлов) и вернутся к нему потом через git checkout. Или ещё проще, можно повесить на этот коммит тег или ветку создать на нём новую, чтобы потом искать его не по хешу, а по символическому имени. С тегами и ветками лишь одна проблема -- они накапливаются, но это опять же не проблема, их можно подчищать иногда.
Дай я угадаю, вам git насаживали в приказном порядке сверху, не спрашивая вашего мнения? И никому это особенно было не нужно, и всем эти проблемы было удобны, потому что задержки в работе всегда можно было свалить на git, то есть на начальство, которое приказало переходить на git. И поэтому никто не парился потратить хотя бы полчаса на то, чтобы разобраться с git, и все продолжали тыкаться рандомными какими-то способами, вплоть до того, что вручную выполняли работу git, а commit использовали только для того, чтобы эту работу зафиксировать в git. Так?
> Дай я угадаю, вам git насаживали в приказном порядке сверху.Почти так и было, лично мне тогда git был не нужен, svn хватало. Я надеялся что кто-то разберется и устроит мастер класс передав знания коллективу, но нет. И да, периодически я выделял пол часа я на чтение progit пытаясь разобраться с той или иной темой.
Я искренне не понимаю почему какая-то vcs от меня требовала стольких усилий, и почему был выбран git, чем он лучше svn, hg, bazar, etc. Тот кто внедрял на момент внедрения "знал" что git каким-то магическим способом решает проблемы бранчинга и мержа конфликтов, но как именно он их решает объяснить не мог.
> Я искренне не понимаю почему какая-то vcs от меня требовала стольких усилий,Потому что ты причину ищешь снаружи своей психики, хотя она прячется внутри.
> почему был выбран git, чем он лучше svn, hg, bazar, etc. Тот кто внедрял на момент внедрения "знал" что git каким-то магическим способом решает проблемы бранчинга и мержа конфликтов, но как именно он их решает объяснить не мог.
Ты сам ответил на свой же вопрос. Он выбрал git потому что где-то прочитал, что git решает проблемы бранчинга и мерджа конфликтов, но при этом решил что не его дело разбираться в том, как это работает -- не ему же мерджить конфликты?, -- что его задача спустить циркуляр о переходе на git, и всё автоматически станет хорошо. Очередное чмо которое лезло по карьере ровно до той ступеньки, где квалификации оказалось недостаточно. Ему б курсы менеджмента закончить, хотя бы краткосрочные какие, чтобы азы освоить и совсем уж позорных ошибок не совершать. Но технари снобы в принципе, и любое не технарское знание воспринимают как недостойное их.
> Потому что ты причину ищешь снаружи своей психики, хотя она прячется внутри.Моя психика мне говорит что мне было тогда не интересно и до сих пор не интересно изучать VCS и его внутреннее устройство. В нормальной VCS я бы использовал команду откатить изменения, а не сбросить/переустановить указатель головы на одну позицию назад в цепочке коммитов.
Хех, я только сейчас понял что reset как раз используется в смысле "переустановить/переназначить".
>> Я б рекомендовал подумать об использовании другой vcs, которая не будет вызывать такого желания.
> Так GIT стандарт, где не работал везде гит, я пользуюсь тем что
> есть.Если ситуация такова, то значит надо одолевать свои психологические причины не справляться с git и искать способ справляться. git -- это просто, если тебе сложно, значит что-то ты делаешь не так.
> Если ситуация такова, то значит надо одолевать свои психологические причины не справляться с git и искать способ справляться.Рекомендуете начать с аутотренинга перед зеркалом?
Это уж кому что помогает.
Все твои кейсы делает, очевидно, `git reset`git reset --hard HEAD~1
Опция --hard восстанавливает состояние ветки и дерева на указанный коммит, в частности ** удалит все локальные изменения ** в индексе. Здесь нужно понимать как git адресует относительные коммиты, HEAD - текущий, HEAD~N - N коммитов назад. Если нужно удалить файл из коммита с другими изменениями, то
git reset --soft HEAD~1
Отказывает состояние ветки на указанный коммит, а отброшенные изменения из ветки загружает в текущий stage не трогая дерево. Далее его можно редактировать как обычный stage. В частности, чтобы вынуть файл из stage, т.е. твой кейс 2, опять помогает reset
git reset path/to/my/file
Если туго с памятью и вообще с головой, то можно сделать алиасы с различаемыми для тебя лично именами. Какая бы у тебя не была VCS, всё равно нужно знать как она адресует коммиты и что запускать. Не работаешь с Git 2012 года, а работаешь с каким-то другим инструментом совсем иногда что-то делая c Git. В таком случае всегда приходится подгружать кеш, для любого минорного инструмента, чтобы вспомнить с чего начать. Хорошо если инструмент сам умеет давать подсказку, например, если запустить его без аргументов. Git и svn показывают какие команды у них есть и если этого мало, то нет ничего страшного в своей шпаргалке. Справка Git не везде хороша, но не настолько чтобы устраивать на этот счёт истерики и делать этот фактор решающим в выборе VCS.
Не нужно возводить личные проблемы до объективных технических, истеричкам нет места в инженерии.
UPD: Прочитал выше как в своём варианте предоагаешь адресовать коммиты, т.е. [N], это ничем не лучше и никак не понятнее по сравнению с адресацией в Git.
UPD: Если нужно squash-нуть последние N коммитов и посмотреть что получилось перед коммитом, то кроме rebase тоже можно воспользоваться второй формой reset-a, т.е.
git reset --soft HEAD~N
Кстати я тут ошибся указав git reset 'HEAD@{1}', в моих заметках сказано что это делает UNDO для UNDO, видно из-за простоты git этого никто пока не заметил.А UNDO коммита как написал товарищ выше: git reset --soft HEAD~
Прямо очень интуитивно, я как вижу git reset --soft HEAD~ так сразу понимаю что это откатывает коммит, проще пареной репы.
Это абсолютная чушь, Git простой как топор. Проще SVN, HG и многих других VCS. Потому у меня обратный вопрос - почему важные архитектурные изменения (развитие протокола, поддержка нескольких хешей и т.д.) происходят медленно, но коммитов стабильно не мало. Я, например, за 627 своих типичных изменений по объёму мог бы почти полностью переписать такой пакет и значительно доработать архитектурно.
> Это абсолютная чушь, Git простой как топор.Я не согласен!
Ну тогда: Git прост как бензопила!
>Проще SVN, HGКакой наброс. Документация по гиту такая кхмм.. подробная, что иногда выть хочется.
По моиму опыту обучить гиту НЕПРОГРАММИСТА (чтобы он ничего не ломал ничего и осозновал что делает) на порядки сложнее чем тот же hg. в нем много лишних абстракций торчат наружу, которые могли бы быть скрыты и интерфейс стал бы проще.
> Какой наброс. Документация по гиту такая кхмм.. подробная, что иногда выть хочется.поскольку гит представляет собой не человеческую программу, исполняющую ровно одну задачу хорошо, как большинство нормальных vcs, а нагромождение костылей и подпорок вокруг совершенно бредовой задачи "порежьте помельче, перепошлите в рассылку", включая и попытки приспособить ее решение к промышленной разработке вместо использования более подходящих - такой документации никогда и не будет - потому что сначала нужно заставить тебя изучить и принять совершенно нечеловеческий workflow, потом описать этапы его автоматизации, "а теперь забудьте все, что вам рассказывали, и давайте попробуем эту мусорку приспособить к реальным нашим задачам - смотрите, смотрите - какие отличные костылики к ней для этого приладили".
> По моиму опыту обучить гиту НЕПРОГРАММИСТА (чтобы он ничего не ломал ничего
> и осозновал что делает) на порядки сложнее чем тот же hg.как будто программисты осознают что делают, а не вызубрили git clone /git commit /git push ?
Следующее поколение и этого уметь не будет - "clone me on github", и всех дел.Давай ты скопируешь из этой новости все примеры, без объяснений, и попросишь любого программиста рассказать тебе, что они делают, не подглядывая в гугль?
Или даже проще - для экономии времени - попроси объяснить тебе смысл и назначение git rev-parse
Думаю, процентов 90 вообще не знают толком, что эта команда делает и как ей пользоваться - хотя и имеют под рукой копипасту со стека, решающую какую-то их частную задачу.> в нем много лишних абстракций торчат наружу, которые могли бы быть
это не абстракции, это детали внутреннего механизма. Совершенно ненужные, да. Просто потому что механизм выполняет совершенно ненужную работу. А та что на самом деле нужна в большинстве случаев - сделана костылями вокруг него.
Вы транслируете мнение совершенно не разбирающегося в архитектурах VCS. С желаниями от "configurations management" и игнорированием всего остального.
в Git примерно всего две простых абстракции - это ADG и индекс. В SVN одна простая с линеной историей, одна мозговыносящая связанная с ветками, тэгами и мержами директорий в директории (не видел как пользователи копируют trunk в NNN GiB в trunk?), и ещё некоторое кол-во поменьше. В Hg одних веток только несколько штук, в плане неконсистентности это самая yблюдочная VCS.Документации к Git больше если сравнивать c, например, svn, просто потому что в Git значильно больше функциональности. Однако это не означает что для работы нужно знать всё и всем пользоваться. Чтобы странный пользователь ничего плохого не делал есть прекоммитные хуки, причём ими пользуются во всех VCS для ограничения деятельности альтернативно одарённых персонажей.
> Git простой как топорСудя по непрязни к Гиту — ни один его критик к разработке не имеет никакого отношения.
Все просто: без контроля версий жить нельзя. ДЕНЬГИ!!! Затраты на разработку растут на порядок!!!
Бабушиным внукам такие вещи по%уй, они не оплачивают команду из своего кармана и уверены, что бабушкина пенсия растет на дереве.
Мне пришлось попробовать всё и Гит — САМЫЙ ВЫГОДНЫЙ вариант. ТОЧКА!!!
>> Git простой как топор
> Судя по непрязни к Гиту — ни один его критик к разработке
> не имеет никакого отношения.
> Все просто: без контроля версий жить нельзя. ДЕНЬГИ!!! Затраты на разработку растут
> на порядок!!!
> Бабушиным внукам такие вещи по%уй, они не оплачивают команду из своего кармана
> и уверены, что бабушкина пенсия растет на дереве.
> Мне пришлось попробовать всё и Гит — САМЫЙ ВЫГОДНЫЙ вариант. ТОЧКА!!!Продолжая заочную дискуссию с безработными энтузиастами открытых решений — JIRA. Без нее тоже никак.
> JIRA. Без нее тоже никакочень даже как, потому что есть Redmine.
>> очень даже как, потому что есть Redmine.Редкостная чушь сей Redmine
>>> очень даже как, потому что есть Redmine.
> Редкостная чушь сей RedmineНа вкус и цвет все люди разные. По крайне мере, за него платить не надо.
>>>> очень даже как, потому что есть Redmine.
>> Редкостная чушь сей Redmine
> На вкус и цвет все люди разные. По крайне мере, за него
> платить не надо.Ещё как надо! :) Каким это бесплатными образом вы намерены обеспечить группе доступ к серверу??? :)
Хостинг/колокейшн либо канал до домашнего сервера стоят денюжек! :) И так это заметных :)
>>>>> очень даже как, потому что есть Redmine.
>>> Редкостная чушь сей Redmine
>> На вкус и цвет все люди разные. По крайне мере, за него
>> платить не надо.
> Ещё как надо! :) Каким это бесплатными образом вы намерены обеспечить
> группе доступ к серверу??? :)
> Хостинг/колокейшн либо канал до домашнего сервера стоят денюжек! :) И так это
> заметных :)Но за саму систему платить не надо, в отличие от Jira.
> Но за саму систему платить не надо, в отличие от Jira.А админить? Пушкин будет? Самому доки курить и ночей не спать? +1 чел. 40 тыщ? А он хочет 70. Пенсионный, бла-бла-бла. Вот Jira уже и дешевле. Открывай контору, окунайся в жизнь, плати зарплаты :) У всех — детки :) И начнешь смотреть на корпоративные сервисы другими глазами :) :) :)
>> Но за саму систему платить не надо, в отличие от Jira.
> А админить? Пушкин будет? Самому доки курить и ночей не спать? +1
> чел. 40 тыщ? А он хочет 70. Пенсионный, бла-бла-бла. Вот Jira
> уже и дешевле. Открывай контору, окунайся в жизнь, плати зарплаты :)
> У всех — детки :) И начнешь смотреть на корпоративные сервисы
> другими глазами :) :) :)Я разраб, а не бизнесмен, в буй мне не впилась своя контора с ее гемором. И да, админ нужен не только для редмайна.
> JIRA. Без нее тоже никак.Редкое дерьмо.
> Судя по непрязни к Гиту — ни один его критик к разработке
> не имеет никакого отношения.утипупсичек, ну конечно же.
> Все просто: без контроля версий жить нельзя.Все просто: кроме тебя, вчерародившегося, тут есть еще, хотя и в очень небольшом количестве, люди, использовавшие в своей работе vcsы еще когда ни тебя, ни уродства автоматизирующего неумение одного пингвиноида в коллективную разработку, в помине не было.
ВНЕЗАПНО, гит не является ни единственным, ни первым, ни хотя бы хорошим средством контроля версий.
> Бабушиным внукам такие вещи по%уй, они не оплачивают команду из своего кармана
О, так мсье - инвестор? Из своего кармана хоть что оплачивает? Или даже за свет платит бабушка, пока он сидит "на удаленке", как обычно?
> Мне пришлось попробовать всё и Гит — САМЫЙ ВЫГОДНЫЙ вариант. ТОЧКА!!!
Попробуй еще легкие наркотики. А то судя по количеству заглавных букв в твоей писанине, необратимые изменения уже начались.
Ну перепиши и доработай, все тебе будут благодарны и может даже денег отсыплют
Если тут есть люди, имеющие отношение к психологии или преподаванию (чего-либо, не важно) --- поясните, пожалуйста, вероятную мотивацию жмыхателей на значки +/- к комментариям 3.26 и 3.14. Спасибо.
Увидели что там уже есть +/- и добавили свой чтобы не выделяться из толпы
вхуярил тебе минус, а у тебя стоял там плюс, наверное, доморощенный ты психолог, это потому что я хочу выделиться из толпы?
В 3.26 -- за вводный негативный заряд "Это абсолютная чушь". Далее комментарий дельный, но не все дочитали.
В 3.14 вывод в споре о вкусах навязывается заметно мягче ("Сложный он ровно до того момента, пока не проникнешься его философией"), но оратор напрасно попытался обобщить субъективный опыт. Люди разные, одним таблицу умножения проще зазубрить, другим каждый раз заново в уме столбиком складывать.
> В какой момент git был простым? Довольно сложная VCS с момента рожденияЭто в каком же месте он сложный? Или не осилил https://git-scm.com/book/ru/v2?
конечно мерещится - он всегда был троллейбусом из буханки, причем с квадратными колесами. Как он может превратиться в трамвай?!
Хэши в постквантумную эпоху пострадают? А то планируют на 5 лет, а дальше хоть трава не расти.
> Хэши в постквантумную эпоху пострадают?Вся современная криптография пострадает. Факторизация со скоростью умножения - это вам не шутки!
> А то планируют на 5 лет
А вы уже запаслись пророчеством Нострадамуса когда она настанет, эпоха энта? Отсыпите?
Ну вон каждый день заявляют о квантум супремасэ, и вроде довольно близко продвинулись уже. Скоро придём к тому, что вся "криптография" будет на запутанных частицах (вроде там сбер что-то такое делал ГОДА 4 НАЗАД), где вмешательство будет исключено. Изначально выбрать sha1 было примерно как выбрать des, а теперь поменять на 3des,
Еще далеко. Если корпорации и смогут, то ломать чужое это уголовка. Опасно для бизнеса. У спецслужб и так все есть. Надо ждать массовый сектор, а его пока в планах не видно.
> У спецслужб и так все естьага, два раза есть.
[sarcasm]
и у сбера также
А обработка персональных данных без согласия - это что? Я вот банку передал давным давно бумагу, что отзываю согласие на обработку персональных данных, и требую произвести их уничтожение, а также всех их копий у всех контрагентов. И даже подписи работников банка на своём экземпляре вытребовал.Однако до сих пор СМС приходят "Для вас предварительно одобрен кредит, такая-то ставка, вы его можете взять, просто заявившись в отделение", хотя я сроду кредитов никогда не брал.
Кавантовые компы угроза для ассимтричной крипты, но не для хэшей и симметричной крипты.
Когда Линус начнал гит кажется sha2 ещё не было.
sha2-256 ещё удобен тем что аппаратно есть в райзенах, впрочем sha1 тоже есть.
А вот sha2-512 и sha3 аппратно пока нет.
>> Хэши в постквантумную эпоху пострадают?
> Вся современная криптография пострадает. Факторизация со скоростью умножения - это вам
> не шутки!Факторизация чего? Вы типа думаете, что поля Галуа - это по которым гулял некий французский дяденька?
> Факторизация чего?Больших целых.
А при чем тут SHA в любой ипостаси? Вы с RSA не перепутали?А для эллиптических кривых уже квантовые алгоритмы есть?
> А при чем тут SHA в любой ипостаси?При том. что алгоритм Гровера. С SHA-2 тут, насколько я знаю, "все не так однозначно" (ц).
> А для эллиптических кривых уже квантовые алгоритмы есть?
В смысле? Тут тот же алгоритм Шора может быть использован.
насколько я курил вопрос - уже есть, однако появилась криптография на изогениях, но все в зародышевым состоянии
не особо. Может быть, когда-нибудь придется увеличить размер хэша например до 384 бит, но придумывать новые алгоритмы нет нужды. От квантовых вычислений страдает только асимметричное шифрование
Я слышал оценки в районе 4096 для RSA. И то, это скорее потому, что теоретическая база для эффективного квантового подбора таких ключей пока не существует.
Алгоритм Гровера только квадратичное ускорение даёт, по сравнению с экспоненциальным для Шора.
о, крутая вещь. а есть hg-репозиторий, где можно его скачать?
Могу дать вместе с unzip.arj. :)
у меня есть ha.lha и lha.ha, оба смешные
А я до сих пор пользуюсь SubVersion и всегда с улыбкой смотрю на очередные новости про гит и хг, и про ребейспроблемы
Обычно с улыбкой смотрят на болванчиков которые без интернета не могут ни коммит, ни лог сделать, а чтобы переключиться на другую задачу им приходится изменённые файлы двигать. А на тех кто крупное изменение льёт одним коммитом, потому что rebase чтобы разбить его на топики не умеет, смотрят без улыбки и просто указывают им на дверь.
Какую дверь, что ты несешь такое вообще ?
На дверь из IT конторы очевидно, потому что профнепригодность.
> На дверь из IT конторы очевидно, потому что профнепригодность.А у нас в ТИУ на "Информационные системы и технология" кроме меня даже о гите и краем уха не слыхали, а уж тем более о всяких rebase и СКВ вообще подавно.
>> На дверь из IT конторы очевидно, потому что профнепригодность.
> А у нас в ТИУ на "Информационные системы и технология" кроме меня
> даже о гите и краем уха не слыхали, а уж тем
> более о всяких rebase и СКВ вообще подавно.И не только студенты, но и преподы
Смешно конечно такие писульки читать, профнепригодность из-за того что коммиты большие?Походу у вас какие-то спартанские порядки в конторе. Все пишут по-разному, в том числе и в опер сорсе коммиты в 2 десятка файлов иногда встречаются. Обычно это вопрос договорённости в команде.
До сих пор смешно с такого детского максимализма, ну до поделать, хорошо что я не в такой команде)
При чём тут максимализм? Факт 1 - есть code review. Факт 2 - мегакоммит невозможно качественно поревьюить. Поэтому в отличие от профпригодности ревьюера такой коммит либо идёт в прод непоревьюеным, либо заворачивается. В первом случае это рано или поздно ломает прод, во втором разработчик не выполняет свою прямую работу. В результате в обоих случаях отправляется в дворники. Ну либо учится git и rebase и делает ветки из маленьких, атомарных, легко обозримых коммитов.
Человек что-то лабает на коленке и что такое промышленное программирование не понимает. Бывает, убеждать бесполезно пока сам не побьётся.
Ох уж это российская любовь к ребейзам. Чем вам просто мерджить-то не нравится? "Не аккуратненько"? =/
Мёржи превращают историю в нечитабельное месиво.Ребейзы (при правильном использовании) делают красивую линеаризованную историю, где каждый коммит в истории на своём месте и сразу понятно что и когда кто делал (точнее заканчивал делать).
Разумеется там где разработчики не пишут описания изменений и смешивают пачку несвязных изменений в один коммит - мёрж / не мёрж уже ничего не поменяет.
мержить можно и сквошем.
> Мёржи превращают историю в нечитабельное месиво.Это не мёрджи. Это неотлаженный воркфлоу.
Чтобы вмержить ветку, её нужно сначала отребейзить (совершенно не обязательно на свежий master) и причесать - фиксы опечаток влить в те коммиты где опечатки были сделаны, большие коммиты разбить и т.д.
За ребайсе надо сразу в торец
Такое говорили 15 лет назад неучи не видевшие и не хотевшие видеть нормальные VCS. Сейчас причесать ветку перед мержем - обязательное правило. Ребейз ветки на master (т.е. с перемещением корня) - дело вкуса, но по мне так нелинейная история допустима только в совсем маленьких проектах, иначе (когда есть > 5 параллельных ветвей) читать её невозможно.
В торец надо тем, кто отправляет на ревью всю свою помойку коммитов, образовавшуюся естественным образом в ходе работы. Ревьюера не волнует, какие ты ошибки сделал в ходе работы и как их исправил. Его интересует конечный результат.
> В торец надо тем, кто отправляет на ревью всю свою помойку коммитов,
> образовавшуюся естественным образом в ходе работы. Ревьюера не волнует, какие ты
> ошибки сделал в ходе работы и как их исправил. Его интересует
> конечный результат.конечный результат в случае не двустрочного исправления он оценить не сможет в принципе - тот слишком велик, чтобы вот так просто разобраться в его логике. История нужна не для шаманского танца ревьюера, а чтобы потом другие люди могли разобраться, откуда в коде что взялось, и, может быть, найти ломающее все исправление - а не получить в результате бисекта "task1235660" одним куском или десятью - от этого легче не станет.
К чему это приводит - мы прекрасненько видим в lkml (я все еще с изюмлением наблюдаю процесс пертурбаций в ntfs3 - теперь уже со стороны, поскольку "уменявсеработает" и лучше уже не станет - именно потому что историю я не вижу и не могу нормально контролировать изменения). Когда ревью на 90% сводятся к придиркам к оформлению и исправлению colour на color. Потому что это единственное, что ревьюеры видят в пятистрочной лапше, на которую порезан действительно большой цельный кусок кода. А критические баги обнаруживаются совсем другими людьми, которые таки взяли проект как целое и начали тестировать - ибо других способов проверки неоднострочного кода в природе нет.
Ну и дурак.
просто ты замшелый пенек. какой нахер subversion? брось уже каку!
Zip с циферками еще круче, его все даже github использует, аж скулы от улыбки сводит.
> ребейспроблемыА что именно Вы предпринимаете в svn, когда надо свести две своих ветки -- например, в основной были мелкие исправления, которые местами пересекаются с текущей разработкой (возможно, где-то и конфликтуют)?
Я просто немного помню, как это выглядело с cvs. С гитом это хотя бы проблемы (в переводе на русский -- задачи), и проблемы решаемые, а не тот кромешный ужас, даже когда сервер рядом по локалке доступен.
Без server-side (священо)действий --- никак. Лочим доступ (когда на запись, а когда и вообще) на час--день--неделю, сливаем backup в сторонку, говорим "ой, мама" и трудимся. После открытия доступа слушаем матюки и угрозы, вжимаем голову в плечи, лочим доступ и пытаемся поправить то, что наворотили. Иногда приходится повторять всё несколько раз. Но вера в святой backup нас поддерживает.
> А что именно Вы предпринимаете в svn, когда надо свести две своих
> веткиmerge нужных изменений
> -- например, в основной были мелкие исправления, которые местами пересекаются
> с текущей разработкой (возможно, где-то и конфликтуют)?и - чем ТУТ поможет rebase? Сломает ветку? Спасибо, я об этом как раз мечтаю.
Это cherry-pick, и в svn это делает именно merge.
> Я просто немного помню, как это выглядело с cvs. С гитом
в cvs точно так же.
> это хотя бы проблемы (в переводе на русский -- задачи), и
> проблемы решаемые, а не тот кромешный ужас, даже когда сервер рядомэто не проблемы. Проблема что волшебства нет, и тебе придется изучать изменившийся код и заново изобретать свои правки под новую версию. Хоть с ребейзом, хоть с мержем, хоть с новая-папка-22
Проблема cvs/svn - когда проект НЕ ТВОЙ и ты не планируешь/не можешь в него возвращать правки. Потому что ты не можешь вести СВОЮ историю изменений параллельно - ни в виде ветки, ни в каком еще, даже в виде "новая папа" не можешь - случайный svn up все испортит.
(svk, но это тот еще костыль)Забавно, что как раз git порожден средой, которая категорически враждебна к подобным применениям.
Недалёким неведомо что svn up при наличии незакоммиченных изменений в working copy делает ни что иное как ребейз [этих изменений на новый head].
> Недалёким неведомо что svn up при наличии незакоммиченных изменений в working copy
> делает ни что иное как ребейз [этих изменений на новый head].это мерж. И более того, явный мерж делается точно так же - через working copy.
Недал...неосиляторам distributed-vcs (для этого необязательно быть недалеким, может и просто повезло, как леночке-проститутке) неведомо, что rebase - это перенос _истории_, а не всех отличий пачкой без разбора. Эгмх...подделка истории, тоись ;-)
Смысла в нем, чаще всего, никакого, просто у тех макак "здесь так принято".Реальную проблему с svn я уже попытался разжевать: вот лежит у тебя в working copy ДВА разных набора патчей (пусть даже история тебе нахрен не нужна). А может и 22 (у меня в freebsd ports и больше может быть, а история в общем-то не нужна) Не закомичены и не будут - это не твой репо. up их ломает к хренам. Патчи нетривиальные, и чинить их надо строго по одному, и не факт что сможешь оба починить в принципе - возможно, придется радоваться что хоть один починишь. А может изменения апстрима совсем критичные, и надо собрать апстримную версию любой ценой прямо сейчас, а потом уже свое чинить. Что делать будиииим - новаяпапка21, да?
Мелкая проблема - что ты мог просто забыть о своих патчах в working tree, сделать up, и получить поломанное дерево. Теперь ты ни откатить этот up не можешь, ни сохранить свои правки в сторонку, чтобы разобраться с ними как-нибудь потом - состояние до up и кривомержа нигде не сохранено.
git или hg просто дадут тебе по рукам при попытке это сделать. И потребуют явно указать, что предпринять с несохраненными изменениями. Ничто, разумеется, не мешало снабдить подобной проверкой и svn/cvs, но их писали давно, проекты были маленькими, всем было лень напрягаться.
> что rebase - это перенос _истории_, а не всех отличий пачкой без разбора. Эгмх...подделка истории, тоись ;-)А нет никакой разницы разбиты изменения на отдельные коммиты или не разбиты, и вообще оформлены в виде коммитов или нет - в ваших терминах это в любом случае "подделка". С практической стороны в любом случае может произойти изменение в чужом коде которое сломает твоё изменение или тихо изменит его поведение, даже не вызвав конфликта.
> С практической стороны в любом случае может произойти изменение в чужом коде которое сломает твоё
> изменениене может - оно где-то в origin/чтототам происходит в терминах гита.
Твои комиты _никуда_ не денутся, и даже попортить автомагическим мержем НЕ закомиченое тебе не дадут. (Закомиченное - дадут, полагая что это именно то что ты хотел, но ты всегда можешь вернуть исходное состояние, это история.)А в svn/cvs ничего из этого нет, и для работы с _чужими_ проектами это действительно проблема.
Подделка происходит при rebase. Поинтересуйся на досуге, что при этом на самом деле происходит с историей.
> А нет никакой разницыесть.
> в ваших терминах это в любом случае "подделка".
нет. Подделка - это именно подделка истории, когда изменения придуманные и реализованные при одном (одних, возможно - разных) состоянии кодовой базы - создаются кодом vcs заново, и выглядят в логе как сделанные при совсем другом ее состоянии. Так работает rebase - создавая фейковую историю вместо настоящей (поверх нее - настоящая на самом деле остается тоже, но ты ее не увидишь, а потом gc ее окончательно зачистит).
А что вы там нафантазировали - к моим терминам не имеет ни малейшего отношения.
Настоящую историю модификаций кода сохраняет merge. Но в той парадигме, для которой придуман и предназначен гит - твоя история никому не нужна, пришлите патчи в рассылку, порезав помельче.
Поскольку там на самом деле не совместная разработка, а поклонение божкам.Для именно совместной гит одна из самых неподходящих технологий. Но модные-современные ничего другого просто не умеют.
> ребейспроблемынапример какие? А то вот уже 7 лет пользуюсь гитом и что-то не припомню проблем с rebase.
Перешел, кстати, с svn.
Какой-то фольклер вместо вменяемого ченжлога, еще и испорчено корявым переводом.
> А я до сих пор пользуюсь SubVersionсочувствую бро
> и всегда с улыбкой смотрю
те, кто работал с svn в цирке больше не смеются
> и про ребейспроблемы
в svn их просто нет. Нет человека - нет проблем ( с )
дебильная логика. sha3 стандарт. не sha2, не sha1, не md5. sha3! нафига использовать старье?
И sha256 тоже стандарт, только предыдущий.
те использоваться уже не должен ибо выявлены проблемы в sha1 и sha2. использовать нужно sha3
А ну-ка, на бис, какие ПРОБЛЕМЫ выявлены в SHA2?
недостаточная стойкость к коллизиям очевидно
Пруфлинк, пожалуйста.В SHA2 (а sha256 - это тоже sha2) пока что не найдено даже теоретических уязвимостей. SHA3 принимали не потому, что SHA2 был сломан, а потому, что SHA2 построен по принципу, похожему на SHA1 (который сейчас условно сломан). Опасаясь ВОЗМОЖНОГО ПОЯВЛЕНИЯ уязвимостей в SHA2, было решено принять параллельно стандарт SHA3, чтобы был алгоритм, не похожий на SHA2. Потому, кстати, победил Keccak, а не Blake/Blake2, которые в софтварной реализации заметно быстрее.
В марте 2008 года индийские исследователи Сомитра Кумар Санадия и Палаш Саркар опубликовали найденные ими коллизии для 22 итераций SHA-256 и SHA-512.В сентябре того же года они представили метод конструирования коллизий для усечённых вариантов SHA-2 (21 итерация). Позднее были найдены методы конструирования коллизий для 31 итерации SHA-256 и для 27 итераций SHA-512.
Сейчас тебе скажут что это другое
> sha256 тоже стандартнет, sha256 это sha2 с увеличеным размером хэша
Это стандарт NiStA.
А как бы это сделать pull не для текущей ветки, но и не переключаясь на ветку которую стягиваешь. Например чтобы посмотреть в ней что менялось и подмержить
напиши скрипт который будет переключатся, делать pull и переключаться назад.
а вообще fetch -a
Как всегда всё гениальное просто... просто проскочило мимо меня) Спасибо
Через гитлаб например мышкой.
Чушь написал. Думал речь про пулл реквест, а не пулл.
Мб тебе нужен git fetch
>>Изначально планировалось использовать алгоритм SHA3-256, но в конечном счёте разработчики остановились на SHA2-256
>>На данном этапе можно лишь выбрать между SHA-1 и SHA-256Так SHA2-256 или SHA-256 добавили? Или это одно и тоже?
SHA-256 это SHA1-256
Нет.
Из педивикии:
===
The SHA-2 family consists of six hash functions with digests (hash values) that are 224, 256, 384 or 512 bits: SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, SHA-512/256.
===
SHA-224, 256 -- считаются 32-битными вордами, SHA-384, 512, 512/* -- 64битными.
Кроме того, отличаются кажется IV (кому интересно точно, читайте педивикию и стандарты).И всё это -- семейство SHA-2
Интересно почему СКВ популярно только у программистов? Теоретически они могут полезны везде где есть часто изменяемые файлы и необходимость командной работе с ними. А то бухгалтеры и дизайнеры плодят 100500 файлов _копия100500 где в этой помойке не разберёшь где что лежит
> Интересно почему СКВ популярно только у программистов? Теоретически они могут полезны везде
> где есть часто изменяемые файлы и необходимость командной работе с ними.
> А то бухгалтеры и дизайнеры плодят 100500 файлов _копия100500 где в
> этой помойке не разберёшь где что лежитпотому что у ворда (и майкрософтофиса) бинарные и проприетарные форматы
но я присоединяюсь к вашему недоумению
>> Интересно почему СКВ популярно только у программистов? Теоретически они могут полезны везде
>> где есть часто изменяемые файлы и необходимость командной работе с ними.
>> А то бухгалтеры и дизайнеры плодят 100500 файлов _копия100500 где в
>> этой помойке не разберёшь где что лежит
> потому что у ворда (и майкрософтофиса) бинарные и проприетарные форматы
> но я присоединяюсь к вашему недоумениюА что мешает этом ворду или другой аналогичной программе использовать текстовый недеструктивный формат? Вендорлок?
Микрософт ;)Вообще-то в MS Word есть встроенный контроль версий. Пригодность к использованию по назначению --- не знаю, я word'ом не пользуюсь. Судя по тому, что об этом почти никто не знает, наверное не пригодно. Там много чего интересного при желании можно найти. Я из присланной рекрутёрами описания вакансии ради интереса достал оттуда: компанию, запостившую вакансию, дату когда её создали, имена hr-ов в оригинальной компании и рекрутинговом агенстве, имя заинтересованного руководителя, примерное количество соискателей на эту вакансию и динамику изменений требований к кандидату, включая денежное довольствие (откуда следовало, что с наймом на эту позицию проблемы).
Вполне пригодно и активно используется. В либре аналогичное есть. Проблема скорее в том, что общая культура работы с данными в ворде в среднем по больнице чудовищна - ну там, на одного учёного тысяча секретарш, которые даже стили не понимают.
У учёных тоже каша в головах.
То ли дело писатели, вот у этих гит хорошо заходит.
Беда в том, что чувствительная информация регулярно утекает незаметно для потребителя. И сделано так (по крайней мере, было; есть ли сейчас?) "из коробки".
На самом деле всё просто. Бинарные файлы тоже можно сравнивать. Достаточно
$ git config diff.word.textconv docx2txt
$ echo '*.docx diff=word' > .gitattributes
Если документы хранятся в репозитории, то можно легко их сравнить. Конечно форматирование теряется, но программистам и не нужно форматирование. А бухгалтеры всё равно не смогут использовать даже GUI git, чтобы делать это. Если только обёртку для этого написать, но мёржить всё равно не получится, проще их на markdown пересадить.
Уже давно не бинарные
Дело не в бинарном формате, а в том, что все существующие стабильные системы контроля версий - текстовые. То есть подходят только для исходников и плейн текста, и то очень плохо. А нужна система для DAGов, а не последовательностей строк.
> Дело не в бинарном формате, а в том, что все существующие стабильные системы контроля версий -
> текстовые.хуже - они линейно-ориентированные. html - это в общем текстовый файл. Только от добавления лишнего пробела или переноса строки, ВНЕЗАПНО, не только не портится, как модные-современные форматы, а хуже того - в результирующем его отображении не меняется НИЧЕГО.
> То есть подходят только для исходников и плейн текста
именно так. Причем для исходников не на пихоне тоже неудобны - приходится добавлять отдельные костыли и подпорки для борьбы с лишним пробелом (а перенос по прежнему неизлечим).
Но с вордом (и экселом) прикол в том, что они ТОЖЕ линейно-ориентированные, хотя и не плейнтекст. И показать что вот в этой строке поменяли а на б а вон та просто сдвинута ниже - вполне можно. Просто не ждите от шва6одкоистерическ подобного инструмента. Включая для шва6одкиных форматов шва6одкоофиса, не на тех напали.
Коммерческие - лет десять назад вполне успешно существовали, к сожалению, мне тогда были без пользы, поэтому названий не вспомню.
> потому что у ворда (и майкрософтофиса) бинарные и проприетарные форматысредства для трекинга изменений в которых (пусть бинарные и проприетарные) существуют уже лет двадцать.
> но я присоединяюсь к вашему недоумению
спи спокойно, твоей шва6одке они не угрожают
Сравнить два .odt ты сможешь примерно никогда.
А какая разница? diff это капля в море возможностей vcs. Посмотреть "как было" и "как стало" можно с абсолютно любым форматом, плюс кто и когда что-то менял. А если постараться, можно и diff сделать. Например, github замечательно умеет diff картинок.
> Интересно почему СКВ популярно только у программистов?Ну почему, в девяностые вроде как и у бухгалтеров с дизайнерами СКВ бывали популярны...
Лично я загнал себя в задницу тысячами и тысячами файлов разных версий на диске. Они ещё и названы могут быть различно (а могут и одно и то же имя иметь). Единственное решение, которое я сейчас вижу, это при любом сохранении файла на диске, принудительно требовать добавлять дополнительную инфу (вроде содержимого и версии, даты), ссылку на онлайн источник, дополнительно извлекать данные о времени последнего изменения файлов в архиве, и всё это пихать в кдеешный semantic desktop (если бы он ещё не обнулялся рандомно). Файлы то относительно небольшие: 10 гигабайт туда, 15 гигабайт сюда, три тысячи тысячи файлов по 4 гигабайта вон там и там, пойди разберись и рассортируй. И это всё за полгода. Когда файлы повторяются, но они разные, это начинает немного напряхать, потом по 10 версий одного файла и найди последний/нужный.
Главная боль в том, что данные рандомно обновляются. И мне что-то не хватает кнопки СРАВНИТЬ ФАЙЛЫ ПРОХЕШИРОВАВ ОБА в кде, когда предлагает заменить файл с одинаковым именем. Там может несколько байт поменялось, НО ОНИ ВАЖНЫЕ. Как люди вообще с файлами работают? Что-либо найти вообще тяжело, файлы называют чёрте как. Но реально, принудительное тагирование нормальными данными наверное бы помогло. Все эти файлы замечательно копятся и потом не ясно куда делись десятки терабайт, а тебе срочно нужны терабайты под какие-то данные, а всё забито мусором и частичными дубликатами.
> Как люди вообще с файлами работают?Твой case описан крайне мутно, сложно дать конкретный совет. Я упорядочиваю ебуки в чём-то типа wiki построенной на org-mode файликах. Мне плюс-минус пофигу как там называются файлы, потому как если мне что-то надо, я ищу это в org-mode по тегам или ключевым словам, и там есть ссылки на файлы.
edit: есть универсальный совет под такие проблемы: lisp. lisp позволяет смешивать описание данных и код. То есть ты начинаешь описывать данные в виде s-expressions, а потом добавляешь обвязку, которая автоматизирует самые болезненные действия. Тут я могу порекомендовать [1], в качестве введения в тему. Это правда common lisp, а не что-нибудь хипстерское типа scheme или racket. Но переключиться с CL на scheme/racket не так уж и сложно.
Мне нужно управление файлами, полученными из интернета. Допустим, я знаю, что ищу, но найти это, не проследовав на источник в интернете и не получив из него имя искомого файла и дату последнего изменения (а в самом лучшем случае и хэш), не представляется возможным: если я открываю архив. я вижу в нём какие-то бинарные файлы, и что дальше? По соседству может лежать точно такой же файл, более старый по времени изменения и имеющий тот же самый размер, но по факту это более новый файл с кучей изменений. Всё-таки, юзабилити нынешних файловых менеджеров не очень высокое. Было бы неплохо интегрировать систему файл менеджмента (я пока только реализовал подгрузку сведений из интернета, но где-то придётся запускать браузер из-за скриптов и это уже не удобно).
Мне кажется, в случае с архивами, можно просканировать файл на предмет самого последнего изменения для всех файлов в архиве. Не поможет для изврата, где время изменения подделали, но в целом должно быть нормально. Но это работает только с архивами, с бинарями не получится и тут только считать хэш -- это единственная доступная инфа. Если бы существовал реестр загрузок, хэши для всех файлов в него вполне можно было бы и сохранять. Но они долго считаются. Т_Т
В идеале было бы в процессе загрузки хэши считать. Ну т.е. если скачивать будет скрипт вместо браузера, он может и добавлять всё куда нужно. Однако это мнее удобно, наверное. И опять же проблема: страницы генерируются скриптами, нужно решать капчи, и прочее такое. Почему никто не напишет такое ПО?
А вот тут что-то можно сделать. Время изменения для локального файла выставлять по последнему обновлённому файлу в архиве. У локального файла архива всё ещё остаётся время создания (даже два, но с ними всегда путаница и второе в glibc только недавно добавили).
Я имею в виду, я это сделал (шелл, правда), но это не информация об удалённом файле. В принципе, так даже лучше, да? Не знаю.
Это просто мера уровня специалиста. Всё что может периодически изменяться руками нет смысла не хранить в vcs. Да, не для всего можно сделать diff, но diff это только один малюсенький аспект работы с VCS. Посмотреть как было, как стало, кто и когда изменил можно абсолютно всегда. И очень часто нужно.
>Также пока ни один Git-провайдер, включая GitHub, не поддерживает репозитории с хэшами SHA-256.Насколько я помню, в доках по гиту было написано, что сначала сделают фичу локально, а уже потом начнут делать транспорт по сети.
У них даже локально не все работает, например gitk.
Уже 2.29.1 вышел
https://github.com/git/git/commit/b927c80531cca9b91077541865...
> Уже 2.29.1 вышел
> https://github.com/git/git/commit/b927c80531cca9b91077541865...GVF=GIT-VERSION-FILE
- DEF_VER=v2.29.0
+ DEF_VER=v2.29.1
и весь релиз
Это лишь один комминт, там ещё есть. В описании ведь написано что изменилось или ты не читал?