The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


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

Оглавление

Выпуск распределенной системы управления исходными текстами Git 2.29, opennews (??), 20-Окт-20, (0) [смотреть все]

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


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__email (ok), 21-Окт-20, 07:49 
> JIRA. Без нее тоже никак

очень даже как, потому что есть Redmine.

Ответить | Правка | Наверх | Cообщить модератору

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

Редкостная чушь сей Redmine

Ответить | Правка | Наверх | Cообщить модератору

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

На вкус и цвет все люди разные. По крайне мере, за него платить не надо.

Ответить | Правка | Наверх | Cообщить модератору

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

Ещё как надо! :)  Каким это бесплатными образом вы намерены обеспечить группе доступ к серверу??? :)

Хостинг/колокейшн либо канал до домашнего сервера стоят денюжек! :) И так это заметных :)

Ответить | Правка | Наверх | Cообщить модератору

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

Но за саму систему платить не надо, в отличие от Jira.

Ответить | Правка | Наверх | Cообщить модератору

140. "Выпуск распределенной системы управления исходными текстами ..."  +/–
Сообщение от TheFotoMag (ok), 22-Окт-20, 20:31 
> Но за саму систему платить не надо, в отличие от Jira.

А админить? Пушкин будет? Самому доки курить и ночей не спать? +1 чел. 40 тыщ? А он хочет 70. Пенсионный, бла-бла-бла. Вот Jira уже и дешевле. Открывай контору, окунайся в жизнь, плати зарплаты :) У всех — детки :) И начнешь смотреть на корпоративные сервисы другими глазами :)  :)  :)


Ответить | Правка | Наверх | Cообщить модератору

141. "Выпуск распределенной системы управления исходными текстами ..."  +/–
Сообщение от nomad__email (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__email (ok), 21-Окт-20, 07:48 
> В какой момент git был простым? Довольно сложная VCS с момента рождения

Это в каком же месте он сложный? Или не осилил https://git-scm.com/book/ru/v2?

Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

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

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




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру