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

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

Сообщения

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

2. Сообщение от Аноним (2), 02-Июн-23, 11:15	+4 +/–
542 изменения, что они там делают ваще?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #3, #4, #84

3. Сообщение от Аноним (3), 02-Июн-23, 11:19	+6 +/–
коммитят
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

4. Сообщение от Аноним (4), 02-Июн-23, 11:29	+/–
а сколько должно было быть? точное число назови
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #7, #8

5. Сообщение от Аноним (5), 02-Июн-23, 11:40	+/–
Как в конфиге прибить для форспушей обязательное выполнение --force-with-lease и --force-if-includes ?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #15

7. Сообщение от 1 (??), 02-Июн-23, 12:14	+2 +/–
42 же !
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

8. Сообщение от Аноним (8), 02-Июн-23, 12:15	+/–
тебе же написали 2.41
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

10. Сообщение от Аноним (10), 02-Июн-23, 12:50	–1 +/–
после svn на git без слёз не взглянешь. но да, миллионы мух не могут ошибаться
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #12, #14, #24, #31, #38, #50, #68

11. Сообщение от Пряник (?), 02-Июн-23, 12:52	+7 +/–
Пишут гит, чтобы писать гит. Пока писали, стал тормозить, стали еще больше писать гит, стало еще больше тормозить...
Ответить | Правка | Наверх | Cообщить модератору

12. Сообщение от Аноним (4), 02-Июн-23, 12:57	+4 +/–
> Subversion — свободная централизованная > централизованная И сразу фтопку. > миллионы мух не могут ошибаться Не будь как все. Ешь ногами, а код набирай носом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #13, #29, #36

13. Сообщение от Аноним (10), 02-Июн-23, 12:59	+/–
у тебя все репы централизованные на твоём гитхабе или гитлабе, а про децентрализованные фишки все забыли ещё до твоего рождения
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #18, #25, #102, #117

14. Сообщение от Пряник (?), 02-Июн-23, 13:00	+1 +/–
Гит всего лишь реализация механизма. Что-то типа виртуальных снапшотов поверх контентно-адресуемой файловой системы. Есть ещё Mercurial и BitKeeper, которые делают то же самое. Не могу сравнивать с SVN, я вообще не понимаю зачем кому-то возможность быстро создавать и удалять ветки?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #16, #56

15. Сообщение от Пряник (?), 02-Июн-23, 13:02	+2 +/–
Альясом в bash или в самом Git (да, в нём тоже альясы есть в config).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5

16. Сообщение от Аноним (10), 02-Июн-23, 13:02	–3 +/–
git всего лишь NIH-синдром в самом существе, который стал популярным по тем же причинам, что и cmake, - чем фиговее, тем лучше
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #65, #93, #97

18. Сообщение от Аноним (4), 02-Июн-23, 13:19	+1 +/–
> у тебя все репы централизованные на твоём гитхабе или гитлабе Нет, у меня все репы децентрализованные, потому что это гит. Особенно это пригодилось на работе, когда переезжали с публичного инстанса гитлаба на self-hosted: во время переходного периода были две одновременно каноничные, но разные по своему составу репы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #27, #46

23. Сообщение от Аноним (23), 02-Июн-23, 14:31	+3 +/–
Скоро эта утилита, предназначенная для менеджмента исходников ядра Linux, станет сложнее этого самого ядра.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #30, #35, #89

24. Сообщение от Аноним (25), 02-Июн-23, 15:04	+1 +/–
Смотри-ка муха считает что права именно она, а не остальные мухи.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

25. Сообщение от Аноним (25), 02-Июн-23, 15:11	+/–
От наличия основного репозитория децентрализованные фишки никуда не исчезают. Например, турнут тебя с гитхаба - пушнешь на гитлаб и продолжишь работать как ни в чём не бывало. А репозиторий subversion, из которой VCS как из гoвна поля, ты в этом случае потеряешь. Ну и потом, децентрализованная VCS это не только децентрализованная разработка. subversion, в которой нельзя сделать локальную ветку без write доступа в основной репозиторий, вообще VCS считаться не может.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #26, #28, #39, #120

26. Сообщение от Ананий (?), 02-Июн-23, 15:49	–1 +/–
>Например, турнут тебя с гитхаба не жалко отдавать хоть сколь-нибудь коммерческое поделие микрософту|${companyname} на съеденье? В случае селфхостед твоя проблема решается копированием репы. Или бекупы гиту не нужны?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #69, #128

27. Сообщение от lizard (??), 02-Июн-23, 16:34	–2 +/–
Subversion умеет прозрачное зеркалирование сервера, переезд очень легкий: `svn relocate` :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #127

28. Сообщение от lizard (??), 02-Июн-23, 16:36	+/–
Subversion умеет удаленный бакап нужных веток: svnrdump. А потом можно все отправить на новый сервер.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #72

29. Сообщение от lizard (??), 02-Июн-23, 16:58	+1 +/–
Централизованная система управления версиями имеет множество своих важных плюшек. Например контроль доступа: есть гарантия, что важная ветка не расползется на 100500 репозиториев. Кроме того с svn монорепа не требунет никаких дополнительных телодвижений. svn нормально работает с бинарными файлами. С svn элементарно получить доступ к коду без svn клиента, просто через браузер, curl, wget (это удобно для деплоя конфигов), или с WebDAV. Subversion легко организовать аутентификацию по сертификату. Ну и много других полезностей. Если вы пользуетесь Гитхабчиком как единственной центральной репой, многочисленные полезности svn недоступны - это плата за децентрализацию, которая в этом случае отсутствует. Плата есть пользы нет. Абсурд. Вообще, выбор между svn и git должен определяться целями и моделью использования.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #37, #47

30. Сообщение от lizard (??), 02-Июн-23, 17:03	–3 +/–
чтобы пользоваться (черной магией) git пишут толстые книги. Но все равно юзеры регулярно портят свои репы (rebase хаха). При этом репу svn нельзя испортить - svn намного более безопасен (для малокомпетентного юзера)ю
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #42

31. Сообщение от lizard (??), 02-Июн-23, 17:16	+/–
Сравните CVE для git и svn: Для git репортов намного больше плюс полно количество arbitrary code execution. Для svn большинство серьезного - denial of service.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #32

32. Сообщение от soarin (ok), 02-Июн-23, 17:20	–9 +/–
Security by Joe.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #33

33. Сообщение от Аноним (33), 02-Июн-23, 17:43	–1 +/–
Лошадиный е6анат.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32

34. Сообщение от Советский инженер и пенсионер (?), 02-Июн-23, 17:44	–1 +/–
Не устану повторять, что гит не нужен. Это лишнее колесо в телеге. Намного быстрее, проще и понятнее жать в контекстном меню 7z -> архивировать.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #48, #49, #82, #148

35. Сообщение от Советский инженер и пенсионер (?), 02-Июн-23, 17:47	+/–
Там один лишь официальный мануал тянет на трёхтомник ландсберга. Даже не представляю как это всё можно держать в голове, попутно программируя и используя ещё 100500 смежных технологий.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #43, #66

36. Сообщение от Советский инженер и пенсионер (?), 02-Июн-23, 17:50	–1 +/–
Централизация это единственно рабочая система. Касается любых жизненных аспектов. Всё остальное - хаос.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

