Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Выпуск распределенной системы управления исходными текстами Git 2.29"	+/–
Сообщение от opennews (??), 20-Окт-20, 15:03
Доступен выпуск распределенной системы управления исходными текстами Git 2.29.0. Git является одной из самых популярных, надёжных и высокопроизводительных систем управления версиями, предоставляющей гибкие средства нелинейной разработки, базирующиеся на ответвлении и слиянии веток. Для обеспечения целостности истории и устойчивости к изменениям "задним числом" используются неявное хеширование всей предыдущей истории в каждом коммите, также возможно удостоверение цифровыми подписями разработчиков отдельных тегов и коммитов... Подробнее: https://www.opennet.me/opennews/art.shtml?num=53923
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по времени | RSS]

1. "Выпуск распределенной системы управления исходными текстами ..."	–8 +/–
Сообщение от Аноним (1), 20-Окт-20, 15:03
Читая чейнджлоги, мне каждый раз мерещится, что git из простой булки белого (или черного) хлеба превращается в трамвай. Надеюсь просто мерещится.
Ответить | Правка | Наверх | Cообщить модератору

	2. "Выпуск распределенной системы управления исходными текстами ..."	+20 +/–
	Сообщение от Аноним (2), 20-Окт-20, 15:08
	В какой момент git был простым? Довольно сложная VCS с момента рождения, просто он стал индустриальным стандартом.
	Ответить | Правка | Наверх | Cообщить модератору

	14. "Выпуск распределенной системы управления исходными текстами ..."	–2 +/–
	Сообщение от m.makhno (ok), 20-Окт-20, 16:01
	Сложный он ровно до того момента, пока не проникнешься его философией. А дальше уже не понимаешь, как раньше жил до этого знакового знакомства. Потом, правда, приходится разбираться ещё с трактовками его фич разномастными хостингами, с их модно-молодёжными workflow's.
	Ответить | Правка | Наверх | Cообщить модератору

