1.1, Аноним (1), 15:03, 20/10/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –8 +/– |
Читая чейнджлоги, мне каждый раз мерещится, что git из простой булки белого (или черного) хлеба превращается в трамвай. Надеюсь просто мерещится.
| |
|
2.2, Аноним (2), 15:08, 20/10/2020 [^] [^^] [^^^] [ответить]
| +20 +/– |
В какой момент git был простым? Довольно сложная VCS с момента рождения, просто он стал индустриальным стандартом.
| |
|
3.14, m.makhno (ok), 16:01, 20/10/2020 [^] [^^] [^^^] [ответить]
| –2 +/– |
Сложный он ровно до того момента, пока не проникнешься его философией. А дальше уже не понимаешь, как раньше жил до этого знакового знакомства. Потом, правда, приходится разбираться ещё с трактовками его фич разномастными хостингами, с их модно-молодёжными workflow's.
| |
|
|
Часть нити удалена модератором |
5.24, Аноним (24), 16:46, 20/10/2020 [ответить]
| +8 +/– |
Имеется в виду что сначала нужно освоить vi и emacs и тогда уже гит будет казаться простым.
| |
|
4.53, TheFotoMag (ok), 20:19, 20/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
> пока не проникнешься его философией. А дальше уже не понимаешь, как раньше жил
Бешено плюсую.
| |
4.93, Аноним (2), 11:36, 21/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
Ну так про все что угодно можно сказать, haskel сложен пока не проникнешься его философией, многомерные пространства сложны пока не проникнешься их философией.
Помню когда начал работать с git первые пол года перед каждым шагом делал tar czvf. До сих пор без заглядывания в заметки не смогу назвать команду для откатывания коммитов, путаю git clean и git reset. Пользуюсь гит с 2012 года.
| |
|
5.98, Ordu (ok), 13:33, 21/10/2020 [^] [^^] [^^^] [ответить] | +1 +/– | Если ты заглядываешь в заметки и не можешь запомнить команды не потому, что тебе... большой текст свёрнут, показать | |
|
6.100, Аноним (2), 14:11, 21/10/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Как много текста ни о чем. У git сложный CLI. Чуть более предметно.
Кейс 1:
Я случайно закомител лишний файл, но еще не отправил коммит на удаленный репозитарий. Как мне убрать лишний файл из последнего коммита?
Я могу только заглянуть в заметки и вытащить от туда команду: git reset 'HEAD@{1}', после которой я повторяю заново коммит без этого файла.
Кейс 2:
Я случайно добавил в индекс лишний файл, как его убрать из индекса не удалив. Я вот не помню, кажется через reset. Мне надо опять заглянуть в заметки.
> Я б рекомендовал подумать об использовании другой vcs, которая не будет вызывать такого желания.
Так GIT стандарт, где не работал везде гит, я пользуюсь тем что есть.
| |
|
7.102, Аноним (2), 14:39, 21/10/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Ну и раз я критикую, я хотел бы сказать какой CLI на мой взгляд был бы более понятным:
git rm удалить файл с диска
git rmi удалить файл из индекса
git undo [N] - отменить последние N действий
git squash N - объединить последние N коммитов в один.
git squash 772e40f-fe89105 - объединить указанные коммиты в один.
| |
|
8.104, Ordu (ok), 15:58, 21/10/2020 [^] [^^] [^^^] [ответить] | +/– | Напиши скрипт, проблем-то Эмм Это как В список отменяемых действий включать... текст свёрнут, показать | |
|
9.106, Аноним (2), 16:16, 21/10/2020 [^] [^^] [^^^] [ответить] | +1 +/– | Я и пользуюсь rebase, в vi меняю строчки на squash нужных мне коммитов, только д... текст свёрнут, показать | |
|
10.112, Ordu (ok), 16:58, 21/10/2020 [^] [^^] [^^^] [ответить] | +/– | Прикинь, я впервые вижу команду git rebase --interactive HEAD N Я даже не уве... большой текст свёрнут, показать | |
|
11.122, Аноним (2), 19:52, 21/10/2020 [^] [^^] [^^^] [ответить] | +/– | А можно знать три аккорда и играть боем Использую как terminal multiplexer, на... большой текст свёрнут, показать | |
|
12.124, Ordu (ok), 21:01, 21/10/2020 [^] [^^] [^^^] [ответить] | +/– | Один член тут моторные навыки Надо пальцами попадать по ладам в нужных местах, ... большой текст свёрнут, показать | |
|
|
14.129, Ordu (ok), 22:50, 21/10/2020 [^] [^^] [^^^] [ответить] | +/– | Потому что ты причину ищешь снаружи своей психики, хотя она прячется внутри Ты ... большой текст свёрнут, показать | |
|
|
|
|
|
|
|
7.103, Ordu (ok), 15:56, 21/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
>> Я б рекомендовал подумать об использовании другой vcs, которая не будет вызывать такого желания.
> Так GIT стандарт, где не работал везде гит, я пользуюсь тем что
> есть.
Если ситуация такова, то значит надо одолевать свои психологические причины не справляться с git и искать способ справляться. git -- это просто, если тебе сложно, значит что-то ты делаешь не так.
| |
7.121, Аноним (2), 19:07, 21/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
Кстати я тут ошибся указав git reset 'HEAD@{1}', в моих заметках сказано что это делает UNDO для UNDO, видно из-за простоты git этого никто пока не заметил.
А UNDO коммита как написал товарищ выше: git reset --soft HEAD~
Прямо очень интуитивно, я как вижу git reset --soft HEAD~ так сразу понимаю что это откатывает коммит, проще пареной репы.
| |
|
|
|
|
3.26, all_glory_to_the_hypnotoad (ok), 16:50, 20/10/2020 [^] [^^] [^^^] [ответить]
| –3 +/– |
Это абсолютная чушь, Git простой как топор. Проще SVN, HG и многих других VCS. Потому у меня обратный вопрос - почему важные архитектурные изменения (развитие протокола, поддержка нескольких хешей и т.д.) происходят медленно, но коммитов стабильно не мало. Я, например, за 627 своих типичных изменений по объёму мог бы почти полностью переписать такой пакет и значительно доработать архитектурно.
| |
|
4.33, an0nymous (?), 17:35, 20/10/2020 [^] [^^] [^^^] [ответить]
| +2 +/– |
>Проще SVN, HG
Какой наброс. Документация по гиту такая кхмм.. подробная, что иногда выть хочется.
По моиму опыту обучить гиту НЕПРОГРАММИСТА (чтобы он ничего не ломал ничего и осозновал что делает) на порядки сложнее чем тот же hg. в нем много лишних абстракций торчат наружу, которые могли бы быть скрыты и интерфейс стал бы проще.
| |
|
5.89, пох. (?), 10:04, 21/10/2020 [^] [^^] [^^^] [ответить] | +/– | поскольку гит представляет собой не человеческую программу, исполняющую ровно од... большой текст свёрнут, показать | |
|
6.97, anonymous yet another (?), 12:51, 21/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
Вы транслируете мнение совершенно не разбирающегося в архитектурах VCS. С желаниями от "configurations management" и игнорированием всего остального.
| |
|
5.101, all_glory_to_the_hypnotoad (ok), 14:29, 21/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
в Git примерно всего две простых абстракции - это ADG и индекс. В SVN одна простая с линеной историей, одна мозговыносящая связанная с ветками, тэгами и мержами директорий в директории (не видел как пользователи копируют trunk в NNN GiB в trunk?), и ещё некоторое кол-во поменьше. В Hg одних веток только несколько штук, в плане неконсистентности это самая yблюдочная VCS.
Документации к Git больше если сравнивать c, например, svn, просто потому что в Git значильно больше функциональности. Однако это не означает что для работы нужно знать всё и всем пользоваться. Чтобы странный пользователь ничего плохого не делал есть прекоммитные хуки, причём ими пользуются во всех VCS для ограничения деятельности альтернативно одарённых персонажей.
| |
|
4.54, TheFotoMag (ok), 20:27, 20/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Git простой как топор
Судя по непрязни к Гиту — ни один его критик к разработке не имеет никакого отношения.
Все просто: без контроля версий жить нельзя. ДЕНЬГИ!!! Затраты на разработку растут на порядок!!!
Бабушиным внукам такие вещи по%уй, они не оплачивают команду из своего кармана и уверены, что бабушкина пенсия растет на дереве.
Мне пришлось попробовать всё и Гит — САМЫЙ ВЫГОДНЫЙ вариант. ТОЧКА!!!
| |
|
5.55, TheFotoMag (ok), 20:30, 20/10/2020 [^] [^^] [^^^] [ответить]
| –3 +/– |
>> Git простой как топор
> Судя по непрязни к Гиту — ни один его критик к разработке
> не имеет никакого отношения.
> Все просто: без контроля версий жить нельзя. ДЕНЬГИ!!! Затраты на разработку растут
> на порядок!!!
> Бабушиным внукам такие вещи по%уй, они не оплачивают команду из своего кармана
> и уверены, что бабушкина пенсия растет на дереве.
> Мне пришлось попробовать всё и Гит — САМЫЙ ВЫГОДНЫЙ вариант. ТОЧКА!!!
Продолжая заочную дискуссию с безработными энтузиастами открытых решений — JIRA. Без нее тоже никак.
| |
|
6.81, nomad__ (ok), 07:49, 21/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
> JIRA. Без нее тоже никак
очень даже как, потому что есть Redmine.
| |
|
5.87, пох. (?), 09:53, 21/10/2020 [^] [^^] [^^^] [ответить] | +/– | утипупсичек, ну конечно же Все просто кроме тебя, вчерародившегося, тут есть е... большой текст свёрнут, показать | |
|
4.75, GG (ok), 04:57, 21/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
Ну перепиши и доработай, все тебе будут благодарны и может даже денег отсыплют
| |
|
3.57, anonymous yet another (?), 20:44, 20/10/2020 [^] [^^] [^^^] [ответить]
| –2 +/– |
Если тут есть люди, имеющие отношение к психологии или преподаванию (чего-либо, не важно) --- поясните, пожалуйста, вероятную мотивацию жмыхателей на значки +/- к комментариям 3.26 и 3.14. Спасибо.
| |
|
4.76, GG (ok), 04:58, 21/10/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Увидели что там уже есть +/- и добавили свой чтобы не выделяться из толпы
| |
|
5.142, n242name (?), 20:17, 23/10/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
вхуярил тебе минус, а у тебя стоял там плюс, наверное, доморощенный ты психолог, это потому что я хочу выделиться из толпы?
| |
|
4.145, n00by (ok), 08:47, 24/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
В 3.26 -- за вводный негативный заряд "Это абсолютная чушь". Далее комментарий дельный, но не все дочитали.
В 3.14 вывод в споре о вкусах навязывается заметно мягче ("Сложный он ровно до того момента, пока не проникнешься его философией"), но оратор напрасно попытался обобщить субъективный опыт. Люди разные, одним таблицу умножения проще зазубрить, другим каждый раз заново в уме столбиком складывать.
| |
|
|
2.86, пох. (?), 09:45, 21/10/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
конечно мерещится - он всегда был троллейбусом из буханки, причем с квадратными колесами. Как он может превратиться в трамвай?!
| |
|
1.3, Аноним (3), 15:12, 20/10/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –5 +/– |
Хэши в постквантумную эпоху пострадают? А то планируют на 5 лет, а дальше хоть трава не расти.
| |
|
2.4, myhand (ok), 15:25, 20/10/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Хэши в постквантумную эпоху пострадают?
Вся современная криптография пострадает. Факторизация со скоростью умножения - это вам не шутки!
> А то планируют на 5 лет
А вы уже запаслись пророчеством Нострадамуса когда она настанет, эпоха энта? Отсыпите?
| |
|
3.19, Аноним (3), 16:23, 20/10/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
Ну вон каждый день заявляют о квантум супремасэ, и вроде довольно близко продвинулись уже. Скоро придём к тому, что вся "криптография" будет на запутанных частицах (вроде там сбер что-то такое делал ГОДА 4 НАЗАД), где вмешательство будет исключено. Изначально выбрать sha1 было примерно как выбрать des, а теперь поменять на 3des,
| |
|
4.38, rshadow (ok), 18:12, 20/10/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Еще далеко. Если корпорации и смогут, то ломать чужое это уголовка. Опасно для бизнеса. У спецслужб и так все есть. Надо ждать массовый сектор, а его пока в планах не видно.
| |
|
5.91, Аноним (91), 10:30, 21/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
> У спецслужб и так все есть
ага, два раза есть.
[sarcasm]
и у сбера также
| |
5.132, Аноним (132), 07:05, 22/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
А обработка персональных данных без согласия - это что? Я вот банку передал давным давно бумагу, что отзываю согласие на обработку персональных данных, и требую произвести их уничтожение, а также всех их копий у всех контрагентов. И даже подписи работников банка на своём экземпляре вытребовал.
Однако до сих пор СМС приходят "Для вас предварительно одобрен кредит, такая-то ставка, вы его можете взять, просто заявившись в отделение", хотя я сроду кредитов никогда не брал.
| |
|
4.67, Ivan_83 (ok), 00:14, 21/10/2020 [^] [^^] [^^^] [ответить]
| +2 +/– |
Кавантовые компы угроза для ассимтричной крипты, но не для хэшей и симметричной крипты.
Когда Линус начнал гит кажется sha2 ещё не было.
sha2-256 ещё удобен тем что аппаратно есть в райзенах, впрочем sha1 тоже есть.
А вот sha2-512 и sha3 аппратно пока нет.
| |
|
3.45, n00by (ok), 18:57, 20/10/2020 [^] [^^] [^^^] [ответить]
| +3 +/– |
>> Хэши в постквантумную эпоху пострадают?
> Вся современная криптография пострадает. Факторизация со скоростью умножения - это вам
> не шутки!
Факторизация чего? Вы типа думаете, что поля Галуа - это по которым гулял некий французский дяденька?
| |
|
|
5.83, funny.falcon (?), 08:38, 21/10/2020 [^] [^^] [^^^] [ответить]
| +2 +/– |
А при чем тут SHA в любой ипостаси? Вы с RSA не перепутали?
А для эллиптических кривых уже квантовые алгоритмы есть?
| |
|
6.139, myhand (ok), 17:46, 22/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
> А при чем тут SHA в любой ипостаси?
При том. что алгоритм Гровера. С SHA-2 тут, насколько я знаю, "все не так однозначно" (ц).
> А для эллиптических кривых уже квантовые алгоритмы есть?
В смысле? Тут тот же алгоритм Шора может быть использован.
| |
6.143, n242name (?), 21:22, 23/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
насколько я курил вопрос - уже есть, однако появилась криптография на изогениях, но все в зародышевым состоянии
| |
|
|
|
|
2.35, Аноним (35), 18:06, 20/10/2020 [^] [^^] [^^^] [ответить]
| +3 +/– |
не особо. Может быть, когда-нибудь придется увеличить размер хэша например до 384 бит, но придумывать новые алгоритмы нет нужды. От квантовых вычислений страдает только асимметричное шифрование
| |
|
3.48, Аноним (3), 19:27, 20/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
Я слышал оценки в районе 4096 для RSA. И то, это скорее потому, что теоретическая база для эффективного квантового подбора таких ключей пока не существует.
| |
|
2.63, Аноним (132), 23:58, 20/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
Алгоритм Гровера только квадратичное ускорение даёт, по сравнению с экспоненциальным для Шора.
| |
|
1.5, б.б. (?), 15:25, 20/10/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
о, крутая вещь. а есть hg-репозиторий, где можно его скачать?
| |
1.6, Аноним (6), 15:37, 20/10/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –4 +/– |
А я до сих пор пользуюсь SubVersion и всегда с улыбкой смотрю на очередные новости про гит и хг, и про ребейспроблемы
| |
|
2.8, Аноним (8), 15:44, 20/10/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
Обычно с улыбкой смотрят на болванчиков которые без интернета не могут ни коммит, ни лог сделать, а чтобы переключиться на другую задачу им приходится изменённые файлы двигать. А на тех кто крупное изменение льёт одним коммитом, потому что rebase чтобы разбить его на топики не умеет, смотрят без улыбки и просто указывают им на дверь.
| |
|
|
|
5.42, Козлетто (?), 18:47, 20/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
> На дверь из IT конторы очевидно, потому что профнепригодность.
А у нас в ТИУ на "Информационные системы и технология" кроме меня даже о гите и краем уха не слыхали, а уж тем более о всяких rebase и СКВ вообще подавно.
| |
|
6.43, Козлетто (?), 18:47, 20/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
>> На дверь из IT конторы очевидно, потому что профнепригодность.
> А у нас в ТИУ на "Информационные системы и технология" кроме меня
> даже о гите и краем уха не слыхали, а уж тем
> более о всяких rebase и СКВ вообще подавно.
И не только студенты, но и преподы
| |
|
5.46, Аноним (46), 19:00, 20/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
Смешно конечно такие писульки читать, профнепригодность из-за того что коммиты большие?
Походу у вас какие-то спартанские порядки в конторе. Все пишут по-разному, в том числе и в опер сорсе коммиты в 2 десятка файлов иногда встречаются. Обычно это вопрос договорённости в команде.
До сих пор смешно с такого детского максимализма, ну до поделать, хорошо что я не в такой команде)
| |
|
6.68, Аноним (8), 00:53, 21/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
При чём тут максимализм? Факт 1 - есть code review. Факт 2 - мегакоммит невозможно качественно поревьюить. Поэтому в отличие от профпригодности ревьюера такой коммит либо идёт в прод непоревьюеным, либо заворачивается. В первом случае это рано или поздно ломает прод, во втором разработчик не выполняет свою прямую работу. В результате в обоих случаях отправляется в дворники. Ну либо учится git и rebase и делает ветки из маленьких, атомарных, легко обозримых коммитов.
| |
|
7.72, Crazy Alex (ok), 02:20, 21/10/2020 [^] [^^] [^^^] [ответить]
| +3 +/– |
Человек что-то лабает на коленке и что такое промышленное программирование не понимает. Бывает, убеждать бесполезно пока сам не побьётся.
| |
|
|
|
|
3.30, freehck (ok), 17:15, 20/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
Ох уж это российская любовь к ребейзам. Чем вам просто мерджить-то не нравится? "Не аккуратненько"? =/
| |
|
4.59, anana (?), 20:57, 20/10/2020 [^] [^^] [^^^] [ответить]
| +2 +/– |
Мёржи превращают историю в нечитабельное месиво.
Ребейзы (при правильном использовании) делают красивую линеаризованную историю, где каждый коммит в истории на своём месте и сразу понятно что и когда кто делал (точнее заканчивал делать).
Разумеется там где разработчики не пишут описания изменений и смешивают пачку несвязных изменений в один коммит - мёрж / не мёрж уже ничего не поменяет.
| |
|
5.92, freehck (ok), 11:27, 21/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Мёржи превращают историю в нечитабельное месиво.
Это не мёрджи. Это неотлаженный воркфлоу.
| |
|
4.69, Аноним (8), 00:56, 21/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
Чтобы вмержить ветку, её нужно сначала отребейзить (совершенно не обязательно на свежий master) и причесать - фиксы опечаток влить в те коммиты где опечатки были сделаны, большие коммиты разбить и т.д.
| |
|
|
4.70, Аноним (8), 01:00, 21/10/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Такое говорили 15 лет назад неучи не видевшие и не хотевшие видеть нормальные VCS. Сейчас причесать ветку перед мержем - обязательное правило. Ребейз ветки на master (т.е. с перемещением корня) - дело вкуса, но по мне так нелинейная история допустима только в совсем маленьких проектах, иначе (когда есть > 5 параллельных ветвей) читать её невозможно.
| |
4.131, Аноним (131), 06:28, 22/10/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
В торец надо тем, кто отправляет на ревью всю свою помойку коммитов, образовавшуюся естественным образом в ходе работы. Ревьюера не волнует, какие ты ошибки сделал в ходе работы и как их исправил. Его интересует конечный результат.
| |
|
5.134, пох. (?), 09:51, 22/10/2020 [^] [^^] [^^^] [ответить] | +/– | конечный результат в случае не двустрочного исправления он оценить не сможет в п... большой текст свёрнут, показать | |
|
|
|
2.13, Аноним (13), 15:51, 20/10/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
просто ты замшелый пенек. какой нахер subversion? брось уже каку!
| |
2.47, Аноним (47), 19:05, 20/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
Zip с циферками еще круче, его все даже github использует, аж скулы от улыбки сводит.
| |
2.50, Michael Shigorin (ok), 19:45, 20/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
> ребейспроблемы
А что именно Вы предпринимаете в svn, когда надо свести две своих ветки -- например, в основной были мелкие исправления, которые местами пересекаются с текущей разработкой (возможно, где-то и конфликтуют)?
Я просто немного помню, как это выглядело с cvs. С гитом это хотя бы проблемы (в переводе на русский -- задачи), и проблемы решаемые, а не тот кромешный ужас, даже когда сервер рядом по локалке доступен.
| |
|
3.58, anonymous yet another (?), 20:56, 20/10/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Без server-side (священо)действий --- никак. Лочим доступ (когда на запись, а когда и вообще) на час--день--неделю, сливаем backup в сторонку, говорим "ой, мама" и трудимся. После открытия доступа слушаем матюки и угрозы, вжимаем голову в плечи, лочим доступ и пытаемся поправить то, что наворотили. Иногда приходится повторять всё несколько раз. Но вера в святой backup нас поддерживает.
| |
3.90, пох. (?), 10:21, 21/10/2020 [^] [^^] [^^^] [ответить] | –1 +/– | merge нужных изменений и - чем ТУТ поможет rebase Сломает ветку Спасибо, я об ... большой текст свёрнут, показать | |
|
2.71, Аноним (8), 01:04, 21/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
Недалёким неведомо что svn up при наличии незакоммиченных изменений в working copy делает ни что иное как ребейз [этих изменений на новый head].
| |
|
3.94, пох. (?), 11:38, 21/10/2020 [^] [^^] [^^^] [ответить] | –1 +/– | это мерж И более того, явный мерж делается точно так же - через working copy Н... большой текст свёрнут, показать | |
|
4.116, Аноним (8), 18:19, 21/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
> что rebase - это перенос _истории_, а не всех отличий пачкой без разбора. Эгмх...подделка истории, тоись ;-)
А нет никакой разницы разбиты изменения на отдельные коммиты или не разбиты, и вообще оформлены в виде коммитов или нет - в ваших терминах это в любом случае "подделка". С практической стороны в любом случае может произойти изменение в чужом коде которое сломает твоё изменение или тихо изменит его поведение, даже не вызвав конфликта.
| |
|
5.119, пох. (?), 18:38, 21/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
> С практической стороны в любом случае может произойти изменение в чужом коде которое сломает твоё
> изменение
не может - оно где-то в origin/чтототам происходит в терминах гита.
Твои комиты _никуда_ не денутся, и даже попортить автомагическим мержем НЕ закомиченое тебе не дадут. (Закомиченное - дадут, полагая что это именно то что ты хотел, но ты всегда можешь вернуть исходное состояние, это история.)
А в svn/cvs ничего из этого нет, и для работы с _чужими_ проектами это действительно проблема.
Подделка происходит при rebase. Поинтересуйся на досуге, что при этом на самом деле происходит с историей.
| |
5.133, пох. (?), 09:39, 22/10/2020 [^] [^^] [^^^] [ответить] | +/– | есть нет Подделка - это именно подделка истории, когда изменения придуманные и... большой текст свёрнут, показать | |
|
|
|
2.82, nomad__ (ok), 07:50, 21/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
> ребейспроблемы
например какие? А то вот уже 7 лет пользуюсь гитом и что-то не припомню проблем с rebase.
Перешел, кстати, с svn.
| |
|
1.7, Аноним (-), 15:44, 20/10/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– |
Какой-то фольклер вместо вменяемого ченжлога, еще и испорчено корявым переводом.
| |
1.10, ALex_hha (ok), 15:45, 20/10/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
> А я до сих пор пользуюсь SubVersion
сочувствую бро
> и всегда с улыбкой смотрю
те, кто работал с svn в цирке больше не смеются
> и про ребейспроблемы
в svn их просто нет. Нет человека - нет проблем ( с )
| |
1.12, Аноним (13), 15:46, 20/10/2020 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– |
дебильная логика. sha3 стандарт. не sha2, не sha1, не md5. sha3! нафига использовать старье?
| |
|
|
3.25, Аноним (13), 16:50, 20/10/2020 [^] [^^] [^^^] [ответить]
| –2 +/– |
те использоваться уже не должен ибо выявлены проблемы в sha1 и sha2. использовать нужно sha3
| |
|
|
|
6.84, funny.falcon (?), 08:48, 21/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
Пруфлинк, пожалуйста.
В SHA2 (а sha256 - это тоже sha2) пока что не найдено даже теоретических уязвимостей. SHA3 принимали не потому, что SHA2 был сломан, а потому, что SHA2 построен по принципу, похожему на SHA1 (который сейчас условно сломан). Опасаясь ВОЗМОЖНОГО ПОЯВЛЕНИЯ уязвимостей в SHA2, было решено принять параллельно стандарт SHA3, чтобы был алгоритм, не похожий на SHA2. Потому, кстати, победил Keccak, а не Blake/Blake2, которые в софтварной реализации заметно быстрее.
| |
|
7.114, Аноним (13), 17:15, 21/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
В марте 2008 года индийские исследователи Сомитра Кумар Санадия и Палаш Саркар опубликовали найденные ими коллизии для 22 итераций SHA-256 и SHA-512.В сентябре того же года они представили метод конструирования коллизий для усечённых вариантов SHA-2 (21 итерация). Позднее были найдены методы конструирования коллизий для 31 итерации SHA-256 и для 27 итераций SHA-512.
| |
|
|
|
|
3.34, кэп (?), 17:48, 20/10/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
> sha256 тоже стандарт
нет, sha256 это sha2 с увеличеным размером хэша
| |
|
|
1.16, Аноним (16), 16:18, 20/10/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
А как бы это сделать pull не для текущей ветки, но и не переключаясь на ветку которую стягиваешь. Например чтобы посмотреть в ней что менялось и подмержить
| |
|
2.17, Аноним (13), 16:21, 20/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
напиши скрипт который будет переключатся, делать pull и переключаться назад.
а вообще fetch -a
| |
|
3.28, Аноним (16), 16:52, 20/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
Как всегда всё гениальное просто... просто проскочило мимо меня) Спасибо
| |
|
|
1.23, Аноним (24), 16:45, 20/10/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
>>Изначально планировалось использовать алгоритм SHA3-256, но в конечном счёте разработчики остановились на SHA2-256
>>На данном этапе можно лишь выбрать между SHA-1 и SHA-256
Так SHA2-256 или SHA-256 добавили? Или это одно и тоже?
| |
|
2.39, Аноним (36), 18:14, 20/10/2020 [^] [^^] [^^^] [ответить]
| +2 +/– |
Из педивикии:
===
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
| |
|
1.32, Козлетто (?), 17:27, 20/10/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Интересно почему СКВ популярно только у программистов? Теоретически они могут полезны везде где есть часто изменяемые файлы и необходимость командной работе с ними. А то бухгалтеры и дизайнеры плодят 100500 файлов _копия100500 где в этой помойке не разберёшь где что лежит
| |
|
2.41, JL2001 (ok), 18:35, 20/10/2020 [^] [^^] [^^^] [ответить]
| +2 +/– |
> Интересно почему СКВ популярно только у программистов? Теоретически они могут полезны везде
> где есть часто изменяемые файлы и необходимость командной работе с ними.
> А то бухгалтеры и дизайнеры плодят 100500 файлов _копия100500 где в
> этой помойке не разберёшь где что лежит
потому что у ворда (и майкрософтофиса) бинарные и проприетарные форматы
но я присоединяюсь к вашему недоумению
| |
|
3.44, Козлетто (?), 18:52, 20/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
>> Интересно почему СКВ популярно только у программистов? Теоретически они могут полезны везде
>> где есть часто изменяемые файлы и необходимость командной работе с ними.
>> А то бухгалтеры и дизайнеры плодят 100500 файлов _копия100500 где в
>> этой помойке не разберёшь где что лежит
> потому что у ворда (и майкрософтофиса) бинарные и проприетарные форматы
> но я присоединяюсь к вашему недоумению
А что мешает этом ворду или другой аналогичной программе использовать текстовый недеструктивный формат? Вендорлок?
| |
|
4.60, anonymous yet another (?), 21:11, 20/10/2020 [^] [^^] [^^^] [ответить]
| +1 +/– |
Микрософт ;)
Вообще-то в MS Word есть встроенный контроль версий. Пригодность к использованию по назначению --- не знаю, я word'ом не пользуюсь. Судя по тому, что об этом почти никто не знает, наверное не пригодно. Там много чего интересного при желании можно найти. Я из присланной рекрутёрами описания вакансии ради интереса достал оттуда: компанию, запостившую вакансию, дату когда её создали, имена hr-ов в оригинальной компании и рекрутинговом агенстве, имя заинтересованного руководителя, примерное количество соискателей на эту вакансию и динамику изменений требований к кандидату, включая денежное довольствие (откуда следовало, что с наймом на эту позицию проблемы).
| |
|
5.73, Crazy Alex (ok), 02:27, 21/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
Вполне пригодно и активно используется. В либре аналогичное есть. Проблема скорее в том, что общая культура работы с данными в ворде в среднем по больнице чудовищна - ну там, на одного учёного тысяча секретарш, которые даже стили не понимают.
| |
|
6.77, GG (ok), 05:02, 21/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
У учёных тоже каша в головах.
То ли дело писатели, вот у этих гит хорошо заходит.
| |
6.108, anonymous yet another (?), 16:40, 21/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
Беда в том, что чувствительная информация регулярно утекает незаметно для потребителя. И сделано так (по крайней мере, было; есть ли сейчас?) "из коробки".
| |
|
|
|
3.61, fuggy (ok), 21:15, 20/10/2020 [^] [^^] [^^^] [ответить]
| –2 +/– |
На самом деле всё просто. Бинарные файлы тоже можно сравнивать. Достаточно
$ git config diff.word.textconv docx2txt
$ echo '*.docx diff=word' > .gitattributes
Если документы хранятся в репозитории, то можно легко их сравнить. Конечно форматирование теряется, но программистам и не нужно форматирование. А бухгалтеры всё равно не смогут использовать даже GUI git, чтобы делать это. Если только обёртку для этого написать, но мёржить всё равно не получится, проще их на markdown пересадить.
| |
3.66, Аноним (132), 00:03, 21/10/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
Дело не в бинарном формате, а в том, что все существующие стабильные системы контроля версий - текстовые. То есть подходят только для исходников и плейн текста, и то очень плохо. А нужна система для DAGов, а не последовательностей строк.
| |
|
4.120, пох. (?), 18:46, 21/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Дело не в бинарном формате, а в том, что все существующие стабильные системы контроля версий -
> текстовые.
хуже - они линейно-ориентированные. html - это в общем текстовый файл. Только от добавления лишнего пробела или переноса строки, ВНЕЗАПНО, не только не портится, как модные-современные форматы, а хуже того - в результирующем его отображении не меняется НИЧЕГО.
> То есть подходят только для исходников и плейн текста
именно так. Причем для исходников не на пихоне тоже неудобны - приходится добавлять отдельные костыли и подпорки для борьбы с лишним пробелом (а перенос по прежнему неизлечим).
Но с вордом (и экселом) прикол в том, что они ТОЖЕ линейно-ориентированные, хотя и не плейнтекст. И показать что вот в этой строке поменяли а на б а вон та просто сдвинута ниже - вполне можно. Просто не ждите от шва6одкоистерическ подобного инструмента. Включая для шва6одкиных форматов шва6одкоофиса, не на тех напали.
Коммерческие - лет десять назад вполне успешно существовали, к сожалению, мне тогда были без пользы, поэтому названий не вспомню.
| |
|
3.95, пох. (?), 11:40, 21/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
> потому что у ворда (и майкрософтофиса) бинарные и проприетарные форматы
средства для трекинга изменений в которых (пусть бинарные и проприетарные) существуют уже лет двадцать.
> но я присоединяюсь к вашему недоумению
спи спокойно, твоей шва6одке они не угрожают
Сравнить два .odt ты сможешь примерно никогда.
| |
3.118, Аноним (8), 18:28, 21/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
А какая разница? diff это капля в море возможностей vcs. Посмотреть "как было" и "как стало" можно с абсолютно любым форматом, плюс кто и когда что-то менял. А если постараться, можно и diff сделать. Например, github замечательно умеет diff картинок.
| |
|
2.51, Michael Shigorin (ok), 19:48, 20/10/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Интересно почему СКВ популярно только у программистов?
Ну почему, в девяностые вроде как и у бухгалтеров с дизайнерами СКВ бывали популярны...
| |
2.52, Аноним (3), 20:06, 20/10/2020 [^] [^^] [^^^] [ответить] | –2 +/– | Лично я загнал себя в задницу тысячами и тысячами файлов разных версий на диске ... большой текст свёрнут, показать | |
|
3.56, Аноним (3), 20:43, 20/10/2020 [^] [^^] [^^^] [ответить]
| –2 +/– |
Главная боль в том, что данные рандомно обновляются. И мне что-то не хватает кнопки СРАВНИТЬ ФАЙЛЫ ПРОХЕШИРОВАВ ОБА в кде, когда предлагает заменить файл с одинаковым именем. Там может несколько байт поменялось, НО ОНИ ВАЖНЫЕ. Как люди вообще с файлами работают? Что-либо найти вообще тяжело, файлы называют чёрте как. Но реально, принудительное тагирование нормальными данными наверное бы помогло. Все эти файлы замечательно копятся и потом не ясно куда делись десятки терабайт, а тебе срочно нужны терабайты под какие-то данные, а всё забито мусором и частичными дубликатами.
| |
|
4.99, Ordu (ok), 13:45, 21/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
> Как люди вообще с файлами работают?
Твой 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/
| |
|
5.109, Аноним (3), 16:43, 21/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
Мне нужно управление файлами, полученными из интернета. Допустим, я знаю, что ищу, но найти это, не проследовав на источник в интернете и не получив из него имя искомого файла и дату последнего изменения (а в самом лучшем случае и хэш), не представляется возможным: если я открываю архив. я вижу в нём какие-то бинарные файлы, и что дальше? По соседству может лежать точно такой же файл, более старый по времени изменения и имеющий тот же самый размер, но по факту это более новый файл с кучей изменений. Всё-таки, юзабилити нынешних файловых менеджеров не очень высокое. Было бы неплохо интегрировать систему файл менеджмента (я пока только реализовал подгрузку сведений из интернета, но где-то придётся запускать браузер из-за скриптов и это уже не удобно).
| |
|
6.110, Аноним (3), 16:47, 21/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
Мне кажется, в случае с архивами, можно просканировать файл на предмет самого последнего изменения для всех файлов в архиве. Не поможет для изврата, где время изменения подделали, но в целом должно быть нормально. Но это работает только с архивами, с бинарями не получится и тут только считать хэш -- это единственная доступная инфа. Если бы существовал реестр загрузок, хэши для всех файлов в него вполне можно было бы и сохранять. Но они долго считаются. Т_Т
| |
|
7.111, Аноним (3), 16:51, 21/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
В идеале было бы в процессе загрузки хэши считать. Ну т.е. если скачивать будет скрипт вместо браузера, он может и добавлять всё куда нужно. Однако это мнее удобно, наверное. И опять же проблема: страницы генерируются скриптами, нужно решать капчи, и прочее такое. Почему никто не напишет такое ПО?
| |
7.113, Аноним (3), 17:02, 21/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
А вот тут что-то можно сделать. Время изменения для локального файла выставлять по последнему обновлённому файлу в архиве. У локального файла архива всё ещё остаётся время создания (даже два, но с ними всегда путаница и второе в glibc только недавно добавили).
| |
|
|
|
|
|
2.117, Аноним (8), 18:25, 21/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
Это просто мера уровня специалиста. Всё что может периодически изменяться руками нет смысла не хранить в vcs. Да, не для всего можно сделать diff, но diff это только один малюсенький аспект работы с VCS. Посмотреть как было, как стало, кто и когда изменил можно абсолютно всегда. И очень часто нужно.
| |
|
1.85, Аноним (132), 09:23, 21/10/2020 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
>Также пока ни один Git-провайдер, включая GitHub, не поддерживает репозитории с хэшами SHA-256.
Насколько я помню, в доках по гиту было написано, что сначала сделают фичу локально, а уже потом начнут делать транспорт по сети.
| |
|
|
3.147, Javaist (?), 18:15, 24/10/2020 [^] [^^] [^^^] [ответить]
| +/– |
Это лишь один комминт, там ещё есть. В описании ведь написано что изменилось или ты не читал?
| |
|
|
|