37. Сообщение от Серб (ok), 02-Июн-23, 18:02	+/–
> Например контроль доступа: есть гарантия, что важная ветка не расползется на 100500 репозиториев. Про git-svn слышал?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #55, #73

38. Сообщение от Аноним (38), 02-Июн-23, 18:03	+/–
> после svn на git без слёз не взглянешь. но да, миллионы мух не могут ошибаться А чего не CVS? 🤡
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #61

39. Сообщение от FSA (??), 02-Июн-23, 18:10	–1 +/–
> Например, турнут тебя с гитхаба - пушнешь на гитлаб и продолжишь работать как ни в чём не бывало. Так можно сразу на Github, Gitlab, Bitbucket, gitflic какой-нибудь даже, и себе на сервер заливать постоянно. Везде дубликаты исходников. Турнули с одного, у тебя есть исходники на других. Останется самое сложное, организовать работу в новой системе. Но это сложно, если ты не один с репозиторием работаешь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #67

40. Сообщение от Аноним (40), 02-Июн-23, 18:11	+3 +/–
Git надёжным назвать нельзя. Надёжным был mercurial, но его прикопали, потому что большие боссы уже двигают git, который как и линукс должен всё под себя подмять и убить реальные альтернативы.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #41, #44, #45, #51, #60, #74, #90

41. Сообщение от Вы забыли заполнить поле Name (?), 02-Июн-23, 18:23	+/–
Кто кого прикопал? Ставь и пользуйся
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40

42. Сообщение от FSA (??), 02-Июн-23, 18:31	+/–
> svn намного более безопасен (для малокомпетентного юзера) Так эти юзеры удалённый репозиторий не испортят в таком случае. А у себя пусть ломают что хотят. Это их проблема, что они свою работу потеряют. Я правильно понял, что вы отсутствие потенциально опасной операции, которая в умелых руках позволяет исправить ошибки, представляете как преимущество?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #71, #81

43. Сообщение от FSA (??), 02-Июн-23, 18:34	+/–
А там всё и не надо держать. По большому счёту для повседневной работы хватает push, pull, status, add, commit, log. Может ещё что-то забыл. Всё остальное гуглится в течении минуты, если оно понадобилось.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35 Ответы: #57, #126

44. Сообщение от FSA (??), 02-Июн-23, 18:36	+/–
Так он был на Python 2. А вот Python 2 закопали. И что делать, если никто не удосужился переписать его на Python 3? Не знаю на счёт разницы в надёжности, но я с mercurial начинал. Некоторые вещи для меня там были проще. Но когда разобрался с git, то решил остаться на нём просто потому, что он делает тоже самое, но при этом есть более широкий выбор бесплатных хостингов для моих репозиториев.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40

45. Сообщение от Аноним (45), 02-Июн-23, 18:51	+1 +/–
Никто ничего не прикапывал. Ртуть релизится и развивается.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40

46. Сообщение от Аноним (46), 02-Июн-23, 18:52	–2 +/–
и где тут децентрализация? может ты толковым словарём не овладел?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

47. Сообщение от Аноним (46), 02-Июн-23, 18:54	+2 +/–
Как только ты прописываешь адрес сервака, уже идёт централизация. Нет никаких децентрализованных систем, это бредни.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #76, #88, #124

48. Сообщение от Аноним (46), 02-Июн-23, 18:57	+/–
Ты не прав от слова совсем. И дело не в git или другой системе контроля версий. А в том, что ты в любой версии можешь быстро сравнить изменения с предыдущими версиями + узнать кто тот дятел, что всё сломал. По твоей системе, надо сперва всё распаковать... А если там гиги?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #58

49. Сообщение от Аноним (2), 02-Июн-23, 19:03	+/–
Мде, в 2023-м не знать про мёрдж.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34

50. Сообщение от Аноним (50), 02-Июн-23, 19:35	+/–
А после RCS и Новая папка (212) вообще рыдаешь сутки не останавливаясь?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

51. Сообщение от Аноним (50), 02-Июн-23, 19:46	–1 +/–
Спешите видеть, фильм в стиле нуар: к опеннетному анониму по ночам приходят большие боссы, отбирают mercurial и двигают git. 18+.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40

55. Сообщение от Другой Аноним (?), 02-Июн-23, 20:50	+/–
Хорошая вещь, но не в тему сказана. Как git-svn гарантирует, что важная ветка не расползется на 100500 репозиториев? Как git-svn даст доступ к коду без svn клиента?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #87

56. Сообщение от Аноним (56), 02-Июн-23, 20:52	+/–
>Гит всего лишь реализация механизма. Что-то типа виртуальных снапшотов поверх контентно-адресуемой файловой системы. А где другие имплементации этих снапшотов? Нет их, поэтому говорить о них как об отдельном продукте бессмысленно. Mercurial и BitKeeper не используют код Git.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14

57. Сообщение от Аноним (56), 02-Июн-23, 20:54	+/–
Может тогда вообще использовать не Git, а другую систему попроще?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43 Ответы: #59, #70

58. Сообщение от Аноним (56), 02-Июн-23, 20:58	+5 +/–
Какие гиги, там один helloworld.rs
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48

59. Сообщение от FSA (??), 02-Июн-23, 20:58	+/–
> Может тогда вообще использовать не Git, а другую систему попроще? Ну так используешь базовые возможности. Остальное, возможно, необходимо другим в вашей команде. Если команды нет, то этих базовых возможностей выше крыши. Если что-то не можешь сделать, читаешь документацию и делаешь. А если у тебя система попроще, то что ты будешь делать, если тебе что-то надо сделать, а у тебя нет такой возможности? Дописывать свою систему самому?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57 Ответы: #62, #110

60. Сообщение от Аноним (56), 02-Июн-23, 21:00	+/–
Просто поставь https://hg-git.github.io/ и покажи боссам средний палец
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40

61. Сообщение от Аноним (56), 02-Июн-23, 21:05	+/–
А почему бы и нет? Стабильная и быстрая штука.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38

62. Сообщение от Аноним (56), 02-Июн-23, 21:08	+/–
Напоминает C++
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59 Ответы: #64

63. Сообщение от Аноним (63), 02-Июн-23, 21:24	+1 +/–
Что бы делать - лишь бы на SHA256 не переходить...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #86

64. Сообщение от FSA (??), 02-Июн-23, 21:37	+/–
> Напоминает C++ ¯\_(ツ)_/¯ Я даже не знаю что тут ответить...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62

65. Сообщение от Аноним (25), 02-Июн-23, 22:03	+2 +/–
Бездоказательное утверждение. Да, и git и cmake не идеальны, но а) Они на голову, просто несравнимо лучше того что до них было. autocrap (или, боже упаси scons) и subversion (cvs уже был мёртв, хотя даже он был не так отвратен как svn). б) Ты со своим мнением не только не написал ничего лучше, но даже не описал как могло бы быть лучше. А если напишешь, тебя как котёнка мордочкой в это натыкают. Потому что такой бред > который стал популярным по тем же причинам, что и cmake, - чем фиговее, тем лучше может написать только полный дилетант, который думает что сообщество в своём выборе инструментов руководствуется не объективными критериями, а какими угодно только бы тебе родимому на зло. Другими словами, git и cmake - замечательные, мощные и удобные инструменты, которыми хочется пользоваться, и лучше которых ничего пока даже близко не изобрели, и сообщество в этом солидарно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16

66. Сообщение от Аноним (25), 02-Июн-23, 22:11	+/–
> Там один лишь официальный мануал тянет на трёхтомник ландсберга Чтобы работать не нужно не только читать его весь, но и читать его вообще. Для работы достаточно знать 4 слова - clone,commit,pull,push которые тебе уже известны по любой другой vcs. Даже ключей никаких не нужно. В man нужно смотреть только когда/если понабится что-то нетривиальное. > Даже не представляю как это всё можно держать в голове Действительно - двор подмести, да бухнуть после работы, ничего больше в голове держать не надо. А то напридумывали каких-то комплюцкеров.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35

67. Сообщение от Электрон (?), 02-Июн-23, 23:30	+1 +/–
Где сложно? Мейнтейнеру хоть мылом пачти присылают. Он после мерджа распушивает ветки на все remote одной командой: git push  kuda nado. Откройте для себя несколько URL за одним remote. Любой другой после этого может откуда угодно клонировать. Принимать PR-MR - да, либо привязка, сторонний сервис или (как уже сказал) рассылка.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #129

68. Сообщение от мимо (?), 02-Июн-23, 23:48	+/–
Hello, this is Linus Torvalds and I pronounce SVN as GIT.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

69. Сообщение от Аноним (69), 03-Июн-23, 00:27	+/–
> не жалко отдавать хоть сколь-нибудь коммерческое поделие микрософту|${companyname} на съеденье? О чём ты? > В случае селфхостед твоя проблема решается копированием репы. Какая проблема? > Или бекупы гиту не нужны? Иди проспись.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

70. Сообщение от Аноним (50), 03-Июн-23, 00:33	+/–
Используй, кто ж тебе не даёт-то? Как существование Git тебе лично мешает пользоваться чем-то попроще?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57

71. Сообщение от lizard (??), 03-Июн-23, 00:34	+/–
Это преимущество в умелых руках. Но проблема в том, что некоторые юзеры любят лазить по разным stackoverflow и копипастить git команды не ситая сопроводительный текст. С фатальными последствиями, потому что в git локальный репо это король. В svn так не прокатит. Там сервер правитель всего.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #125

72. Сообщение от Аноним (69), 03-Июн-23, 00:36	+/–
- Вы пробовали им дампить и заливать репозиторий хотя бы в 200k коммитов? Попробуйте. - О бэкапе нужно заранеее позаботиться. Никто этого не делает. И нет, они не ССЗБ, поскольку в нормальных VCS не нужно заранее заботиться о бэкапах. Алсо, даже регулярный бэкап отстаёт от реальности, поэтому последние изменения будут потеряны. В git это невозможно. - Для поднятия нового официального репозитория должен проснуться овнер проекта. Это простой разработки в часы-недели. В git во-первых, простоя не будет, потому что в них МОЖНО полноценно работать локально. Во-вторых, в git можно за секунду организовать временный общий репозиторий где угодно. Или несколько. Надо ли говорить, что произойдёт в svn мире если вдруг народ после проблем с репозиторием не договорился и поднял НЕСКОЛЬКО его копий и в каждую что-то закоммитил?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #80

73. Сообщение от lizard (??), 03-Июн-23, 00:39	+/–
git-svn это просто интерфейс к git, позволяющий использовать сервер svn. Вещь иногда очень полезная, неплохая, но иногда несколько глюбкавая.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #123

74. Сообщение от Аноним (69), 03-Июн-23, 00:40	–1 +/–
> Git надёжным назвать нельзя А тебя нельзя назвать профессионалом, с достаточным опытом чтобы об этом судить, не говоря даже о доказательствах.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40

76. Сообщение от fuggy (ok), 03-Июн-23, 01:01	+/–
Нет гит не так устроен. Не обязательно прописывать сервер. Я могу прописать адрес Васяна, Васян адрес Стасяна, Стасян адрес Димана, Диман адрес Торвальдса. Где децентрализованный сервер? Это обычный p2p.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47

80. Сообщение от lizard (??), 03-Июн-23, 02:58	+/–
200000 нет, но 20000 работает, хотя и далеко не мгновенно. Руками качать нет необходимости - все делает скрипт. > О бэкапе нужно заранеее позаботиться. Никто этого не делает. Сервер требует бакап. В том числе и git. Точка. > в нормальных VCS не нужно заранее заботиться о бэкапах ??? - в гит нет гарантии того, что на разных серверах хранятся полностью идентичные данные, нет гарантии одинаковой истории изменений. Так что бакап это необходимость всегда > что произойдёт в svn мире если вдруг народ после проблем с репозиторием не договорился и поднял НЕСКОЛЬКО его копий Такого быть не может при централизованной модели. Если у вас базар - svn не для вас, добро пожаловать в git, hg и т.п. Можно хоть патчи по почте посылать. Инструмент зависит от модели использования
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72 Ответы: #100

81. Сообщение от lizard (??), 03-Июн-23, 03:01	–1 +/–
Можно испортить удаленный сервер --force готово
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #105

82. Сообщение от lizard (??), 03-Июн-23, 03:03	+/–
Нет, git очень даже нужен - для своей модели использования. Для всего другого - другие подходящие инструменты, иногда svn. Это просто инструмент, а не религия.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #91

84. Сообщение от Аноним (84), 03-Июн-23, 08:04	+/–
https://github.com/git/git/compare/v2.40.0..v2.41.0
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

86. Сообщение от Аноним (86), 03-Июн-23, 09:48	+1 +/–
Что бы делать - лишь бы ненужного не делать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63

87. Сообщение от Аноним (87), 03-Июн-23, 10:06	+/–
Я так понимаю, просто наличие git-svn приводит к тому, что нет никаких гарантий, на то что код из svn репозитория не расползется на сотни, веток в разных репозиториях. Он просто опроверг высказывание.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55 Ответы: #103

88. Сообщение от Аноним (5), 03-Июн-23, 10:07	+/–
А если три сервера прописал, то центр где?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47

89. Сообщение от Вы забыли заполнить поле Name (?), 03-Июн-23, 14:28	+/–
> Скоро эта утилита, предназначенная для менеджмента исходников ядра Linux, станет сложнее > этого самого ядра. https://www.opennet.me/opennews/art.shtml?num=52355
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

90. Сообщение от пох. (?), 03-Июн-23, 17:41	+/–
> Git надёжным назвать нельзя. > Надёжным был mercurial, но его прикопали, потому что большие боссы уже двигают нет, потому что он сам закопался. Во-первых автор ядра покинул проект в первый же год его существования (и да, это большие боссы но они играли не за гит а за мертворожденный биткипер). С тех пор много казавшихся тривиальными вещей так и не были реализованы или реализованы криво. Во-вторых был выбран фантастически неудачный язычок с отступами (внезапно, даже перл на котором все еще написаны отдельные куски гита жив и портирован на мильен платформ, а вот впихон2 - таки всьо) В-третьих, гитхап и гитляп, да. Третий пункт не имел бы определяющего значения, если бы автор не повторил изначальную ошибку гита - отсутствие хотя бы номинальной авторизации и разделения пользователей из коробки. То что позволяло svn как быть самодостаточным, так и легко интегрироваться в системы контроля версий. P.S. еще вишенка на тортике - неудавшаяся попытка начать переписывать. Ну вы поняли, на чем и чем кончилось. А время шло...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40

91. Сообщение от пох. (?), 03-Июн-23, 17:45	+/–
> Нет, git очень даже нужен - для своей модели использования. его модель использования - автоматизация работы одного очень странного чувака, требовавшего присылания ему патчей мэйлом и порезанных так чтоб в экран 80*25 влазило. Вот с этой моделью он справляется наотличненько. Причем чуваку было и осталось совершенно наплевать что всем кроме него работать подобным образом крайне неудобно. > Для всего другого - другие подходящие инструменты, иногда svn. Это просто инструмент, а > не религия. это религия. Проблема в том что разработчики никаким другим инструментом пользоваться не умеют и учиться не хотят. Они на самом деле этим тоже пользоваться не умеют и "ой, как вернуть как было?!" - но постулат основан на вере и опровергнуть его невозможно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82 Ответы: #92, #96

92. Сообщение от Аноним (50), 03-Июн-23, 18:54	+/–
> Причем чуваку было и осталось совершенно наплевать что всем кроме него работать подобным образом крайне неудобно А как же опенсорс, никто никому ничего не должен, захотел — форкнул? Не вышло форкнуть чувака, да? А что ж ты не вызвался? Кодить не умеешь или это другое? > разработчики никаким другим инструментом пользоваться не умеют и учиться не хотят А как же «работает — не трогай»? Или это тоже другое? Никогда не мог понять: почему у опеннета всегда так пригорает в пятой точке от того, что кому-то удобно не так, как им? Про религию уж чья бы корова мычала. Только на опеннетах можно встретить «правильные» и «неправильные» языки, системы инициализации, ядра ОС, процессорные архитектуры, да что угодно. Дай опеннетчикам на выбор два протокола — перегрызутся между собой насмерть, прежде чем хоть байт отправят.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #91 Ответы: #95

93. Сообщение от Аноним (93), 03-Июн-23, 19:09	+/–
Ну, в этом что-то есть. По тому сколько изменений в git программу вносится, в структуру файлов-данных, и всё больше и больше каких-то очень специфичных опций и команд добавляется - превращается в какой-то комбайн. И в комбайн что-то превратить на самом деле не так сложно, гораздо сложнее продумать программу так, чтобы она и очень простой была и выполняла при этом все необходимые функции.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16

94. Сообщение от Аноним (93), 03-Июн-23, 19:14	+2 +/–
Какие-то индексы, обратные индексы индексы - зачем это всё? Есть же базы данных, в них всё это давно уже есть и хорошо работает, зачем переизобретать?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #98, #104, #115

95. Сообщение от пох. (?), 03-Июн-23, 21:02	+/–
> А как же опенсорс, никто никому ничего не должен, захотел — форкнул? во-первых, поляна уже загажена - причем не по щиколотку, а аж по пояс. > Не вышло форкнуть чувака, да? А что ж ты не вызвался? > Кодить не умеешь или это другое? форкнуть надо не чувака, а два состава денег IBM. А это не имеет отношения ни к опенсорсу, ни к кодингу. >> разработчики никаким другим инструментом пользоваться не умеют и учиться не хотят > А как же «работает — не трогай»? Или это тоже другое? вот того чувака это нисколько не колыхало - сетевики, фсоводы и наверное еще куча команд вокруг ядра вполне себе еще с 90х использовали cvs и потом svn. А попутно нормальные механизмы для ревью и не только. Но чтобы подать его величеству - выковыривали патчи по-одному и шинковали в 80x25 - величество по другому не приемлели. Даром что объемы того же net3 были такие что ни о каком осмысленном ревью этих мелких ошметьев 1 of 240 и речи быть не могло. > Никогда не мог понять: почему у опеннета всегда так пригорает в пятой > точке от того, что кому-то удобно не так, как им? Про ничего что нам приходится как-то взаимодействовать с этими которым очень удобно (снова нет, просто не умеют)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #92

96. Сообщение от Аноним (96), 03-Июн-23, 21:11	+/–
У git есть TortoiseGit и GUI-клиенты и плагины для файловых менеджеров. У pijul - нет. У git есть GitHub. У pijul - нет. У git есть биндинги и либы. У pijul - нет. Пока кто-то всё это не сделает, а на pijul не перейду.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #91 Ответы: #112, #118

97. Сообщение от Аноним (97), 03-Июн-23, 21:17	+/–
Руки прочь от CMake. Пока ваш базель/мезон не реализует всю функциональность симейка, хотя бы основную и многими используюмую, такую как поиск зависимостей и пакетирование, вам бы в тряпочку молчать, а не хлам бесполезный рекламировать, который для сборок софта НЕ во flatpakе/snap/Docker малопригоден.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16

98. Сообщение от Аноним (2), 03-Июн-23, 21:48	+1 +/–
тут главное побольше накоммитить и показать свою активность hr'у
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #94

100. Сообщение от Электрон (?), 04-Июн-23, 01:14	+1 +/–
> в гит нет гарантии того, что на разных серверах хранятся полностью идентичные данные, нет гарантии одинаковой истории изменений. В git есть абсолютная гарантия неизменности истории и содержания, потому что он построен и верифицируется по цепочке, блокчейн before it was cool. Если кто-то меняет историю - изменяются все низходящие коммиты, у вас не сойдется sha1 хэш. Подписи, по мнению Линуса, нужны только на тэги/релизы, чтобы подтвердить цепочку на момент подписи.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #80 Ответы: #101

101. Сообщение от lizard (??), 04-Июн-23, 02:13	–1 +/–
git init echo Бла бла бла хелло мир > file1.txt git add file1.txt git commit -m "первая ревизия ура" git mv file1.txt file2.txt echo Другой файл, прощай мир > file2.txt git add file2.txt git commit -m "вторая ревизия отлично" # Ну теперь посмотрим лог git log --follow file2.txt # Ой, первая ревизия ИСЧЕЗЛА!!!! Катастрофа, где соя первая ревизия???!!! # Занавес
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #100 Ответы: #121, #134

102. Сообщение от Аноним (-), 04-Июн-23, 05:13	+1 +/–
> у тебя все репы централизованные на твоём гитхабе или гитлабе, У меня в хомяке точная копия этого самого лежит. Она тоже "централизованная"? В отличие от svn она может все то же что копия на гит*бах, включая полноценную работу с деревом сорца, версионирование и все такое, и все это вообще без ремотных серверов. А потому быстро и независимо от наличия интернета. А если вон те надоели, можно залить на тот же notabug, или куда там еще. Или на свой сервак. Или даже флопинетом обмениваться комитами, это тоже предусмотрено. Поэтому если гит*аб забанил аккаунт, или даже закрыл датацентры и испарился, это вообще совсем не проблема. А если сервер свина стал недоступен - это уже упс. В этом децентрализованность и проявляется. В свине без ремотного сервера капец. А тут гит*абы всякие это лишь опция. Удобная хранилка и интерфейсик к копии репы. Одной из копий репы. Ничем такой не специальной. Моя репа в хомяке ничем не хуже.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13

103. Сообщение от lizard (??), 04-Июн-23, 08:33	+/–
> Я так понимаю, просто наличие git-svn приводит к тому, что нет никаких > гарантий, на то что код > из svn репозитория не расползется на сотни, веток в разных репозиториях. > Он просто опроверг высказывание. Нет, не опроверг. Если у юзера git-svn нет доступа к ветке, то ниткакой git-svn не поможет его получить. Если у юзера super-git-svn-etc есть доступ к ветка, то он может хоть копипастой в текст файл его утащить. Вопрос не в тулзе, а в наличии центрального контроля доступа
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #87 Ответы: #106

104. Сообщение от Аноним (106), 04-Июн-23, 10:25	+/–
> Какие-то индексы, обратные индексы индексы - зачем это всё? Есть же базы данных, в них всё это давно уже есть и хорошо работает, зачем переизобретать? Все дело в скорости работы. Часто используемые операции должны работать быстро. Редкоиспользуемые - приемлемое время. И дальше идет ручная балансировка необходимой от БД функциональности. Есть базы данных, которые могут разрешить сделать ручную балансировку необходимой функциональности?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #94

105. Сообщение от Аноним (106), 04-Июн-23, 10:27	+/–
Поумалчанию установленный сервер - нет. Для этого еще в настройках сервера надо разрешить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #81

106. Сообщение от Аноним (106), 04-Июн-23, 10:30	+/–
Если у пользователя нет доступа - чем это отличается от git? Если и там нет доступа - то ничего не сделать?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #103 Ответы: #107

107. Сообщение от lizard (??), 04-Июн-23, 22:00	+/–
В git нет никакого контроля доступа. Совсем. На сервере он делается через костыли.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #106 Ответы: #108

108. Сообщение от lizard (??), 04-Июн-23, 22:03	+/–
И в svn контроли гранулированный - хоть к отдельной подветке.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #107 Ответы: #109

109. Сообщение от lizard (??), 04-Июн-23, 22:08	+/–
Из гитхабчика регулярно утекают приватные ключи из открытых реп. Жесть. В svn риск намного меньше - можно просто установить соответствующие  права на ветку/файлы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #108 Ответы: #122

110. Сообщение от lizard (??), 04-Июн-23, 22:20	+/–
git изначальтно спроектирован кое-как для довольно извратного workflow (патчи от кого попало на мыло) с целью облегчить работу МАЙНТЕЙНЕРА (а НЕ разработчика). Поэтому черная магия git требуется регулярно. Люди страдают.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59 Ответы: #111

111. Сообщение от lizard (??), 04-Июн-23, 22:26	+/–
Сравните git и любые другие системы контроля версий - svn один бинарный файл, hg один бинарный файл. git - 100500 файлов и скриптиков на баше. Видно, что разработчику было интересно делать ядро. А тузу для версий он склепал тяп-ляп на коленке лишь бы работало. А оно внезапно взлетело :) И теперь все с эттим маются.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #110 Ответы: #130, #131

112. Сообщение от lizard (??), 05-Июн-23, 00:14	+/–
Есть несколько альтернатив, если надо именно распределенную систему - см https://www.fossil-scm.org/. Но гитхабчика там конечно не будет...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #96 Ответы: #113

113. Сообщение от lizard (??), 05-Июн-23, 00:22	+/–
Нет, будет - сделали автозеркалирование d git
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #112 Ответы: #114

114. Сообщение от lizard (??), 05-Июн-23, 00:26	+/–
Хотя fossil практически сам себе гитхабчик. Все в одном бинаре - и версиии веб интерфейс, вики и т.п. вплоть до чатика. Суперкомбайн.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #113

115. Сообщение от lizard (??), 05-Июн-23, 00:29	+/–
https://www.fossil-scm.org/ - на SQLite. Все уже сделано до нас.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #94 Ответы: #119

116. Сообщение от Neon (??), 05-Июн-23, 05:06	+/–
Как то чересчур переусложнили систему. Хрень какая та стала
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #132

117. Сообщение от Брат Анон (ok), 05-Июн-23, 08:20	+/–
Ты путаешь гит с гитхабом/гитлабом. Первое -- распределённая система управления версиями. Второе -- надстройки над гитом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13

118. Сообщение от пох. (?), 05-Июн-23, 11:39	+/–
> У git есть TortoiseGit и GUI-клиенты у hg, svn и (с определенными особенностями) перфорсы - тоже есть. Но ты как обычно выбрал самую васянскую поделку из всех васянских. > кто-то всё это не сделает, а на pijul не перейду. держи нас в курсе
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #96 Ответы: #133

119. Сообщение от Серб (ok), 05-Июн-23, 17:18	+/–
Это там где, для того, что бы поправить историю, надо конвертировать репозиторий в git, поправить в git'е историю, и конвертировать обратно?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #115 Ответы: #135

120. Сообщение от lizard (??), 05-Июн-23, 20:30	+/–
В svn есть shelving - локальное хранилище, данные из которого не шлются на сервер при коммите. Удобно кесли нужно отложить работу не доделав коммит и переключиться на что-то другое. Или инет если пропал. Так что есть, хотя и в рудиментарной форме (но это центрадлизованная система в ней не должно быть ничего только локального)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25

121. Сообщение от Аноним (-), 05-Июн-23, 21:23	+/–
Вы прикалываетесь? Ну вот вам на основе именно ваших потуг: $ cat 123.sh git init git config user.email "you@example.com" git config user.name "Your Name" echo Бла бла бла хелло мир > file1.txt git add file1.txt git commit -m "первая ревизия ура" git mv file1.txt file2.txt echo Другой файл, прощай мир > file2.txt git add file2.txt git commit -m "вторая ревизия отлично" # Ну теперь посмотрим лог git log --follow file2.txt # Ой, первая ревизия ИСЧЕЗЛА!!!! Катастрофа, где соя первая ревизия???!!! # Занавес Окей, позвольте посмотреть что получилось. $ git log commit de94bb0c6009544e5d4339eb3fb7b7fa4653f7cf (HEAD -> master) Author: Your Name <you@example.com> Date:   Mon Jun 5 21:19:52 2023 +0300     вторая ревизия отлично commit 254cb3af53e6a5e13868bfcfc3254a6a21d966aa Author: Your Name <you@example.com> Date:   Mon Jun 5 21:19:52 2023 +0300     первая ревизия ура Т.е. ящер явно гонит: все прекрасно видно. В общем читая коменты в интернете не забывайте включать здоровый скепсис и проверять input.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #101 Ответы: #141

122. Сообщение от Аноним (122), 05-Июн-23, 21:29	+/–
> Из гитхабчика регулярно утекают приватные ключи из открытых реп. Жесть. Если разработчик д@бил и заливает ключи в репу - кто ему доктор? > В svn риск намного меньше - можно просто установить соответствующие  права на > ветку/файлы. Тело пускающее пузыри и заливающее ключи в репу очень врядли заморочится какими-то там там правами на какие-то там ветки. Оно об этом задумается после того как на его сервак левые кадры зайдут и порулят от души. А потом в гите .gitignore есть, так что он и не будет предлагать комитить файлы которые комитить не надо, в том числе ключи, рантайм данные, объектники, бинари и проч, что в репу попадать не должно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #109 Ответы: #139

123. Сообщение от Аноним (122), 05-Июн-23, 21:30	+/–
> git-svn это просто интерфейс к git, позволяющий использовать сервер svn. Вещь иногда > очень полезная, неплохая, но иногда несколько глюбкавая. Он нужен 1 раз в жизни - получить нормальное представление репы из свина. Потом про него можно забыть навсегда.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73

124. Сообщение от Аноним (122), 05-Июн-23, 21:32	+/–
> Как только ты прописываешь адрес сервака, уже идёт централизация. > Нет никаких децентрализованных систем, это бредни. А если я патчи в PACK файл перекидываемый между юзерами флопинетом оформил, центр тогда что? Да, получатель может сделать pull и из вот такого pack с патчами. Ну или вот локальное репо - у него вообще НИКАКИХ серверов не прописано. Даже локалхостовых. И?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47

125. Сообщение от Аноним (-), 05-Июн-23, 21:40	+/–
> это король. В svn так не прокатит. Там сервер правитель всего. Ну и за одно вот это вот svn должен умереть. Задача VCS помогать разработке а не создавать проблемы и ставить палки в колеса разработчику. Git продолжает работать независимо от состояния сервера, наличия интернета и причуд апстрима. И, главное, мотается по версиям со скоростью ракеты. Что для VCS - must have. SVN вечно брыкается - то интернета нет, то сервер дурит, то DNS что-то не то вернул, то еще какая-то лабуда. А вот именно версиями он рулит крайне позорно и медленно, перекачивая на каждый пшит половину репы. Ну и зачем это недоразумение надо?! Ублажать каких-то маразматиков с синдромом собак на сене? Это ортогонально современным и эффективным процессам разработки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #71

126. Сообщение от Аноним (-), 05-Июн-23, 21:42	+/–
> А там всё и не надо держать. По большому счёту для повседневной > работы хватает push, pull, status, add, commit, log. Может ещё что-то > забыл. Всё остальное гуглится в течении минуты, если оно понадобилось. Ну например merge, на случай если ты все же сводишь в репу потенциально конфликтующие комиты эн разработчиков, хоть кто-то 1 на толпу должен уметь такое если в тиме более 1 чела :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43

127. Сообщение от Аноним (-), 05-Июн-23, 21:54	+/–
> Subversion умеет прозрачное зеркалирование сервера, переезд очень легкий: `svn relocate` :) В git вообще понятие переезда не имеет смысла - моя репа не хуже серверной. Если сервер сдох - ну окей, я свою репу куда-то еще залью. Это еще проще. Кстати, минус сетап сервера, если я хотел лишь немного попрограмить по бырому и при этом контроль версий хотел. А потом можно куда-то залить, если хочется. А можно и не заливать. Смотря что надо. У меня есть и несколько локальных проектов, где я пользуюсь всеми прелестями контроля версий. Без сетапа каких либо серверов. И работает это все даже если сервак уже сдох. Т.е. в случае гита какой-то ремотный серв для перекидывания файлами это опция, удобство, а не основа процесса. Его может вообще не быть в ряде случаев. А если он взбрыкнул, это за 5 минут заливается в любой другой реп. Из того что у разработчиков есть. Это вполне себе такие же копии репы. Весьма принципиальная разница.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27

128. Сообщение от Аноним (-), 05-Июн-23, 21:55	+/–
> В случае селфхостед твоя проблема решается копированием репы. Или бекупы гиту не > нужны? YOLO, в случае гита каждая репа у каждого разработчика сама по себе - бэкап.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

129. Сообщение от Аноним (-), 05-Июн-23, 21:56	+/–
Более того - даже если на того майнтайнера или тот сервер упал автобус, или что там, кто угодно может перезалить реп куда ему угодно и подхватить разработку.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #67

130. Сообщение от Аноним (130), 05-Июн-23, 22:21	+/–
> Сравните git и любые другие системы контроля версий - svn один бинарный файл, Это как? Сервак на котором svn крутится явно не 1 файл. А без этого сервака оно столь же полезно как шкурка от сосиски. Без самой сосиски в комплекте. > hg один бинарный файл. Это питономесиво вообще. Какой, к черту, исполняемый файл у горстки питоноскриптов?! > git - 100500 файлов и скриптиков на баше. А какая мне разница в общем то - сколько там файлов? Сказал apt install git и вот оно через минуту готовое. Я ж не буду руками файло по дирам раскладывать, и мне 1 файл или 10, или сколько там - не принципиально. > Видно, что разработчику было интересно делать ядро. А тузу > для версий он склепал тяп-ляп на коленке лишь бы работало. Да вот при этом он реюзанул некоторые знания, в т.ч. о ФС и проч - так что смог в довольно эффективные форматы. Не тормозящие даже на проекте размером в линукскернел. В отличие от. И рабочие процессы логичные, удобные, осмысленные. А не вон тот позор.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #111

131. Сообщение от Аноним (131), 05-Июн-23, 23:16	+/–
> Сравните git и любые другие системы контроля версий - svn один бинарный файл, Сервак svn точно в 1 файл не влезет, без сервака клиент - вообще ни о чем. Он сам по себе ничего не может и не является VCS. > hg один бинарный файл. Hg технически куча скриптов на питоне так то. > git - 100500 файлов и скриптиков на баше. Лучше чем куча скриптов на питоне. В том числе и по скорости работы этого всего. Да и никто не раскидывает эти файлы самолично же. > Видно, что разработчику было интересно делать ядро. А тузу > для версий он склепал тяп-ляп на коленке лишь бы работало. А > оно внезапно взлетело :) Разработчик git хотя-бы в эффективные структуры данных может - так что не клинит даже на проекте размером с линуксный кернел. Hg на чем-то таком тормозит жесточайше просто, а svn никто в здравом уме для такого использовать не будет - там апдейт проекта с сервера, с перекачкой большей части файлов, ждать вообще умрешь. А гит вот может за несколько секунд другую версию даже вот линукскернела выкатить. А хотя-бы и своротив 100К файлов в процессе. И ничего, нормальненоко и ненапряжно так. И взлетело оно не внезапно - а потому что делало то что хотели нормальные мощные кодеры от такой штуки на самом деле. И только. > И теперь все с эттим маются. Мы им не маемся, мы им наслаждаемся. А вы можете SVNом пользоваться если хотите. Мы этого делать не будем. У меня вообще svn уже не установлен: осталось 0 проектов интересных мне которые используют ЭТО. И если опенсорсный проект юзает svn до сих пор - я просто обхожу его за километр^W парсек.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #111 Ответы: #137, #138

132. Сообщение от Аноним (131), 05-Июн-23, 23:18	+/–
> Как то чересчур переусложнили систему. Хрень какая та стала Плохому танцору всегда что-то мешает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #116

133. Сообщение от Аноним (133), 06-Июн-23, 01:28	+/–
> у hg, svn и (с определенными особенностями) перфорсы - тоже есть. Удачи тебе в взаимодействиях. Хорошо когда проприетарщики на самоизоляцию уходят :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #118

134. Сообщение от Электрон (?), 06-Июн-23, 13:02	+/–
Пример хороший, но для другого. После прочтения всё становится на свои места: https://stackoverflow.com/questions/5743739/how-to-really-sh... Потому что семантика "а ввел команды А, Б, получил В" отличается от сеимантики, которой руководствуется content-addressable система типа Git. Для нее старый контент перестал существовать, добавился новый. А то, что там иерархия путей изменилась - это лишь представление, content-addressable системе это все равно. С точки зрения UX соглашусь, но не более. К тому же мы не привыкли к системам адрессирующим по содержанию, они в принципе были раньше невозможны.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #101 Ответы: #140