Часть нити удалена модератором

	24. "Выпуск распределенной системы управления исходными текстами ..."	+8 +/–
	Сообщение от Аноним (24), 20-Окт-20, 16:46
	Имеется в виду что сначала нужно освоить vi и emacs и тогда уже гит будет казаться простым.
	Ответить | Правка | Наверх | Cообщить модератору

	53. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от TheFotoMag (ok), 20-Окт-20, 20:19
	> пока не проникнешься его философией. А дальше уже не понимаешь, как раньше жил Бешено плюсую.
	Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

	93. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от Аноним (2), 21-Окт-20, 11:36
	Ну так про все что угодно можно сказать, haskel сложен пока не проникнешься его философией, многомерные пространства сложны пока не проникнешься их философией. Помню когда начал работать с git первые пол года перед каждым шагом делал tar czvf. До сих пор без заглядывания в заметки не смогу назвать команду для откатывания коммитов, путаю git clean и git reset. Пользуюсь гит с 2012 года.
	Ответить | Правка | К родителю #14 | Наверх | Cообщить модератору

	98. "Выпуск распределенной системы управления исходными текстами ..."	+1 +/–
	Сообщение от Ordu (ok), 21-Окт-20, 13:33
	> До сих пор без заглядывания в заметки не смогу назвать команду для откатывания коммитов Если ты заглядываешь в заметки и не можешь запомнить команды не потому, что тебе нужен аргумент в пользу того, что 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, которая не будет вызывать такого желания.
	Ответить | Правка | Наверх | Cообщить модератору

	100. "Выпуск распределенной системы управления исходными текстами ..."	+1 +/–
	Сообщение от Аноним (2), 21-Окт-20, 14:11
	Как много текста ни о чем. У git сложный CLI. Чуть более предметно. Кейс 1: Я случайно закомител лишний файл, но еще не отправил коммит на удаленный репозитарий. Как мне убрать лишний файл из последнего коммита? Я могу только заглянуть в заметки и вытащить от туда команду: git reset 'HEAD@{1}', после которой я повторяю заново коммит без этого файла. Кейс 2: Я случайно добавил в индекс лишний файл, как его убрать из индекса не удалив. Я вот не помню, кажется через reset. Мне надо опять заглянуть в заметки. > Я б рекомендовал подумать об использовании другой vcs, которая не будет вызывать такого желания. Так GIT стандарт, где не работал везде гит, я пользуюсь тем что есть.
	Ответить | Правка | Наверх | Cообщить модератору

	102. "Выпуск распределенной системы управления исходными текстами ..."	+1 +/–
	Сообщение от Аноним (2), 21-Окт-20, 14:39
	Ну и раз я критикую, я хотел бы сказать какой CLI на мой взгляд был бы более понятным: git rm   удалить файл с диска git rmi  удалить файл из индекса git undo [N] - отменить последние N действий git squash N - объединить последние N коммитов в один. git squash 772e40f-fe89105 - объединить указанные коммиты в один.
	Ответить | Правка | Наверх | Cообщить модератору

	104. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от Ordu (ok), 21-Окт-20, 15:58
	> Ну и раз я критикую, я хотел бы сказать какой CLI на > мой взгляд был бы более понятным: > git rm   удалить файл с диска > git rmi  удалить файл из индекса Напиши скрипт, проблем-то? > git undo [N] - отменить последние N действий Эмм... Это как? В список отменяемых действий включать переключение веток, например? > git squash N - объединить последние N коммитов в один. > git squash 772e40f-fe89105 - объединить указанные коммиты в один. git rebase тебе в помощь. Это более общий инструмент, который не только объединять умеет, но и разделять и переупорядочивать, но ты попробуй как-нибудь на досуге.
	Ответить | Правка | Наверх | Cообщить модератору

	106. "Выпуск распределенной системы управления исходными текстами ..."	+1 +/–
	Сообщение от Аноним (2), 21-Окт-20, 16:16
	Я и пользуюсь rebase, в vi меняю строчки на squash нужных мне коммитов, только для этого мне приходится опять заглядывать в заметки, где я нахожу git rebase --interactive HEAD~N, потому что это запомнить нереально, CLI нисколько не помогает. GIT сложен, моя команда училась работе с ним пол года. Это слишком много для какой-то VCS. Если тул которым пользуешься каждый рабочий день требует столько времени для освоения, то значит он сложный. Я не говорю что git плохой, но он сложный. Сложный как игра на гитаре, или gnu screen, или awk, sed, vi. Причем gnu screen и vi я умею пользоваться, и пользуюсь каждый день, но я никогда никому не будут рассказывать что они простые.
	Ответить | Правка | Наверх | Cообщить модератору

	112. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от Ordu (ok), 21-Окт-20, 16:58
	> Я и пользуюсь 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.
	Ответить | Правка | Наверх | Cообщить модератору

	122. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от Аноним (2), 21-Окт-20, 19:52
	> Игра на гитаре требует сложных моторных навыков, в сочетании с развитием сенсорики, и это реально _годы_ ежедневной практики. А можно знать три аккорда и играть боем. > 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 намного сложнее.
	Ответить | Правка | Наверх | Cообщить модератору

	123. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от Аноним (2), 21-Окт-20, 19:56
	Я вспомнил какой был svn workflow: git stash git pull git pop <!- резолвинг конфликтов -> git commit git push
	Ответить | Правка | Наверх | Cообщить модератору

	125. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от Ordu (ok), 21-Окт-20, 21:06
	> Я вспомнил какой был svn workflow: > git stash > git pull > git pop > <!- резолвинг конфликтов -> > git commit > git push ууу... Откуда вы такой взяли? Какой-то "гений" придумал, а вы потом мучались.
	Ответить | Правка | Наверх | Cообщить модератору

	128. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от Аноним (2), 21-Окт-20, 22:45
	Коллективно придумали за один день, в первый день был только один вопрос, как свои изменения залить на git когда есть конфликт?
	Ответить | Правка | К родителю #125 | Наверх | Cообщить модератору

	124. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от Ordu (ok), 21-Окт-20, 21:01
	>> Игра на гитаре требует сложных моторных навыков, в сочетании с развитием сенсорики, и это реально _годы_ ежедневной практики. > А можно знать три аккорда и играть боем. Один член тут моторные навыки. Надо пальцами попадать по ладам в нужных местах, и медиатор держать так, чтобы не вываливался из пальцев. И да, баррэ -- ппц как сложно, когда не умеешь держать палец прямым и в нужном месте, вне зависимости от положения кисти. > Был 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. Так?
	Ответить | Правка | К родителю #122 | Наверх | Cообщить модератору

	127. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от Аноним (2), 21-Окт-20, 22:21
	> Дай я угадаю, вам git насаживали в приказном порядке сверху. Почти так и было, лично мне тогда git был не нужен, svn хватало. Я надеялся что кто-то разберется и устроит мастер класс передав знания коллективу, но нет. И да, периодически я выделял пол часа я на чтение progit пытаясь разобраться с той или иной темой. Я искренне не понимаю почему какая-то vcs от меня требовала стольких усилий, и почему был выбран git, чем он лучше svn, hg, bazar, etc. Тот кто внедрял на момент внедрения "знал" что git каким-то магическим способом решает проблемы бранчинга и мержа конфликтов, но как именно он их решает объяснить не мог.
	Ответить | Правка | Наверх | Cообщить модератору

	129. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от Ordu (ok), 21-Окт-20, 22:50
	> Я искренне не понимаю почему какая-то vcs от меня требовала стольких усилий, Потому что ты причину ищешь снаружи своей психики, хотя она прячется внутри. > почему был выбран git, чем он лучше svn, hg, bazar, etc. Тот кто внедрял на момент внедрения "знал" что git каким-то магическим способом решает проблемы бранчинга и мержа конфликтов, но как именно он их решает объяснить не мог. Ты сам ответил на свой же вопрос. Он выбрал git потому что где-то прочитал, что git решает проблемы бранчинга и мерджа конфликтов, но при этом решил что не его дело разбираться в том, как это работает -- не ему же мерджить конфликты?, -- что его задача спустить циркуляр о переходе на git, и всё автоматически станет хорошо. Очередное чмо которое лезло по карьере ровно до той ступеньки, где квалификации оказалось недостаточно. Ему б курсы менеджмента закончить, хотя бы краткосрочные какие, чтобы азы освоить и совсем уж позорных ошибок не совершать. Но технари снобы в принципе, и любое не технарское знание воспринимают как недостойное их.
	Ответить | Правка | К родителю #127 | Наверх | Cообщить модератору

	130. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от Аноним (2), 21-Окт-20, 23:09
	> Потому что ты причину ищешь снаружи своей психики, хотя она прячется внутри. Моя психика мне говорит что мне было тогда не интересно и до сих пор не интересно изучать VCS и его внутреннее устройство. В нормальной VCS я бы использовал команду откатить изменения, а не сбросить/переустановить указатель головы на одну позицию назад в цепочке коммитов. Хех, я только сейчас понял что reset как раз используется в смысле "переустановить/переназначить".
	Ответить | Правка | К родителю #129 | Наверх | Cообщить модератору

	103. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от Ordu (ok), 21-Окт-20, 15:56
	>> Я б рекомендовал подумать об использовании другой vcs, которая не будет вызывать такого желания. > Так GIT стандарт, где не работал везде гит, я пользуюсь тем что > есть. Если ситуация такова, то значит надо одолевать свои психологические причины не справляться с git и искать способ справляться. git -- это просто, если тебе сложно, значит что-то ты делаешь не так.
	Ответить | Правка | К родителю #100 | Наверх | Cообщить модератору

	105. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от Аноним (2), 21-Окт-20, 16:06
	> Если ситуация такова, то значит надо одолевать свои психологические причины не справляться с git и искать способ справляться. Рекомендуете начать с аутотренинга перед зеркалом?
	Ответить | Правка | Наверх | Cообщить модератору

	107. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от Ordu (ok), 21-Окт-20, 16:17
	Это уж кому что помогает.
	Ответить | Правка | Наверх | Cообщить модератору

	115. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от all_glory_to_the_hypnotoad (ok), 21-Окт-20, 18:16
	Все твои кейсы делает, очевидно, `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
	Ответить | Правка | К родителю #100 | Наверх | Cообщить модератору

	121. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от Аноним (2), 21-Окт-20, 19:07
	Кстати я тут ошибся указав git reset 'HEAD@{1}', в моих заметках сказано что это делает UNDO для UNDO, видно из-за простоты git этого никто пока не заметил. А UNDO коммита как написал товарищ выше: git reset --soft HEAD~ Прямо очень интуитивно, я как вижу git reset --soft HEAD~ так сразу понимаю что это откатывает коммит, проще пареной репы.
	Ответить | Правка | К родителю #100 | Наверх | Cообщить модератору

	26. "Выпуск распределенной системы управления исходными текстами ..."	–3 +/–
	Сообщение от all_glory_to_the_hypnotoad (ok), 20-Окт-20, 16:50
	Это абсолютная чушь, Git простой как топор. Проще SVN, HG и многих других VCS. Потому у меня обратный вопрос - почему важные архитектурные изменения (развитие протокола, поддержка нескольких хешей и т.д.) происходят медленно, но коммитов стабильно не мало. Я, например, за 627 своих типичных изменений по объёму мог бы почти полностью переписать такой пакет и значительно доработать архитектурно.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	31. "Выпуск распределенной системы управления исходными текстами ..."	+4 +/–
	Сообщение от fossilscm (?), 20-Окт-20, 17:22
	> Это абсолютная чушь, Git простой как топор. Я не согласен!
	Ответить | Правка | Наверх | Cообщить модератору

	96. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от Аноним (2), 21-Окт-20, 11:40
	Ну тогда: Git прост как бензопила!
	Ответить | Правка | Наверх | Cообщить модератору

	33. "Выпуск распределенной системы управления исходными текстами ..."	+2 +/–
	Сообщение от an0nymous (?), 20-Окт-20, 17:35
	>Проще SVN, HG Какой наброс. Документация по гиту такая кхмм.. подробная, что иногда выть хочется. По моиму опыту обучить гиту НЕПРОГРАММИСТА (чтобы он ничего не ломал ничего и осозновал что делает) на порядки сложнее чем тот же hg. в нем много лишних абстракций торчат наружу, которые могли бы быть скрыты и интерфейс стал бы проще.
	Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

	89. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от пох. (?), 21-Окт-20, 10:04
	> Какой наброс. Документация по гиту такая кхмм.. подробная, что иногда выть хочется. поскольку гит представляет собой не человеческую программу, исполняющую ровно одну задачу хорошо, как большинство нормальных vcs, а нагромождение костылей и подпорок вокруг совершенно бредовой задачи "порежьте помельче, перепошлите в рассылку", включая и попытки приспособить ее решение к промышленной разработке вместо использования более подходящих - такой документации никогда и не будет - потому что сначала нужно заставить тебя изучить и принять совершенно нечеловеческий workflow, потом описать этапы его автоматизации, "а теперь забудьте все, что вам рассказывали, и давайте попробуем эту мусорку приспособить к реальным нашим задачам - смотрите, смотрите - какие отличные костылики к ней для этого приладили". > По моиму опыту обучить гиту НЕПРОГРАММИСТА (чтобы он ничего не ломал ничего > и осозновал что делает) на порядки сложнее чем тот же hg. как будто программисты осознают что делают, а не вызубрили git clone /git commit /git push ? Следующее поколение и этого уметь не будет - "clone me on github", и всех дел. Давай ты скопируешь из этой новости все примеры, без объяснений, и попросишь любого программиста рассказать тебе, что они делают, не подглядывая в гугль? Или даже проще - для экономии времени - попроси объяснить тебе смысл и назначение git rev-parse Думаю, процентов 90 вообще не знают толком, что эта команда делает и как ей пользоваться - хотя и имеют под рукой копипасту со стека, решающую какую-то их частную задачу. > в нем много лишних абстракций торчат наружу, которые могли бы быть это не абстракции, это детали внутреннего механизма. Совершенно ненужные, да. Просто потому что механизм выполняет совершенно ненужную работу. А та что на самом деле нужна в большинстве случаев - сделана костылями вокруг него.
	Ответить | Правка | Наверх | Cообщить модератору

	97. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от anonymous yet another (?), 21-Окт-20, 12:51
	Вы транслируете мнение совершенно не разбирающегося в архитектурах VCS. С желаниями от "configurations management" и игнорированием всего остального.
	Ответить | Правка | Наверх | Cообщить модератору

	101. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от all_glory_to_the_hypnotoad (ok), 21-Окт-20, 14:29
	в Git примерно всего две простых абстракции - это ADG и индекс. В SVN одна простая с линеной историей, одна мозговыносящая связанная с ветками, тэгами и мержами директорий в директории (не видел как пользователи копируют trunk в NNN GiB в trunk?), и ещё некоторое кол-во поменьше. В Hg одних веток только несколько штук, в плане неконсистентности это самая yблюдочная VCS. Документации к Git больше если сравнивать c, например, svn, просто потому что в Git значильно больше функциональности. Однако это не означает что для работы нужно знать всё и всем пользоваться. Чтобы странный пользователь ничего плохого не делал есть прекоммитные хуки, причём ими пользуются во всех VCS для ограничения деятельности альтернативно одарённых персонажей.
	Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

	54. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от TheFotoMag (ok), 20-Окт-20, 20:27
	> Git простой как топор Судя по непрязни к Гиту — ни один его критик к разработке не имеет никакого отношения. Все просто: без контроля версий жить нельзя. ДЕНЬГИ!!! Затраты на разработку растут на порядок!!! Бабушиным внукам такие вещи по%уй, они не оплачивают команду из своего кармана и уверены, что бабушкина пенсия растет на дереве. Мне пришлось попробовать всё и Гит — САМЫЙ ВЫГОДНЫЙ вариант. ТОЧКА!!!
	Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

	55. "Выпуск распределенной системы управления исходными текстами ..."	–3 +/–
	Сообщение от TheFotoMag (ok), 20-Окт-20, 20:30
	>> Git простой как топор > Судя по непрязни к Гиту — ни один его критик к разработке > не имеет никакого отношения. > Все просто: без контроля версий жить нельзя. ДЕНЬГИ!!! Затраты на разработку растут > на порядок!!! > Бабушиным внукам такие вещи по%уй, они не оплачивают команду из своего кармана > и уверены, что бабушкина пенсия растет на дереве. > Мне пришлось попробовать всё и Гит — САМЫЙ ВЫГОДНЫЙ вариант. ТОЧКА!!! Продолжая заочную дискуссию с безработными энтузиастами открытых решений — JIRA. Без нее тоже никак.
	Ответить | Правка | Наверх | Cообщить модератору

	81. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от nomad__ (ok), 21-Окт-20, 07:49
	> JIRA. Без нее тоже никак очень даже как, потому что есть Redmine.
	Ответить | Правка | Наверх | Cообщить модератору

	135. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от TheFotoMag (ok), 22-Окт-20, 09:56
	>> очень даже как, потому что есть Redmine. Редкостная чушь сей Redmine
	Ответить | Правка | Наверх | Cообщить модератору

	136. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от nomad__ (ok), 22-Окт-20, 10:04
	>>> очень даже как, потому что есть Redmine. > Редкостная чушь сей Redmine На вкус и цвет все люди разные. По крайне мере, за него платить не надо.
	Ответить | Правка | Наверх | Cообщить модератору

	137. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от TheFotoMag (ok), 22-Окт-20, 14:12
	>>>> очень даже как, потому что есть Redmine. >> Редкостная чушь сей Redmine > На вкус и цвет все люди разные. По крайне мере, за него > платить не надо. Ещё как надо! :)  Каким это бесплатными образом вы намерены обеспечить группе доступ к серверу??? :) Хостинг/колокейшн либо канал до домашнего сервера стоят денюжек! :) И так это заметных :)
	Ответить | Правка | Наверх | Cообщить модератору

	138. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от nomad__ (ok), 22-Окт-20, 14:14
	>>>>> очень даже как, потому что есть Redmine. >>> Редкостная чушь сей Redmine >> На вкус и цвет все люди разные. По крайне мере, за него >> платить не надо. > Ещё как надо! :)  Каким это бесплатными образом вы намерены обеспечить > группе доступ к серверу??? :) > Хостинг/колокейшн либо канал до домашнего сервера стоят денюжек! :) И так это > заметных :) Но за саму систему платить не надо, в отличие от Jira.
	Ответить | Правка | Наверх | Cообщить модератору

	140. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от TheFotoMag (ok), 22-Окт-20, 20:31
	> Но за саму систему платить не надо, в отличие от Jira. А админить? Пушкин будет? Самому доки курить и ночей не спать? +1 чел. 40 тыщ? А он хочет 70. Пенсионный, бла-бла-бла. Вот Jira уже и дешевле. Открывай контору, окунайся в жизнь, плати зарплаты :) У всех — детки :) И начнешь смотреть на корпоративные сервисы другими глазами :)  :)  :)
	Ответить | Правка | Наверх | Cообщить модератору

	141. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от nomad__ (ok), 23-Окт-20, 05:43
	>> Но за саму систему платить не надо, в отличие от Jira. > А админить? Пушкин будет? Самому доки курить и ночей не спать? +1 > чел. 40 тыщ? А он хочет 70. Пенсионный, бла-бла-бла. Вот Jira > уже и дешевле. Открывай контору, окунайся в жизнь, плати зарплаты :) > У всех — детки :) И начнешь смотреть на корпоративные сервисы > другими глазами :)  :)  :) Я разраб, а не бизнесмен, в буй мне не впилась своя контора с ее гемором. И да, админ нужен не только для редмайна.
	Ответить | Правка | Наверх | Cообщить модератору

	88. "Выпуск распределенной системы управления исходными текстами ..."	+2 +/–
	Сообщение от Аноним (88), 21-Окт-20, 09:57
	> JIRA. Без нее тоже никак. Редкое дерьмо.
	Ответить | Правка | К родителю #55 | Наверх | Cообщить модератору

	87. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от пох. (?), 21-Окт-20, 09:53
	> Судя по непрязни к Гиту — ни один его критик к разработке > не имеет никакого отношения. утипупсичек, ну конечно же. > Все просто: без контроля версий жить нельзя. Все просто: кроме тебя, вчерародившегося, тут есть еще, хотя и в очень небольшом количестве, люди, использовавшие в своей работе vcsы еще когда ни тебя, ни уродства автоматизирующего неумение одного пингвиноида в коллективную разработку, в помине не было. ВНЕЗАПНО, гит не является ни единственным, ни первым, ни хотя бы хорошим средством контроля версий. > Бабушиным внукам такие вещи по%уй, они не оплачивают команду из своего кармана О, так мсье - инвестор? Из своего кармана хоть что оплачивает? Или даже за свет платит бабушка, пока он сидит "на удаленке", как обычно? > Мне пришлось попробовать всё и Гит — САМЫЙ ВЫГОДНЫЙ вариант. ТОЧКА!!! Попробуй еще легкие наркотики. А то судя по количеству заглавных букв в твоей писанине, необратимые изменения уже начались.
	Ответить | Правка | К родителю #54 | Наверх | Cообщить модератору

	75. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от GG (ok), 21-Окт-20, 04:57
	Ну перепиши и доработай, все тебе будут благодарны и может даже денег отсыплют
	Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

	57. "Выпуск распределенной системы управления исходными текстами ..."	–2 +/–
	Сообщение от anonymous yet another (?), 20-Окт-20, 20:44
	Если тут есть люди, имеющие отношение к психологии или преподаванию (чего-либо, не важно) --- поясните, пожалуйста, вероятную мотивацию жмыхателей на значки +/- к комментариям 3.26 и 3.14. Спасибо.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	76. "Выпуск распределенной системы управления исходными текстами ..."	+1 +/–
	Сообщение от GG (ok), 21-Окт-20, 04:58
	Увидели что там уже есть +/- и добавили свой чтобы не выделяться из толпы
	Ответить | Правка | Наверх | Cообщить модератору

	142. "Выпуск распределенной системы управления исходными текстами ..."	–1 +/–
	Сообщение от n242name (?), 23-Окт-20, 20:17
	вхуярил тебе минус, а у тебя стоял там плюс, наверное, доморощенный ты психолог, это потому что я хочу выделиться из толпы?
	Ответить | Правка | Наверх | Cообщить модератору

	145. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от n00by (ok), 24-Окт-20, 08:47
	В 3.26 -- за вводный негативный заряд "Это абсолютная чушь". Далее комментарий дельный, но не все дочитали. В 3.14 вывод в споре о вкусах навязывается заметно мягче ("Сложный он ровно до того момента, пока не проникнешься его философией"), но оратор напрасно попытался обобщить субъективный опыт. Люди разные, одним таблицу умножения проще зазубрить, другим каждый раз заново в уме столбиком складывать.
	Ответить | Правка | К родителю #57 | Наверх | Cообщить модератору

	80. "Выпуск распределенной системы управления исходными текстами ..."	–1 +/–
	Сообщение от nomad__ (ok), 21-Окт-20, 07:48
	> В какой момент git был простым? Довольно сложная VCS с момента рождения Это в каком же месте он сложный? Или не осилил https://git-scm.com/book/ru/v2?
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	86. "Выпуск распределенной системы управления исходными текстами ..."	–1 +/–
	Сообщение от пох. (?), 21-Окт-20, 09:45
	конечно мерещится - он всегда был троллейбусом из буханки, причем с квадратными колесами. Как он может превратиться в трамвай?!
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

3. "Выпуск распределенной системы управления исходными текстами ..."	–5 +/–
Сообщение от Аноним (3), 20-Окт-20, 15:12
Хэши в постквантумную эпоху пострадают? А то планируют на 5 лет, а дальше хоть трава не расти.
Ответить | Правка | Наверх | Cообщить модератору

	4. "Выпуск распределенной системы управления исходными текстами ..."	–1 +/–
	Сообщение от myhand (ok), 20-Окт-20, 15:25
	> Хэши в постквантумную эпоху пострадают? Вся современная криптография пострадает.  Факторизация со скоростью умножения - это вам не шутки! > А то планируют на 5 лет А вы уже запаслись пророчеством Нострадамуса когда она настанет, эпоха энта?  Отсыпите?
	Ответить | Правка | Наверх | Cообщить модератору

	19. "Выпуск распределенной системы управления исходными текстами ..."	–1 +/–
	Сообщение от Аноним (3), 20-Окт-20, 16:23
	Ну вон каждый день заявляют о квантум супремасэ, и вроде довольно близко продвинулись уже. Скоро придём к тому, что вся "криптография" будет на запутанных частицах (вроде там сбер что-то такое делал ГОДА 4 НАЗАД), где вмешательство будет исключено. Изначально выбрать sha1 было примерно как выбрать des, а теперь поменять на 3des,
	Ответить | Правка | Наверх | Cообщить модератору

	38. "Выпуск распределенной системы управления исходными текстами ..."	+1 +/–
	Сообщение от rshadow (ok), 20-Окт-20, 18:12
	Еще далеко. Если корпорации и смогут, то ломать чужое это уголовка. Опасно для бизнеса. У спецслужб и так все есть. Надо ждать массовый сектор, а его пока в планах не видно.
	Ответить | Правка | Наверх | Cообщить модератору

	91. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от Аноним (91), 21-Окт-20, 10:30
	> У спецслужб и так все есть ага, два раза есть. [sarcasm] и у сбера также
	Ответить | Правка | Наверх | Cообщить модератору

	132. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от Аноним (132), 22-Окт-20, 07:05
	А обработка персональных данных без согласия - это что? Я вот банку передал давным давно бумагу, что отзываю согласие на обработку персональных данных, и требую произвести их уничтожение, а также всех их копий у всех контрагентов. И даже подписи работников банка на своём экземпляре вытребовал. Однако до сих пор СМС приходят "Для вас предварительно одобрен кредит, такая-то ставка, вы его можете взять, просто заявившись в отделение", хотя я сроду кредитов никогда не брал.
	Ответить | Правка | К родителю #38 | Наверх | Cообщить модератору

	67. "Выпуск распределенной системы управления исходными текстами ..."	+2 +/–
	Сообщение от Ivan_83 (ok), 21-Окт-20, 00:14
	Кавантовые компы угроза для ассимтричной крипты, но не для хэшей и симметричной крипты. Когда Линус начнал гит кажется sha2 ещё не было. sha2-256 ещё удобен тем что аппаратно есть в райзенах, впрочем sha1 тоже есть. А вот sha2-512 и sha3 аппратно пока нет.
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	45. "Выпуск распределенной системы управления исходными текстами ..."	+3 +/–
	Сообщение от n00by (ok), 20-Окт-20, 18:57
	>> Хэши в постквантумную эпоху пострадают? > Вся современная криптография пострадает.  Факторизация со скоростью умножения - это вам > не шутки! Факторизация чего? Вы типа думаете, что поля Галуа - это по которым гулял некий французский дяденька?
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

	78. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от myhand (ok), 21-Окт-20, 06:46
	> Факторизация чего? Больших целых.
	Ответить | Правка | Наверх | Cообщить модератору

	83. "Выпуск распределенной системы управления исходными текстами ..."	+2 +/–
	Сообщение от funny.falcon (?), 21-Окт-20, 08:38
	А при чем тут SHA в любой ипостаси? Вы с RSA не перепутали? А для эллиптических кривых уже квантовые алгоритмы есть?
	Ответить | Правка | Наверх | Cообщить модератору

	139. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от myhand (ok), 22-Окт-20, 17:46
	> А при чем тут SHA в любой ипостаси? При том. что алгоритм Гровера.  С SHA-2 тут, насколько я знаю, "все не так однозначно" (ц). > А для эллиптических кривых уже квантовые алгоритмы есть? В смысле?  Тут тот же алгоритм Шора может быть использован.
	Ответить | Правка | Наверх | Cообщить модератору

	143. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от n242name (?), 23-Окт-20, 21:22
	насколько я курил вопрос - уже есть, однако появилась криптография на изогениях, но все в зародышевым состоянии
	Ответить | Правка | К родителю #83 | Наверх | Cообщить модератору

	35. "Выпуск распределенной системы управления исходными текстами ..."	+3 +/–
	Сообщение от Аноним (35), 20-Окт-20, 18:06
	не особо. Может быть, когда-нибудь придется увеличить размер хэша например до 384 бит, но придумывать новые алгоритмы нет нужды. От квантовых вычислений страдает только асимметричное шифрование
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	48. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от Аноним (3), 20-Окт-20, 19:27
	Я слышал оценки в районе 4096 для RSA. И то, это скорее потому, что теоретическая база для эффективного квантового подбора таких ключей пока не существует.
	Ответить | Правка | Наверх | Cообщить модератору

	63. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от Аноним (132), 20-Окт-20, 23:58
	Алгоритм Гровера только квадратичное ускорение даёт, по сравнению с экспоненциальным для Шора.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

5. "Выпуск распределенной системы управления исходными текстами ..."	–1 +/–
Сообщение от б.б. (?), 20-Окт-20, 15:25
о, крутая вещь. а есть hg-репозиторий, где можно его скачать?
Ответить | Правка | Наверх | Cообщить модератору

	49. "Выпуск распределенной системы управления исходными текстами ..."	+4 +/–
	Сообщение от Michael Shigorin (ok), 20-Окт-20, 19:43
	Могу дать вместе с unzip.arj. :)
	Ответить | Правка | Наверх | Cообщить модератору

	74. "Выпуск распределенной системы управления исходными текстами ..."	+2 +/–
	Сообщение от б.б. (?), 21-Окт-20, 03:21
	у меня есть ha.lha и lha.ha, оба смешные
	Ответить | Правка | Наверх | Cообщить модератору

6. "Выпуск распределенной системы управления исходными текстами ..."	–4 +/–
Сообщение от Аноним (6), 20-Окт-20, 15:37
А я до сих пор пользуюсь SubVersion и всегда с улыбкой смотрю на очередные новости про гит и хг, и про ребейспроблемы
Ответить | Правка | Наверх | Cообщить модератору

	8. "Выпуск распределенной системы управления исходными текстами ..."	–1 +/–
	Сообщение от Аноним (8), 20-Окт-20, 15:44
	Обычно с улыбкой смотрят на болванчиков которые без интернета не могут ни коммит, ни лог сделать, а чтобы переключиться на другую задачу им приходится изменённые файлы двигать. А на тех кто крупное изменение льёт одним коммитом, потому что rebase чтобы разбить его на топики не умеет, смотрят без улыбки и просто указывают им на дверь.
	Ответить | Правка | Наверх | Cообщить модератору

	11. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от Аноним (-), 20-Окт-20, 15:46
	Какую дверь, что ты несешь такое вообще ?
	Ответить | Правка | Наверх | Cообщить модератору

	22. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от Аноним (8), 20-Окт-20, 16:44
	На дверь из IT конторы очевидно, потому что профнепригодность.
	Ответить | Правка | Наверх | Cообщить модератору

	42. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от Козлетто (?), 20-Окт-20, 18:47
	> На дверь из IT конторы очевидно, потому что профнепригодность. А у нас в ТИУ на "Информационные системы и технология" кроме меня даже о гите и краем уха не слыхали, а уж тем более о всяких rebase и СКВ вообще подавно.
	Ответить | Правка | Наверх | Cообщить модератору

	43. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от Козлетто (?), 20-Окт-20, 18:47
	>> На дверь из IT конторы очевидно, потому что профнепригодность. > А у нас в ТИУ на "Информационные системы и технология" кроме меня > даже о гите и краем уха не слыхали, а уж тем > более о всяких rebase и СКВ вообще подавно. И не только студенты, но и преподы
	Ответить | Правка | Наверх | Cообщить модератору

	46. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от Аноним (46), 20-Окт-20, 19:00
	Смешно конечно такие писульки читать, профнепригодность из-за того что коммиты большие? Походу у вас какие-то спартанские порядки в конторе. Все пишут по-разному, в том числе и в опер сорсе коммиты в 2 десятка файлов иногда встречаются. Обычно это вопрос договорённости в команде. До сих пор смешно с такого детского максимализма, ну до поделать, хорошо что я не в такой команде)
	Ответить | Правка | К родителю #22 | Наверх | Cообщить модератору

	68. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от Аноним (8), 21-Окт-20, 00:53
	При чём тут максимализм? Факт 1 - есть code review. Факт 2 - мегакоммит невозможно качественно поревьюить. Поэтому в отличие от профпригодности ревьюера такой коммит либо идёт в прод непоревьюеным, либо заворачивается. В первом случае это рано или поздно ломает прод, во втором разработчик не выполняет свою прямую работу. В результате в обоих случаях отправляется в дворники. Ну либо учится git и rebase и делает ветки из маленьких, атомарных, легко обозримых коммитов.
	Ответить | Правка | Наверх | Cообщить модератору

	72. "Выпуск распределенной системы управления исходными текстами ..."	+3 +/–
	Сообщение от Crazy Alex (ok), 21-Окт-20, 02:20
	Человек что-то лабает на коленке и что такое промышленное программирование не понимает. Бывает, убеждать бесполезно пока сам не побьётся.
	Ответить | Правка | Наверх | Cообщить модератору

	30. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от freehck (ok), 20-Окт-20, 17:15
	Ох уж это российская любовь к ребейзам. Чем вам просто мерджить-то не нравится? "Не аккуратненько"? =/
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	59. "Выпуск распределенной системы управления исходными текстами ..."	+2 +/–
	Сообщение от anana (?), 20-Окт-20, 20:57
	Мёржи превращают историю в нечитабельное месиво. Ребейзы (при правильном использовании) делают красивую линеаризованную историю, где каждый коммит в истории на своём месте и сразу понятно что и когда кто делал (точнее заканчивал делать). Разумеется там где разработчики не пишут описания изменений и смешивают пачку несвязных изменений в один коммит - мёрж / не мёрж уже ничего не поменяет.
	Ответить | Правка | Наверх | Cообщить модератору

	79. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от Анатолий (??), 21-Окт-20, 07:17
	мержить можно и сквошем.
	Ответить | Правка | Наверх | Cообщить модератору

	92. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от freehck (ok), 21-Окт-20, 11:27
	> Мёржи превращают историю в нечитабельное месиво. Это не мёрджи. Это неотлаженный воркфлоу.
	Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

	69. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от Аноним (8), 21-Окт-20, 00:56
	Чтобы вмержить ветку, её нужно сначала отребейзить (совершенно не обязательно на свежий master) и причесать - фиксы опечаток влить в те коммиты где опечатки были сделаны, большие коммиты разбить и т.д.
	Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

	62. "Выпуск распределенной системы управления исходными текстами ..."	–2 +/–
	Сообщение от Аноним (62), 20-Окт-20, 23:57
	За ребайсе надо сразу в торец
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	70. "Выпуск распределенной системы управления исходными текстами ..."	+1 +/–
	Сообщение от Аноним (8), 21-Окт-20, 01:00
	Такое говорили 15 лет назад неучи не видевшие и не хотевшие видеть нормальные VCS. Сейчас причесать ветку перед мержем - обязательное правило. Ребейз ветки на master (т.е. с перемещением корня) - дело вкуса, но по мне так нелинейная история допустима только в совсем маленьких проектах, иначе (когда есть > 5 параллельных ветвей) читать её невозможно.
	Ответить | Правка | Наверх | Cообщить модератору

	131. "Выпуск распределенной системы управления исходными текстами ..."	–1 +/–
	Сообщение от Аноним (131), 22-Окт-20, 06:28
	В торец надо тем, кто отправляет на ревью всю свою помойку коммитов, образовавшуюся естественным образом в ходе работы. Ревьюера не волнует, какие ты ошибки сделал в ходе работы и как их исправил. Его интересует конечный результат.
	Ответить | Правка | К родителю #62 | Наверх | Cообщить модератору

	134. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от пох. (?), 22-Окт-20, 09:51
	> В торец надо тем, кто отправляет на ревью всю свою помойку коммитов, > образовавшуюся естественным образом в ходе работы. Ревьюера не волнует, какие ты > ошибки сделал в ходе работы и как их исправил. Его интересует > конечный результат. конечный результат в случае не двустрочного исправления он оценить не сможет в принципе - тот слишком велик, чтобы вот так просто разобраться в его логике. История нужна не для шаманского танца ревьюера, а чтобы потом другие люди могли разобраться, откуда в коде что взялось, и, может быть, найти ломающее все исправление - а не получить в результате бисекта "task1235660" одним куском или десятью - от этого легче не станет. К чему это приводит - мы прекрасненько видим в lkml (я все еще с изюмлением наблюдаю процесс пертурбаций в ntfs3 - теперь уже со стороны, поскольку "уменявсеработает" и лучше уже не станет - именно потому что историю я не вижу и не могу нормально контролировать изменения). Когда ревью на 90% сводятся к придиркам к оформлению и исправлению colour на color. Потому что это единственное, что ревьюеры видят в пятистрочной лапше, на которую порезан действительно большой цельный кусок кода. А критические баги обнаруживаются совсем другими людьми, которые таки взяли проект как целое и начали тестировать - ибо других способов проверки неоднострочного кода в природе нет.
	Ответить | Правка | Наверх | Cообщить модератору

	9. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от Аноним (-), 20-Окт-20, 15:45
	Ну и дурак.
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	13. "Выпуск распределенной системы управления исходными текстами ..."	–1 +/–
	Сообщение от Аноним (13), 20-Окт-20, 15:51
	просто ты замшелый пенек. какой нахер subversion? брось уже каку!
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	47. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от Аноним (47), 20-Окт-20, 19:05
	Zip с циферками еще круче, его все даже github использует, аж скулы от улыбки сводит.
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	50. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от Michael Shigorin (ok), 20-Окт-20, 19:45
	> ребейспроблемы А что именно Вы предпринимаете в svn, когда надо свести две своих ветки -- например, в основной были мелкие исправления, которые местами пересекаются с текущей разработкой (возможно, где-то и конфликтуют)? Я просто немного помню, как это выглядело с cvs.  С гитом это хотя бы проблемы (в переводе на русский -- задачи), и проблемы решаемые, а не тот кромешный ужас, даже когда сервер рядом по локалке доступен.
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	58. "Выпуск распределенной системы управления исходными текстами ..."	+1 +/–
	Сообщение от anonymous yet another (?), 20-Окт-20, 20:56
	Без server-side (священо)действий --- никак. Лочим доступ (когда на запись, а когда и вообще) на час--день--неделю, сливаем backup в сторонку, говорим "ой, мама" и трудимся. После открытия доступа слушаем матюки и угрозы, вжимаем голову в плечи, лочим доступ и пытаемся поправить то, что наворотили. Иногда приходится повторять всё несколько раз. Но вера в святой backup нас поддерживает.
	Ответить | Правка | Наверх | Cообщить модератору

	90. "Выпуск распределенной системы управления исходными текстами ..."	–1 +/–
	Сообщение от пох. (?), 21-Окт-20, 10:21
	> А что именно Вы предпринимаете в svn, когда надо свести две своих > ветки merge нужных изменений > -- например, в основной были мелкие исправления, которые местами пересекаются > с текущей разработкой (возможно, где-то и конфликтуют)? и - чем ТУТ поможет rebase? Сломает ветку? Спасибо, я об этом как раз мечтаю. Это cherry-pick, и в svn это делает именно merge. > Я просто немного помню, как это выглядело с cvs.  С гитом в cvs точно так же. > это хотя бы проблемы (в переводе на русский -- задачи), и > проблемы решаемые, а не тот кромешный ужас, даже когда сервер рядом это не проблемы. Проблема что волшебства нет, и тебе придется изучать изменившийся код и заново изобретать свои правки под новую версию. Хоть с ребейзом, хоть с мержем, хоть с новая-папка-22 Проблема cvs/svn - когда проект НЕ ТВОЙ и ты не планируешь/не можешь в него возвращать правки. Потому что ты не можешь вести СВОЮ историю изменений параллельно - ни в виде ветки, ни в каком еще, даже в виде "новая папа" не можешь - случайный svn up все испортит. (svk, но это тот еще костыль) Забавно, что как раз git порожден средой, которая категорически враждебна к подобным применениям.
	Ответить | Правка | К родителю #50 | Наверх | Cообщить модератору

	71. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от Аноним (8), 21-Окт-20, 01:04
	Недалёким неведомо что svn up при наличии незакоммиченных изменений в working copy делает ни что иное как ребейз [этих изменений на новый head].
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	94. "Выпуск распределенной системы управления исходными текстами ..."	–1 +/–
	Сообщение от пох. (?), 21-Окт-20, 11:38
	> Недалёким неведомо что 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, но их писали давно, проекты были маленькими, всем было лень напрягаться.
	Ответить | Правка | Наверх | Cообщить модератору

	116. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от Аноним (8), 21-Окт-20, 18:19
	> что rebase - это перенос _истории_, а не всех отличий пачкой без разбора. Эгмх...подделка истории, тоись ;-) А нет никакой разницы разбиты изменения на отдельные коммиты или не разбиты, и вообще оформлены в виде коммитов или нет - в ваших терминах это в любом случае "подделка". С практической стороны в любом случае может произойти изменение в чужом коде которое сломает твоё изменение или тихо изменит его поведение, даже не вызвав конфликта.
	Ответить | Правка | Наверх | Cообщить модератору

	119. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от пох. (?), 21-Окт-20, 18:38
	> С практической стороны в любом случае может произойти изменение в чужом коде которое сломает твоё > изменение не может - оно где-то в origin/чтототам происходит в терминах гита. Твои комиты _никуда_ не денутся, и даже попортить автомагическим мержем НЕ закомиченое тебе не дадут. (Закомиченное - дадут, полагая что это именно то что ты хотел, но ты всегда можешь вернуть исходное состояние, это история.) А в svn/cvs ничего из этого нет, и для работы с _чужими_ проектами это действительно проблема. Подделка происходит при rebase. Поинтересуйся на досуге, что при этом на самом деле происходит с историей.
	Ответить | Правка | Наверх | Cообщить модератору

	133. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от пох. (?), 22-Окт-20, 09:39
	> А нет никакой разницы есть. > в ваших терминах это в любом случае "подделка". нет. Подделка - это именно подделка истории, когда изменения придуманные и реализованные при одном (одних, возможно - разных) состоянии кодовой базы - создаются кодом vcs заново, и выглядят в логе как сделанные при совсем другом ее состоянии. Так работает rebase - создавая фейковую историю вместо настоящей (поверх нее - настоящая на самом деле остается тоже, но ты ее не увидишь, а потом gc ее окончательно зачистит). А что вы там нафантазировали - к моим терминам не имеет ни малейшего отношения. Настоящую историю модификаций кода сохраняет merge. Но в той парадигме, для которой придуман и предназначен гит - твоя история никому не нужна, пришлите патчи в рассылку, порезав помельче. Поскольку там на самом деле не совместная разработка, а поклонение божкам. Для именно совместной гит одна из самых неподходящих технологий. Но модные-современные ничего другого просто не умеют.
	Ответить | Правка | К родителю #116 | Наверх | Cообщить модератору

	82. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от nomad__ (ok), 21-Окт-20, 07:50
	> ребейспроблемы например какие? А то вот уже 7 лет пользуюсь гитом и что-то не припомню проблем с rebase. Перешел, кстати, с svn.
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

7. "Выпуск распределенной системы управления исходными текстами ..."	–3 +/–
Сообщение от Аноним (-), 20-Окт-20, 15:44
Какой-то фольклер вместо вменяемого ченжлога, еще и испорчено корявым переводом.
Ответить | Правка | Наверх | Cообщить модератору

10. "Выпуск распределенной системы управления исходными текстами ..."	+/–
Сообщение от ALex_hha (ok), 20-Окт-20, 15:45
> А я до сих пор пользуюсь SubVersion сочувствую бро > и всегда с улыбкой смотрю те, кто работал с svn в цирке больше не смеются > и про ребейспроблемы в svn их просто нет. Нет человека - нет проблем ( с )
Ответить | Правка | Наверх | Cообщить модератору

12. "Выпуск распределенной системы управления исходными текстами ..."	–2 +/–
Сообщение от Аноним (13), 20-Окт-20, 15:46
дебильная логика. sha3 стандарт. не sha2, не sha1, не md5. sha3! нафига использовать старье?
Ответить | Правка | Наверх | Cообщить модератору

	18. "Выпуск распределенной системы управления исходными текстами ..."	+1 +/–
	Сообщение от Anonymousqwe (?), 20-Окт-20, 16:21
	И sha256 тоже стандарт, только предыдущий.
	Ответить | Правка | Наверх | Cообщить модератору

	25. "Выпуск распределенной системы управления исходными текстами ..."	–2 +/–
	Сообщение от Аноним (13), 20-Окт-20, 16:50
	те использоваться уже не должен ибо выявлены проблемы в sha1 и sha2. использовать нужно sha3
	Ответить | Правка | Наверх | Cообщить модератору

	36. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от Аноним (36), 20-Окт-20, 18:10
	А ну-ка, на бис, какие ПРОБЛЕМЫ выявлены в SHA2?
	Ответить | Правка | Наверх | Cообщить модератору

	40. "Выпуск распределенной системы управления исходными текстами ..."	–3 +/–
	Сообщение от Аноним (13), 20-Окт-20, 18:33
	недостаточная стойкость к коллизиям очевидно
	Ответить | Правка | Наверх | Cообщить модератору

	84. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от funny.falcon (?), 21-Окт-20, 08:48
	Пруфлинк, пожалуйста. В SHA2 (а sha256 - это тоже sha2) пока что не найдено даже теоретических уязвимостей. SHA3 принимали не потому, что SHA2 был сломан, а потому, что SHA2 построен по принципу, похожему на SHA1 (который сейчас условно сломан). Опасаясь ВОЗМОЖНОГО ПОЯВЛЕНИЯ уязвимостей в SHA2, было решено принять параллельно стандарт SHA3, чтобы был алгоритм, не похожий на SHA2. Потому, кстати, победил Keccak, а не Blake/Blake2, которые в софтварной реализации заметно быстрее.
	Ответить | Правка | Наверх | Cообщить модератору

	114. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от Аноним (13), 21-Окт-20, 17:15
	В марте 2008 года индийские исследователи Сомитра Кумар Санадия и Палаш Саркар опубликовали найденные ими коллизии для 22 итераций SHA-256 и SHA-512.В сентябре того же года они представили метод конструирования коллизий для усечённых вариантов SHA-2 (21 итерация). Позднее были найдены методы конструирования коллизий для 31 итерации SHA-256 и для 27 итераций SHA-512.
	Ответить | Правка | Наверх | Cообщить модератору

	149. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от microsoft (?), 31-Окт-20, 02:48
	Сейчас тебе скажут что это другое
	Ответить | Правка | Наверх | Cообщить модератору

	34. "Выпуск распределенной системы управления исходными текстами ..."	+1 +/–
	Сообщение от кэп (?), 20-Окт-20, 17:48
	> sha256 тоже стандарт нет, sha256 это sha2 с увеличеным размером хэша
	Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

	64. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от Аноним (132), 21-Окт-20, 00:00
	Это стандарт NiStA.
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

16. "Выпуск распределенной системы управления исходными текстами ..."	+/–
Сообщение от Аноним (16), 20-Окт-20, 16:18
А как бы это сделать pull не для текущей ветки, но и не переключаясь на ветку которую стягиваешь. Например чтобы посмотреть в ней что менялось и подмержить
Ответить | Правка | Наверх | Cообщить модератору

	17. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от Аноним (13), 20-Окт-20, 16:21
	напиши скрипт который будет переключатся, делать pull и переключаться назад. а вообще fetch -a
	Ответить | Правка | Наверх | Cообщить модератору

	28. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от Аноним (16), 20-Окт-20, 16:52
	Как всегда всё гениальное просто... просто проскочило мимо меня) Спасибо
	Ответить | Правка | Наверх | Cообщить модератору

	20. "Выпуск распределенной системы управления исходными текстами ..."	–4 +/–
	Сообщение от Аноним (24), 20-Окт-20, 16:42
	Через гитлаб например мышкой.
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

	21. "Выпуск распределенной системы управления исходными текстами ..."	+1 +/–
	Сообщение от Аноним (24), 20-Окт-20, 16:43
	Чушь написал. Думал речь про пулл реквест, а не пулл.
	Ответить | Правка | Наверх | Cообщить модератору

	29. "Выпуск распределенной системы управления исходными текстами ..."	+3 +/–
	Сообщение от all_glory_to_the_hypnotoad (ok), 20-Окт-20, 16:57
	Мб тебе нужен git fetch
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

23. "Выпуск распределенной системы управления исходными текстами ..."	+1 +/–
Сообщение от Аноним (24), 20-Окт-20, 16:45
>>Изначально планировалось использовать алгоритм SHA3-256, но в конечном счёте разработчики остановились на SHA2-256 >>На данном этапе можно лишь выбрать между SHA-1 и SHA-256 Так SHA2-256 или SHA-256 добавили? Или это одно и тоже?
Ответить | Правка | Наверх | Cообщить модератору

	27. "Выпуск распределенной системы управления исходными текстами ..."	–1 +/–
	Сообщение от Аноним (13), 20-Окт-20, 16:51
	SHA-256 это SHA1-256
	Ответить | Правка | Наверх | Cообщить модератору

	37. "Выпуск распределенной системы управления исходными текстами ..."	+3 +/–
	Сообщение от Аноним (36), 20-Окт-20, 18:11
	Нет.
	Ответить | Правка | Наверх | Cообщить модератору

	39. "Выпуск распределенной системы управления исходными текстами ..."	+2 +/–
	Сообщение от Аноним (36), 20-Окт-20, 18:14
	Из педивикии: === 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
	Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

32. "Выпуск распределенной системы управления исходными текстами ..."	+/–
Сообщение от Козлетто (?), 20-Окт-20, 17:27
Интересно почему СКВ популярно только у программистов? Теоретически они могут полезны везде где есть часто изменяемые файлы и необходимость командной работе с ними. А то бухгалтеры и дизайнеры плодят 100500 файлов _копия100500 где в этой помойке не разберёшь где что лежит
Ответить | Правка | Наверх | Cообщить модератору

	41. "Выпуск распределенной системы управления исходными текстами ..."	+2 +/–
	Сообщение от JL2001 (ok), 20-Окт-20, 18:35
	> Интересно почему СКВ популярно только у программистов? Теоретически они могут полезны везде > где есть часто изменяемые файлы и необходимость командной работе с ними. > А то бухгалтеры и дизайнеры плодят 100500 файлов _копия100500 где в > этой помойке не разберёшь где что лежит потому что у ворда (и майкрософтофиса) бинарные и проприетарные форматы но я присоединяюсь к вашему недоумению
	Ответить | Правка | Наверх | Cообщить модератору

	44. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от Козлетто (?), 20-Окт-20, 18:52
	>> Интересно почему СКВ популярно только у программистов? Теоретически они могут полезны везде >> где есть часто изменяемые файлы и необходимость командной работе с ними. >> А то бухгалтеры и дизайнеры плодят 100500 файлов _копия100500 где в >> этой помойке не разберёшь где что лежит > потому что у ворда (и майкрософтофиса) бинарные и проприетарные форматы > но я присоединяюсь к вашему недоумению А что мешает этом ворду или другой аналогичной программе использовать текстовый недеструктивный формат? Вендорлок?
	Ответить | Правка | Наверх | Cообщить модератору

	60. "Выпуск распределенной системы управления исходными текстами ..."	+1 +/–
	Сообщение от anonymous yet another (?), 20-Окт-20, 21:11
	Микрософт ;) Вообще-то в MS Word есть встроенный контроль версий. Пригодность к использованию по назначению --- не знаю, я word'ом не пользуюсь. Судя по тому, что об этом почти никто не знает, наверное не пригодно. Там много чего интересного при желании можно найти. Я из присланной рекрутёрами описания вакансии ради интереса достал оттуда: компанию, запостившую вакансию, дату когда её создали, имена hr-ов в оригинальной компании и рекрутинговом агенстве, имя заинтересованного руководителя, примерное количество соискателей на эту вакансию и динамику изменений требований к кандидату, включая денежное довольствие (откуда следовало, что с наймом на эту позицию проблемы).
	Ответить | Правка | Наверх | Cообщить модератору

	73. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от Crazy Alex (ok), 21-Окт-20, 02:27
	Вполне пригодно и активно используется. В либре аналогичное есть. Проблема скорее в том, что общая культура работы с данными в ворде в среднем по больнице чудовищна - ну там, на одного учёного тысяча секретарш, которые даже стили не понимают.
	Ответить | Правка | Наверх | Cообщить модератору

	77. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от GG (ok), 21-Окт-20, 05:02
	У учёных тоже каша в головах. То ли дело писатели, вот у этих гит хорошо заходит.
	Ответить | Правка | Наверх | Cообщить модератору

	108. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от anonymous yet another (?), 21-Окт-20, 16:40
	Беда в том, что чувствительная информация регулярно утекает незаметно для потребителя. И сделано так (по крайней мере, было; есть ли сейчас?) "из коробки".
	Ответить | Правка | К родителю #73 | Наверх | Cообщить модератору

	61. "Выпуск распределенной системы управления исходными текстами ..."	–2 +/–
	Сообщение от fuggy (ok), 20-Окт-20, 21:15
	На самом деле всё просто. Бинарные файлы тоже можно сравнивать. Достаточно $ git config diff.word.textconv docx2txt $ echo '*.docx diff=word' > .gitattributes Если документы хранятся в репозитории, то можно легко их сравнить. Конечно форматирование теряется, но программистам и не нужно форматирование. А бухгалтеры всё равно не смогут использовать даже GUI git, чтобы делать это. Если только обёртку для этого написать, но мёржить всё равно не получится, проще их на markdown пересадить.
	Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

	65. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от Аноним (62), 21-Окт-20, 00:00
	Уже давно не бинарные
	Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

	66. "Выпуск распределенной системы управления исходными текстами ..."	–1 +/–
	Сообщение от Аноним (132), 21-Окт-20, 00:03
	Дело не в бинарном формате, а в том, что все существующие стабильные системы контроля версий - текстовые. То есть подходят только для исходников и плейн текста, и то очень плохо. А нужна система для DAGов, а не последовательностей строк.
	Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

	120. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от пох. (?), 21-Окт-20, 18:46
	> Дело не в бинарном формате, а в том, что все существующие стабильные системы контроля версий - > текстовые. хуже - они линейно-ориентированные. html - это в общем текстовый файл. Только от добавления лишнего пробела или переноса строки, ВНЕЗАПНО, не только не портится, как модные-современные форматы, а хуже того - в результирующем его отображении не меняется НИЧЕГО. > То есть подходят только для исходников и плейн текста именно так. Причем для исходников не на пихоне тоже неудобны - приходится добавлять отдельные костыли и подпорки для борьбы с лишним пробелом (а перенос по прежнему неизлечим). Но с вордом (и экселом) прикол в том, что они ТОЖЕ линейно-ориентированные, хотя и не плейнтекст. И показать что вот в этой строке поменяли а на б а вон та просто сдвинута ниже - вполне можно. Просто не ждите от шва6одкоистерическ подобного инструмента. Включая для шва6одкиных форматов шва6одкоофиса, не на тех напали. Коммерческие - лет десять назад вполне успешно существовали, к сожалению, мне тогда были без пользы, поэтому названий не вспомню.
	Ответить | Правка | Наверх | Cообщить модератору

	95. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от пох. (?), 21-Окт-20, 11:40
	> потому что у ворда (и майкрософтофиса) бинарные и проприетарные форматы средства для трекинга изменений в которых (пусть бинарные и проприетарные) существуют уже лет двадцать. > но я присоединяюсь к вашему недоумению спи спокойно, твоей шва6одке они не угрожают Сравнить два .odt ты сможешь примерно никогда.
	Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

	118. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от Аноним (8), 21-Окт-20, 18:28
	А какая разница? diff это капля в море возможностей vcs. Посмотреть "как было" и "как стало" можно с абсолютно любым форматом, плюс кто и когда что-то менял. А если постараться, можно и diff сделать. Например, github замечательно умеет diff картинок.
	Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

	51. "Выпуск распределенной системы управления исходными текстами ..."	–1 +/–
	Сообщение от Michael Shigorin (ok), 20-Окт-20, 19:48
	> Интересно почему СКВ популярно только у программистов? Ну почему, в девяностые вроде как и у бухгалтеров с дизайнерами СКВ бывали популярны...
	Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

	52. "Выпуск распределенной системы управления исходными текстами ..."	–2 +/–
	Сообщение от Аноним (3), 20-Окт-20, 20:06
	Лично я загнал себя в задницу тысячами и тысячами файлов разных версий на диске. Они ещё и названы могут быть различно (а могут и одно и то же имя иметь). Единственное решение, которое я сейчас вижу, это при любом сохранении файла на диске, принудительно требовать добавлять дополнительную инфу (вроде содержимого и версии, даты), ссылку на онлайн источник, дополнительно извлекать данные о времени последнего изменения файлов в архиве, и всё это пихать в кдеешный semantic desktop (если бы он ещё не обнулялся рандомно). Файлы то относительно небольшие: 10 гигабайт туда, 15 гигабайт сюда, три тысячи тысячи файлов по 4 гигабайта вон там и там, пойди разберись и рассортируй. И это всё за полгода. Когда файлы повторяются, но они разные, это начинает немного напряхать, потом по 10 версий одного файла и найди последний/нужный.
	Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

	56. "Выпуск распределенной системы управления исходными текстами ..."	–2 +/–
	Сообщение от Аноним (3), 20-Окт-20, 20:43
	Главная боль в том, что данные рандомно обновляются. И мне что-то не хватает кнопки СРАВНИТЬ ФАЙЛЫ ПРОХЕШИРОВАВ ОБА в кде, когда предлагает заменить файл с одинаковым именем. Там может несколько байт поменялось, НО ОНИ ВАЖНЫЕ. Как люди вообще с файлами работают? Что-либо найти вообще тяжело, файлы называют чёрте как. Но реально, принудительное тагирование нормальными данными наверное бы помогло.  Все эти файлы замечательно копятся и потом не ясно куда делись десятки терабайт, а тебе срочно нужны терабайты под какие-то данные, а всё забито мусором и частичными дубликатами.
	Ответить | Правка | Наверх | Cообщить модератору

	99. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от Ordu (ok), 21-Окт-20, 13:45
	> Как люди вообще с файлами работают? Твой case описан крайне мутно, сложно дать конкретный совет. Я упорядочиваю ебуки в чём-то типа wiki построенной на org-mode файликах. Мне плюс-минус пофигу как там называются файлы, потому как если мне что-то надо, я ищу это в org-mode по тегам или ключевым словам, и там есть ссылки на файлы. edit: есть универсальный совет под такие проблемы: lisp. lisp позволяет смешивать описание данных и код. То есть ты начинаешь описывать данные в виде s-expressions, а потом добавляешь обвязку, которая автоматизирует самые болезненные действия. Тут я могу порекомендовать [1], в качестве введения в тему. Это правда common lisp, а не что-нибудь хипстерское типа scheme или racket. Но переключиться с CL на scheme/racket не так уж и сложно. [1] http://www.gigamonkeys.com/book/
	Ответить | Правка | Наверх | Cообщить модератору

	109. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от Аноним (3), 21-Окт-20, 16:43
	Мне нужно управление файлами, полученными из интернета. Допустим, я знаю, что ищу, но найти это, не проследовав на источник в интернете и не получив из него имя искомого файла и дату последнего изменения (а в самом лучшем случае и хэш), не представляется возможным: если я открываю архив. я вижу в нём какие-то бинарные файлы, и что дальше? По соседству может лежать точно такой же файл, более старый по времени изменения и имеющий тот же самый размер, но по факту это более новый файл с кучей изменений. Всё-таки, юзабилити нынешних файловых менеджеров не очень высокое. Было бы неплохо интегрировать систему файл менеджмента (я пока только реализовал подгрузку сведений из интернета, но где-то придётся запускать браузер из-за скриптов и это уже не удобно).
	Ответить | Правка | Наверх | Cообщить модератору

	110. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от Аноним (3), 21-Окт-20, 16:47
	Мне кажется, в случае с архивами, можно просканировать файл на предмет самого последнего изменения для всех файлов в архиве. Не поможет для изврата, где время изменения подделали, но в целом должно быть нормально. Но это работает только с архивами, с бинарями не получится и тут только считать хэш -- это единственная доступная инфа. Если бы существовал реестр загрузок, хэши для всех файлов в него вполне можно было бы и сохранять. Но они долго считаются. Т_Т
	Ответить | Правка | Наверх | Cообщить модератору

	111. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от Аноним (3), 21-Окт-20, 16:51
	В идеале было бы в процессе загрузки хэши считать. Ну т.е. если скачивать будет скрипт вместо браузера, он может и добавлять всё куда нужно. Однако это мнее удобно, наверное. И опять же проблема: страницы генерируются скриптами, нужно решать капчи, и прочее такое. Почему никто не напишет такое ПО?
	Ответить | Правка | Наверх | Cообщить модератору

	113. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от Аноним (3), 21-Окт-20, 17:02
	А вот тут что-то можно сделать. Время изменения для локального файла выставлять по последнему обновлённому файлу в архиве. У локального файла архива всё ещё остаётся время создания (даже два, но с ними всегда путаница и второе в glibc только недавно добавили).
	Ответить | Правка | К родителю #110 | Наверх | Cообщить модератору

	126. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от Аноним (3), 21-Окт-20, 21:46
	Я имею в виду, я это сделал (шелл, правда), но это не информация об удалённом файле. В принципе, так даже лучше, да? Не знаю.
	Ответить | Правка | Наверх | Cообщить модератору

	117. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от Аноним (8), 21-Окт-20, 18:25
	Это просто мера уровня специалиста. Всё что может периодически изменяться руками нет смысла не хранить в vcs. Да, не для всего можно сделать diff, но diff это только один малюсенький аспект работы с VCS. Посмотреть как было, как стало, кто и когда изменил можно абсолютно всегда. И очень часто нужно.
	Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

85. "Выпуск распределенной системы управления исходными текстами ..."	+/–
Сообщение от Аноним (132), 21-Окт-20, 09:23
>Также пока ни один Git-провайдер, включая GitHub, не поддерживает репозитории с хэшами SHA-256. Насколько я помню, в доках по гиту было написано, что сначала сделают фичу локально, а уже потом начнут делать транспорт по сети.
Ответить | Правка | Наверх | Cообщить модератору

	148. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от Javaist (?), 24-Окт-20, 18:16
	У них даже локально не все работает, например gitk.
	Ответить | Правка | Наверх | Cообщить модератору

144. "Выпуск распределенной системы управления исходными текстами ..."	+/–
Сообщение от Javaist (?), 23-Окт-20, 21:44
Уже 2.29.1 вышел https://github.com/git/git/commit/b927c80531cca9b91077541865...
Ответить | Правка | Наверх | Cообщить модератору

	146. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от Козлетто (?), 24-Окт-20, 09:22
	> Уже 2.29.1 вышел > https://github.com/git/git/commit/b927c80531cca9b91077541865... GVF=GIT-VERSION-FILE - DEF_VER=v2.29.0 + DEF_VER=v2.29.1 и весь релиз
	Ответить | Правка | Наверх | Cообщить модератору

	147. "Выпуск распределенной системы управления исходными текстами ..."	+/–
	Сообщение от Javaist (?), 24-Окт-20, 18:15
	Это лишь один комминт, там ещё есть. В описании ведь написано что изменилось или ты не читал?
	Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема