| |
| |
| 3.7, Yowayowa Sensei (?), 11:56, 30/06/2026 [^] [^^] [^^^] [ответить]
| +2 +/– | |
Так одно создавалось для другого. Неудивительно почему получился паршивый продукт. Не говоря о том, что абсолютное большинство коммерческих и любительских проектов используют централизованную модель разработки (через github, gitLab или bitbucket).
Многие распределенные возможности git остаются невостребованными, но разработчики все равно вынуждены нести накладные расходы на их понимание и обслуживание (например, разбираться с разницей между git fetch и git pull, настраивать upstream-ветки).
| | |
| |
| 4.9, Аноним (9), 12:03, 30/06/2026 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> разбираться с разницей между git fetch и git pull
Ну, пользователей же вынуждают разбираться с разницей между скачиванием документа/программы/песенки и их открытием/запуском/прослушиванием. Так в чём проблема увидеть разницу между git fetch и git pull? Не говоря уж о том, что git pull вообще не особо нужная команда, я вообще ей пользовался десяток раз, чтобы подтянуть изменения чужих репозиториев и пересобрать исходник. Для своих репозиториев удобнее git fetch+git merge.
| | |
| |
| 5.14, одвто7 (?), 12:23, 30/06/2026 [^] [^^] [^^^] [ответить]
| +2 +/– |
Глупости, pul как раз одна из популярных команд!
git pull
git add .
git commit -m "..."
git push
Это покрывает 90% работы с гитом, всё остальное это уже рукоблудие 😁
| | |
| |
| 6.22, Аноним (22), 12:47, 30/06/2026 [^] [^^] [^^^] [ответить]
| –1 +/– |
А весь этот винегрет можно было заменить какой-нибудь одной git sync "superhotfix 128"
| | |
|
|
| 4.19, Аноним (19), 12:39, 30/06/2026 [^] [^^] [^^^] [ответить]
| –1 +/– |
Попробуй предложить, чтобы из гита удалили лишнее, что используется для децентрализованной разработки.
Сообщество™ Борцунов за Щв06одьку™ будет тебя поливать помоями, даже если они не используют эти фичи))
| | |
|
|
| 2.8, Аноним (8), 12:02, 30/06/2026 [^] [^^] [^^^] [ответить]
| –2 +/– | |
> Когда у меня интересуются, что я считаю оверинжинирингом, я не задумываясь отвечаю, что это git
Программы можно разделить на те которые оверинжиниринг, и те которые нафиг никому не нужны.
Как показывает практика мир вокруг - весьма сложная штука, поэтому софт тоже становится сложным.
А всякие suckless поделки на практике могут только suck ¯\_(ツ)_/¯.
| | |
| |
| |
| 4.21, aname (ok), 12:43, 30/06/2026 [^] [^^] [^^^] [ответить]
| +/– |
Ещё один воен против рыночка.
Да, в принципе, только благодаря ему что- то кроме … существует.
| | |
|
| 3.20, aname (ok), 12:41, 30/06/2026 [^] [^^] [^^^] [ответить]
| +/– |
> Программы можно разделить на те которые оверинжиниринг,
> и те которые нафиг никому не нужны.
Ох уж эти ложные дихотомии
> мир вокруг - весьма сложная штука, поэтому софт тоже становится сложным.
Не поэтому.
> А всякие suckless поделки на практике могут только suck
Против KISS воюем?
| | |
| |
| 4.25, Аноним (19), 12:52, 30/06/2026 [^] [^^] [^^^] [ответить]
| +/– | |
> Ох уж эти ложные дихотомии
Ложность не доказывается твоим комментарием)
>> мир вокруг - весьма сложная штука, поэтому софт тоже становится сложным.
> Не поэтому.
Поэтому. Сложные предметные области порождают сложный софт.
Так как гит делался как децентрализованная штука - то сработала теорема Брюера.
Поэтому он получился сложный.
Можно конечно выкинуть половину кода со словами "а мне и так сойдет", но на выходе получится штука у которой не будет всех возможностей гита.
>> А всякие suckless поделки на практике могут только suck
> Против KISS воюем?
А что против нее воевать? Принцип классный на бумаге, а в реальности получается то что получается)
На UNIX-way тоже поколения какеров наяривали, и где теперь UNIX со своим way?
| | |
| |
| 5.39, e (??), 13:43, 30/06/2026 [^] [^^] [^^^] [ответить]
| +/– | |
> и где теперь UNIX со своим way?
Примерно везде? Начиная с Intel ME до автомобилей, самолётов, ракет, мед. оборудования, суперкомпьютеров и тд
| | |
|
|
|
| 2.12, q (ok), 12:07, 30/06/2026 [^] [^^] [^^^] [ответить]
| +/– |
Напоминаю, что ты не обязан пользоваться ВООБЩЕ ВСЕМ функционалом гита. Оверинжиниринг -- это когда что-то сделали, а оно могло быть проще. Так вот: приведи конкретный пункт, в котором что-то в гите могло быть проще. Хотя бы один пункт. Вот прям ща. Ты же отвечаешь за свои слова, верно? Или просто газифицируешь лужу? Один пункт. Не два, не три, а всего один.
| | |
| |
| 3.17, e (??), 12:33, 30/06/2026 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Оверинжиниринг -- это когда что-то сделали, а оно могло быть проще.
Не только. Из Cambridge Dictionary:
over-engineer --- to create, design, or build something to be more complicated or perform more actions than is necessary or helpful.
Вторая часть как раз к гиту и подходит
| | |
| |
| 4.18, q (ok), 12:35, 30/06/2026 [^] [^^] [^^^] [ответить]
| +/– |
> Вторая часть как раз к гиту и подходит
Отлично! А теперь ты берешь - и приводишь функционал в гите, которым вообще никто не пользуется: ни пользователи, ни другие системы вроде cgit, GitLab etc. Давай. Прям ща. Хоп! - и приводишь ОДНУ такую вещь.
| | |
| |
| 5.36, e (??), 13:26, 30/06/2026 [^] [^^] [^^^] [ответить]
| +/– | |
> приводишь функционал в гите, которым вообще никто не пользуется
Такого функционала просто не может быть, гит слишком распространен, добавь туда хоть аудиоплеер, им хоть кто-то да будет пользоваться.
> ни другие системы вроде cgit, GitLab etc
Так в этом и проблема, по видимому. Git превращается (или уже превратился) из простой СКВ, в некий "бэкенд" для крупных сервисов, судя по последним чейнджлогам. И вариант "просто не пользоваться" избыточным функционалом не прокатывает. На все эти лишние команды приходится обращать внимание, просто потому что они есть, ну, ты же как бы инструмент изучаешь, его желательно "полностью" освоить. И выходит, что для изучения простого доп. инструмента, который вроде работу облегчать должен, нужно времени больше, чем для изучения какого-нибудь ЯП.
| | |
| |
| 6.40, q (ok), 13:44, 30/06/2026 [^] [^^] [^^^] [ответить]
| +/– |
> добавь туда хоть аудиоплеер, им хоть кто-то да будет пользоваться
Функционал аудио-плеера не принадлежит домену управления ревизиями дерева исходников. Приведи функционал, который удовлетворяет следующим критериям:
относится_к_теме_гита && (могло_быть_проще || никто_не_пользуется)
> Git превращается (или уже превратился) из простой СКВ, в некий "бэкенд" для крупных сервисов
Всегда был таким, доброе утро. Хочешь попроще? Пользуйся "Новой папкой (42)" и "Отчет-финальный-финальный-точно-финальный-5-после-правок-8.docx".
> вариант "просто не пользоваться" избыточным функционалом не прокатывает
Прокатывает. Я ими не пользуюсь.
> На все эти лишние команды приходится обращать внимание
Не приходится. О существовании большинства из них я даже не в курсе.
> ты же как бы инструмент изучаешь, его желательно "полностью" освоить
Нет. Инструмент осваиваешь ровно настолько, насколько лично тебе нужно. Скажем, ты даже свой телевизор освоил лишь на 10% - и все равно успешно пользуешься им годами. А вот ты попробуй потыкать по менюхам и на все кнопки пульта -- откроешь для себя редчайшие 90% функционала.
> нужно времени больше, чем для изучения какого-нибудь ЯП
А ЯП ты как изучаешь? По учебникам, в которых объясняется только то, что нужно тебе? Или читаешь стандарт от корки до корки, включая BNF синтаксиса? Вот то-то же и оно. Ты и ЯП не "полностью" осваиваешь.
| | |
|
|
|
| 3.23, Аноним (23), 12:48, 30/06/2026 [^] [^^] [^^^] [ответить]
| +/– | |
>Оверинжиниринг -- это когда что-то сделали, а оно могло быть проще
вы ошиблись
| | |
| 3.31, НектоОткудаТо (?), 13:08, 30/06/2026 [^] [^^] [^^^] [ответить]
| +/– |
Не с целью поругаться, но по поводу "проще" - вот не могу назвать detached head удобной концепцией для тех, кто хочет перейти на произвольный коммит. Допускаю, что Вам и многим другим это может казаться простым. А вот мне и многим другим это простым не кажется. Вывод - что не просто для всей целевой аудитории, то простым не является.
| | |
| |
| 4.35, q (ok), 13:25, 30/06/2026 [^] [^^] [^^^] [ответить]
| +/– |
Ты не отличаешь "сложно" от "оверинжиниринг"? Извиняй чувак, но реальные самолеты управляются чуточку сложнее, чем WASD-клавиши (даже если ты на 146% уверен, что WASD хватает! тебе в играх их хватало во всяком случае!)
| | |
|
|
| 2.37, хрю (?), 13:36, 30/06/2026 [^] [^^] [^^^] [ответить]
| +2 +/– | |
git без оверинжиринга называется hg +). До сих пор до конца не умер. Для 95% коммерческих разработок его возможностей заглаза.
Но интеграций уровня gitlab к сожалению нема, отсюда и проистекает к сожалению предсмертное состояние.
| | |
|
| 1.3, Аноним (3), 11:52, 30/06/2026 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Ждём форка или независимой реализации на любом языке из набора GCC. Gccrs ещё не готов.
| | |
| |
| 2.10, Аноним (10), 12:04, 30/06/2026 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Ждём форка или независимой реализации на любом языке из набора GCC. Gccrs ещё не готов.
Но зачем?
Оно отлично собирается clang/llvm под свободной лицензией.
Зачем делать форк для гнуракового убожества?
| | |
| |
| 3.15, Аноним (3), 12:24, 30/06/2026 [^] [^^] [^^^] [ответить]
| –1 +/– |
Потому что, GCC forever! Лучше, чтобы весь бинарный код был сгенерирован одним кодогенератором. По крайней мере, код базовых компонентов системы.
| | |
| |
| 4.41, Аноним (41), 13:52, 30/06/2026 [^] [^^] [^^^] [ответить]
| +/– |
Угу, часть крейтов фейлится или компилится неправильно, если шланг не единственный компилятор в системе. Я знал, что растолюбы тупые, но такой дичи не ожидал. Ну, чтобы не быть голословным, присмотрись к proc-macro2.
| | |
|
| 3.42, Аноним (42), 13:54, 30/06/2026 [^] [^^] [^^^] [ответить]
| +/– |
Потому что иметь один компилятор в виде rustc - потенциальная проблема с бэкдором. Единая точка для встраивания вредоносного кода. Нет альтернативных компиляторов. Рано или поздно стрельнет такая штука как описывал Кен Томпсон в "Reflections on Trusting Trust".
| | |
|
|
|