135. Сообщение от lizard (??), 07-Июн-23, 01:57	+/–
поправить историю? Это зачем и как, как в гите? с оторванными ветками? Во вменяемой системе контроля версий история изменений не может быть изменена, иначе уже это не система контроля версий. История изменений должна отражать реальные изменения, сделанные в процессе работы. В противном случае это не история, а а не фейк. Как у Оруэлла.История свята и священна :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #119 Ответы: #136, #149

136. Сообщение от lizard (??), 07-Июн-23, 01:58	+/–
любое вмешательство в историю превращает ее в фейк
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #135 Ответы: #150

137. Сообщение от lizard (??), 07-Июн-23, 02:03	+/–
Пользуйтесь чем вам удобно, никто не заставляет. Но каша из баша показывает изначальное отношение к тулзе. Поставить пару бинарей на любую платформу не проблема. Но вот гит на винде выглядит довольно чужеродно и монструозно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #131 Ответы: #144

138. Сообщение от lizard (??), 07-Июн-23, 02:06	+/–
причем тут сервак? Речь идет о клиенте. Сервак это вообще отдельная вещь. Попробуйте сравнить с серваком гитхаба - это вообще монстр
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #131 Ответы: #147

139. Сообщение от lizard (??), 07-Июн-23, 02:09	+/–
Тело не должно вообще морочиться. Морочиться должен администратор сервера. svn - для централизованной модели разработки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #122 Ответы: #143

140. Сообщение от lizard (??), 07-Июн-23, 02:13	+/–
ага - в гите вообще нет файлов и путей как сущности :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #134 Ответы: #145

141. Сообщение от lizard (??), 07-Июн-23, 02:15	+/–
нет, вы похоже не совсем понимаете о чем шла речь в примере
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #121 Ответы: #142

142. Сообщение от Аноним (142), 07-Июн-23, 11:37	+/–
> нет, вы похоже не совсем понимаете о чем шла речь в примере О том что вы картинно прострелили сами себе пятку и принялись вопить?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #141

143. Сообщение от Аноним (142), 07-Июн-23, 11:39	+/–
> Тело не должно вообще морочиться. Морочиться должен администратор сервера. Администратор сервера 1 на всю толпу и вообще не обязан знать за вообще всех какие файлы и куски той или иной программы - важные. Откуда ему знать надо этот ключ тут или нет? У некоторых тестовые ключи в репах бывают например. > svn - для централизованной модели разработки. Т.е. для архаичного легаси, по большому счету.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #139 Ответы: #155

144. Сообщение от Аноним (142), 07-Июн-23, 11:56	+/–
> Пользуйтесь чем вам удобно, никто не заставляет. Но каша из баша показывает ...что писавший его 1) умел в модуляризацию и субзадачи 2) знал где критично, на си, а где можно и макет на баше на время накатать 3) догадывался что монилитный дизайн не рулит совсем никак 4) в отличие от вон тех умел в нормальные workflow и структуры данных, чтобы делать то что на самом деле хотят програмеры и не иметь проблем с перфомансом даже на большом проекте. > изначальное отношение к тулзе. Поставить пару бинарей на любую платформу не > проблема. Но вот гит на винде выглядит довольно чужеродно и монструозно. Винда вообще не бог весть какая девелоперская система. Я ставлю либы 1 командой пакетника. В винде... изначально вообще пакетника нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #137 Ответы: #157

145. Сообщение от Аноним (142), 07-Июн-23, 12:05	+/–
> ага - в гите вообще нет файлов и путей как сущности :) Что к лучшему - не брыкается при рефакторах кода. Но чтобы это знать надо уметь програмить и даже только подумайте рефакторить свой код.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #140

147. Сообщение от Аноним (142), 07-Июн-23, 12:11	+/–
Git сам по себе изначально не клиент и не сервер, он VCS. Симметричный и самодостаточный, по большому счету. Серверов может не быть совсем, если я скажем git pack перепидывался и делал pull из вот такой вот дельты переданой хоть флопинетом на флешке. SVN так ессно не умеет и уметь не может.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #138 Ответы: #156

148. Сообщение от Аноним (142), 07-Июн-23, 12:12	+/–
> понятнее жать в контекстном меню 7z -> > архивировать. Не очень понимаю как при таком пускании пузырей программировать что-то получается. А git bisect средствами 7z интересно как выполняется? Я бы на это посмотрел! :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34

149. Сообщение от Серб (ok), 07-Июн-23, 12:59	+/–
Допустим один из разработчиков внес в проект код украденный из другого проекта. Через 5-ть лет на вас подали в суд. Ваши действия?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #135 Ответы: #153, #158

150. Сообщение от Серб (ok), 07-Июн-23, 13:03	+/–
> любое вмешательство в историю превращает ее в фейк сама по себе история никому не нужна нужны понятные и обоснованные изменения Блуждания в поиске подходящей реализации оставьте у себя в локальной ветке
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #136 Ответы: #151

151. Сообщение от lizard (??), 08-Июн-23, 00:25	+/–
правильная история помогает найти сточник ошибок, регрессии и т.п. При редактировании истории в git можно получить некомпилируемые коммиты, оторванные ветки и подобные проблемы. Гит строго говоря вообще не система контроля версий. (Но эт о не значит что гит плох. Он имеет свои плюсы и минусы как и любой тул)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #150 Ответы: #152, #163

152. Сообщение от lizard (??), 08-Июн-23, 00:29	+/–
> нужны понятные и обоснованные изменения для этого нужно правильно и обоснованно работать: нормально организовать свой workflow - органические коммиты, trunk-based и т.п. Причем и в любой vcs,включая git. Красивая фейковая история только создает проблемы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #151 Ответы: #162

153. Сообщение от lizard (??), 08-Июн-23, 00:30	+/–
в svn? `svn rm` :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #149 Ответы: #154, #161

154. Сообщение от lizard (??), 08-Июн-23, 00:32	+/–
`git rm`
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #153

155. Сообщение от lizard (??), 08-Июн-23, 00:43	–1 +/–
нет, для корпораций, с тенденцией к по возможности максимальному контролю. Вы когда-нибудь работали с военными или энергетиками? certification, compliance? Это не опен сорс с гитхабчиком, это нечто совершенно отдельное. И там централизованный workflow с обязательной политикой, правами доступа и прочим - необходимость.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #143

156. Сообщение от lizard (??), 08-Июн-23, 00:49	+/–
Строго говоря рн не vcs совсем, так как тут нет ни версий ни файлов. git это система управления контентом. > Симметричный и самодостаточный, по большому счету. В этом может быть и преимущество и недостаток. Я же не говорю что git это что-то плохое. Просто вокруг него много фанатизма
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #147

157. Сообщение от lizard (??), 08-Июн-23, 00:54	+/–
...что писавший его думал в первую очередь об облегчении своего личного труда в своем конкретном проекте (это не есть плохо) и по фигу другие workflow, платформы и все остальное. ну и интерфейс git'а это одна большая прооблемя
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #144

158. Сообщение от lizard (??), 08-Июн-23, 11:13	+/–
Ну от вам другой пример. Вя инженер делаете  NASAMS и через пять лет ракета взрывается на старте или летит в зад запускающему. Поднимаете код и видите что история гита отредактирована, ветка пропала, коммит с предполагаемой ошибкой испорчен в результате правки истории и не компилируется вообще. Зато история выглядит красиво и изменения (месседжи?) выглядят обоснованными. Кто сидеть-то будет?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #149 Ответы: #160

159. Сообщение от lizard (??), 08-Июн-23, 11:41	+/–
>[оверквотинг удален] > > нет, потому что он сам закопался. > > Во-первых автор ядра покинул проект в первый же год его существования (и да, это большие боссы но они играли не за гит а за мертворожденный биткипер). С тех пор много казавшихся тривиальными вещей так и не были реализованы или реализованы криво. > Во-вторых был выбран фантастически неудачный язычок с отступами (внезапно, даже перл на котором все еще написаны отдельные куски гита жив и портирован на мильен платформ, а вот впихон2 - таки всьо) > В-третьих, гитхап и гитляп, да. > > Третий пункт не имел бы определяющего значения, если бы автор не повторил изначальную ошибку гита - отсутствие хотя бы номинальной авторизации и разделения пользователей из коробки. То что позволяло svn как быть самодостаточным, так и легко интегрироваться в системы контроля версий. > > P.S. еще вишенка на тортике - неудавшаяся попытка начать переписывать. Ну вы поняли, на чем и чем кончилось. А время шло... Основной урок тут такой: никогда не связывайтесь с питоном, если нужно sustainability дольше чем пара лет. Даже фортран лучше, он хоть поддерживается  ISO  и обратно совместим с древностями. Питон только для короткоживущих скриптиков.
Ответить | Правка | Наверх | Cообщить модератору

160. Сообщение от Серб (ok), 08-Июн-23, 12:55	+/–
Во первых: Кто-нибудь, когда-нибудь сел? Во вторых: Два типа репозиториев - это вполне норма для корпораций: один публичный; другой непубличный; В публичном удаляется то, что нужно удалить по закону. В третьих: Релизы бывают сравнительно редко и до их выхода история должна быть переработана так, что бы рецензенты могли легко понять изменения. Ничего лишнего. Ни одного патча исправляющего ошибку в предыдущем патче. И вот такая история должна храниться. Можно и дальше делать вид, что идеология требует неизменяемой истории. А можно признать, что на этапе проектирования была допущена ошибка в выборе системы хранения, не позволяющая реализовать нужный функционал.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #158 Ответы: #165, #166

161. Сообщение от Серб (ok), 08-Июн-23, 12:57	+/–
> в svn? `svn rm` :) История доступна. Код в истории доступен. Решения суда не выполнили.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #153 Ответы: #168

162. Сообщение от Серб (ok), 08-Июн-23, 12:57	+/–
>> нужны понятные и обоснованные изменения > для этого нужно правильно и обоснованно работать: нормально организовать свой workflow > - органические коммиты, trunk-based и т.п. Причем и в любой vcs,включая > git. Красивая фейковая история только создает проблемы. Вы из тех, кто никогда не ошибается?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #152 Ответы: #164, #167

163. Сообщение от Серб (ok), 08-Июн-23, 13:33	+/–
> правильная история помогает найти сточник ошибок, регрессии и т.п. Именно при редактировании истории этот процесс становится на порядок проще реализовать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #151

164. Сообщение от lizard (??), 09-Июн-23, 16:59	+/–
Все ошибаются. Ошибка это тоже часть истории. Не нужно ее прятать
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #162 Ответы: #169

165. Сообщение от lizard (??), 09-Июн-23, 20:14	+/–
> Кто-нибудь, когда-нибудь сел? У вас всегда есть шанс :) Ну и про NASAMSы мы не знаем, все секретно. Систематическая ошибка выжившего
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #160

166. Сообщение от lizard (??), 09-Июн-23, 20:19	+/–
> Два типа репозиториев - это вполне норма для корпораций: > один публичный; Вот и правьте историю в публичном репозитарии для красоты. Или вообще выкладывайте zip. Это почти не имеет отношения к контролю версии при разработке. Это вопрос управления контентом, дистрибуции и т.п. Я же не утверждяю что гит не подходит для выкладывания кода ни гитхабе. Большинство VCS умеют экспортировать/зеркалировать  в git
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #160 Ответы: #171

167. Сообщение от lizard (??), 09-Июн-23, 20:27	+/–
> Все ошибаются. Ошибка это тоже часть истории. Не нужно ее прятать возможно в случае ошибки имеет смысл править сообщение коммита post hoc, для маркировки, идентификации ошибки, описания и т.п. Но лишь тольтко лейбл, а не changeset. В svn кстати есть возможность редактировать commit message, не затрагивая changeset.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #162

168. Сообщение от lizard (??), 10-Июн-23, 12:08	+/–
Почему же? Ветка удалена, в публичном доступе украденного кода нет. В текущих ветках его тоже нет. Возможность работать с веткой можно заблокировать контролем доступа, если нужно. Это все работает в разных VCS, d svn и например в Perforce. Кстати, если речь касается именно svn, то таки да, можно удалить ветку из репозирория, но это довольно замороченный метод, хотя и официально документированный насколько я помню в svnbook. Но это крайний случай, если дело очень серьезное и в суде придти к договоренности не удалось. По поводу украденного кода в репе андроид-фонарика или фейсбучка можно придти к договоренности в суде. Но вот если правка истории изменений кода сделала невозможно расследование авиационной катастрофы или аварии на АЭС - это намного серьезнее. Тут люди погибли и это надо досконально расследовать, изучая все коммиты в том виде и в том порядке, в котором они были сделаны в свое время, не скрываю ошибок, экспериментов и странностей внесенных разработчиками.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #161 Ответы: #170

169. Сообщение от Серб (ok), 13-Июн-23, 13:26	+/–
> Все ошибаются. Ошибка это тоже часть истории. Не нужно ее прятать Зачем рецензенту продираться сквозь ошибки?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #164

170. Сообщение от Серб (ok), 13-Июн-23, 13:29	+/–
> Ветка удалена Удалять ветку, которая давно уже вмержена в основную, ну, или, отребейзена? Каков результат такого удаления?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #168

171. Сообщение от Серб (ok), 13-Июн-23, 13:33	+/–
>> Два типа репозиториев - это вполне норма для корпораций: >> один публичный; > Вот и правьте историю в публичном репозитарии для красоты. Или вообще выкладывайте > zip. Это почти не имеет отношения к контролю версии при разработке. > Это вопрос управления контентом, дистрибуции и т.п. Я же не утверждяю > что гит не подходит для выкладывания кода ни гитхабе. Большинство VCS > умеют экспортировать/зеркалировать  в git Тут, очевидно, что разница глобальная. Публичная история должна быть красивой (без безобразий) что бы привлекать новых разработчиков, так как в таком случае большее число людей сможет разобраться: как, что и почему было сделано. Если у вас нет рецензентов и вы не заинтересованы в притоке новых разработчиков, то да, можете хранить историю блуждания в поисках подходящей реализации.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #166

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

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