LINUX.ORG.RU
ФорумTalks

git is really stupid and made by stupid

 linus benedict poettering


0

3

gcc можно собирать вмести с binutils, newlib и прочими библиотеками и инструментарием GNU (например gdb) в так называемом combined tree, тоесть из сведённого в одно дерево исходников. Например если вы распаковали исходники gcc-7.2.0 и binutils-2.29.1 вы можете свести их в одно дерево (одну директорию) командами:

rsync -au gcc-7.2.0/ combined-gcc-7.2.0/
rsync -au binutils-2.29.1/ combined-gcc-7.2.0/

Это работает благодаря тому, что оба проекта используют единую базу инфраструктурного кода gcc и периодически синхронизируются между собой. Но если вы попытаетесь точно так же добавить ещё и код newlib-2.5.0.20170922 вы испортите combined-gcc-7.2.0 и в частности файл include/dwarf2.h

Почему это происходит? Потому что git не умеет сохранять даты модификаций файлов. В итоге git выставляет текущую дату и время в качестве даты модификации файла всякий раз, когда изменяет его содержимое после таких команд как git clone или git checkout.

В git репозитории проекта newlib файл include/dwarf2.h последний раз модифицировался аж в 2016-06-23, но в тарбале newlib-2.5.0.20170922 дата его модификации 2017-09-19:

https://sourceware.org/git/?p=newlib-cygwin.git;a=history;f=include/dwarf2.h
ftp://sourceware.org/pub/newlib/newlib-2.5.0.20170922.tar.gz

В git репозитории проекта binutils, после 2016-06-23 и до создания тага релиза binutils-2_29_1.1, этот же файл модифицировался три раза, последний раз 2017-07-02. Одно из изменений, отсутствующее в newlib-2.5.0.20170922 - добавление внешней функции get_DW_IDX_name

https://sourceware.org/git/?p=binutils-gdb.git;a=history;f=include/dwarf2.h;h...

Но поскольку дата модификации include/dwarf2.h в тарбале newlib-2.5.0.20170922 неверная и якобы новее, rsync оставляет именно её вместо действительно более новой версии из binutils.

Проблема не новая, с Линусом уже перетёртая и я далеко не первый, кто назвал его решение глупым. Кстати, в Mercurial такой проблемы нет. В старых системах управления версиями (CVS, SVN) её тоже не было. Линус решил, что он самый умный и вот результат. Ну чем не Поттеринг?

★★★★★

Ответ на: комментарий от tailgunner

Я думал, разбирается ситуация, когда они этого не делают и повлиять на это невозможно.

Так они этого не делают. Я ведь не ради празного любопытства пытаюсь создать combined tree.

Или rsync -auc

Как флаг -c поможет определить какая из трёх версий include/dwarf2.h более новая?

bbk123 ★★★★★
() автор топика
Ответ на: комментарий от Iron_Bug

Хорошо. Будем считать, что они все разные и это типа правильно и очень удобно(на самом деле нет). И что авторы всех этих несовместимых друг с другом мейков на самои деле не психически больны.

Но вот про скрипты я абсолютно не согласен. На каждый мейкфайл ты должна знать под какой мейк он написан. Спасибо GNU, что они сейчас везде, за исключением бздшников, которые по религиозным соображениям не хотят GPL-ный код.

А вот теперь про аутизмотулсы. Насколько я знаю, этот набор костылей требует m4 и sh. Если с m4 проблем нет, то у sh ровно та же самая проблема: каждый пишет его как хочет. Я уже не говорю о том как работают аутизмотулсы. Генератор ехал через генератор, называется.

a1batross ★★★★★
()
Ответ на: комментарий от bbk123

Синхронизировать должны разработчики

Я думал, разбирается ситуация, когда они этого не делают и повлиять на это невозможно.

Так они этого не делают

/me shrugged

Если они этого не делают, придется тебе. Если не хочешь/не можешь использовать git-subtree/git-submodules - придется вручную. И бесполезно жаловаться «это должны они».

Как флаг -c поможет определить какая из трёх версий include/dwarf2.h более новая?

Очевидно, что никак. Но если ты настаиваешь на использовании именно rsync, то вызывай команды в правильном порядке и используй -c.

tailgunner ★★★★★
()
Ответ на: комментарий от a1batross

А вот теперь про аутизмотулсы. Насколько я знаю, этот набор костылей требует m4 и sh. Если с m4 проблем нет, то у sh ровно та же самая проблема: каждый пишет его как хочет

autotools используют стандартизированное подмножество шелла.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Если они этого не делают, придется тебе. Если не хочешь/не можешь использовать git-subtree/git-submodules - придется вручную. И бесполезно жаловаться «это должны они».

Мне бесполезно использовать git-subtree/git-submodules с кодом gcc поскольку этого не делают сами разработчики. И мерджить их код в ручную я не могу по банальной причине - я не являюсь разработчиком всех этих проектов одновременно и поэтому недостаточно хорошо знаком со всем его нутром. Если разработчики заявляют об официальной поддержке combined tree, они должны позаботиться о том, чтобы не разработчики могли такой combined tree относительно легко создать.

bbk123 ★★★★★
() автор топика
Ответ на: комментарий от tailgunner

Очевидно, что никак. Но если ты настаиваешь на использовании именно rsync, то вызывай команды в правильном порядке и используй -c

Я не наставива, я лишь не нашёл ничего лучше. И флаг -c тут не нужен, даже если бы git не портил дату модификации файлов.

bbk123 ★★★★★
() автор топика
Ответ на: комментарий от bbk123

Твоя проблема с актуализированными версиями дат высосана из пальца.

Combined-Tree достаточно хрупок и сложен в обслуживании, я думаю из разработчиков его использует лишь малая часть и только на проверенных архивах.

rsync'ая сорцы в combined-tree ты рано или поздно столкнёшься с какими-нибудь проблемами сборки в лучшем случае, а в худшем всё соберётся, но работать будет с heisenbug'ами из-за смешивания кода.

Если бы разработчик этой newlib поставлял сорцы вообще в каком-нибудь формате архива без сохранения даты файлов или ручками делал touch *, то Git здесь был бы ни при чём, но проблема бы осталась.

А потому что полагаться на даты файлов, как это делаешь ты, это всё равно что стрелять себе по ногам.

Если живущий в каком-нибудь Петропавловске-камчатском (у них там уже 4 декабря) вот прям сейчас зальёт тебе тарбалл сорцов, которые ты скачаешь сидя в Тель-Авиве и попытаешься их собрать, то есть шанс, что твой make вообще уйдёт в while(1) пока у тебя не наступит завтра.

Не помню, решили этот баг с make или нет, но я с таким сталкивался.

Почему остальные разработчики должны подстраивать под git годами если не десятилетиями прекрасно живущие проекты?

Я уверен, что остальные разработчки давным-давно забыли про Combined Tree и у них отпало это множество проблем, как класс.

EXL ★★★★★
()
Ответ на: комментарий от kirk_johnson

Ээээ... то есть если бы эти файлы действительно обновились, то все тоже сломалось бы?

Нет конечно, не сломалось бы. Осталась бы действительно самая новая версия этого общего, для нескольких проектов, файла.

Не говоря уже о том, что CVS и SVN централизованные системы.

Почему ты забыл про Mercurial?

P.S. Выставь ключ, чтобы rsync по содержимому сравнивал, и не ной.

А ты забавный. В твоём rsync есть искуственный интеллект?

bbk123 ★★★★★
() автор топика

В GIT'е есть множество других актуальных проблем и недостатков:

  • Нет понятия докачки/дозагрузки из-за чего на нестабильных мобильных соединениях работа с GIT'ом превращается в ад.
  • Нет возможности добавить пустые каталоги в репозиторий и определить/запланировать этим действием будущую структуру проекта.
  • Проблемы с восстановлением БД при различных факапах. Несколько раз натыкался на повреждение базы и полную неработоспособность и невозможность восстановления репозитория из-за, скажем так, внезапного отключения электричества при работе с репозиторием. Спасала только децентрализация и привычка отправлять коммиты в удалённые репозитории сразу после их создания.
  • Достаточно неочевидная работа с несколькими подпроектами как с помощью Git submodules, так и с помощью Git subtrees. Можно было сделать куда как проще.
  • Невозможность редактирования COMMIT_MSG отдельно от самого коммита, в итоге в крупных проектах везде очепятки и не слишком подробные сообщения, которые можно было бы исправить и дополнить полезными заметками, но с переписыванием всей истории никто не хочет заморачиваться

Куча их, но ты выбрал самую незначительную проблему, которую и проблемой-то с трудом можно назвать.

EXL ★★★★★
()
Последнее исправление: EXL (всего исправлений: 2)
Ответ на: комментарий от system-root

общепринятое, ещё когда «деды код писали», эту дичь что, стандартизировали?

Как думаешь, каким образом твоя система сборки узнает, что изменился конкретный файл, и нужно пересобирать зависимые от него объекты?

baka-kun ★★★★★
()
Ответ на: комментарий от baka-kun

Как думаешь, каким образом твоя система сборки узнает, что изменился конкретный файл

Зависит от системы. Некоторые считают хеш-суммы, некоторые следят за изменениями.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Зависит от системы. Некоторые считают хеш-суммы, некоторые следят за изменениями.

А чо из открытого считает суммы?

P.S. Scons вроде умеет.

kirk_johnson ★☆
()
Последнее исправление: kirk_johnson (всего исправлений: 1)
Ответ на: комментарий от tailgunner

Зависит от системы. Некоторые считают хеш-суммы, некоторые следят за изменениями.

Ну да, scons считает md5 файлов. Немудрено, что он такой тормоз. Но для простой и быстрой системы достаточно сравнить время правки.

baka-kun ★★★★★
()
Ответ на: комментарий от EXL

Куча их, но ты выбрал самую незначительную проблему, которую и проблемой-то с трудом можно назвать.

Я не выбирал, я на эту проблему наткнулся на практике. При этом сам git я не использовал, а лишь скачал тарбол.

bbk123 ★★★★★
() автор топика
Ответ на: комментарий от EXL

Невозможность редактирования COMMIT_MSG отдельно от самого коммита

Это как раз фича.

tailgunner ★★★★★
()
Ответ на: комментарий от baka-kun

Это стандартное решение во всех системах сборки, контроля версий и резервного копирования.

Если бы это было стандартным решением, сломались бы не только гнутые мегаподелки.

hateyoufeel ★★★★★
()
Ответ на: комментарий от kirk_johnson

А чо из открытого считает суммы?

Сейчас проверил:

Gradle считает какие-то хеши, пофиг на время.

QBS, так же как и make, ориентируется на время.

Meson, так же как и make, ориентируется на время.

EXL ★★★★★
()
Ответ на: комментарий от hateyoufeel

Если бы это было стандартным решением, сломались бы не только гнутые мегаподелки.

А где здесь «сломались гнутые мегаподелки»? Git?

Прости, как ты собираешься из трех файлов include/dwarf2.h найти самый свежий, если кто-то (не будем показывать пальцем, хотя это был git) похерил время правки?

baka-kun ★★★★★
()
Ответ на: комментарий от baka-kun

Идея Combined Tree изначально ущербна.

Что, если новый include/dwarf2.h будет содержать правки, которые сломают сборку других проектов в combined tree? И даты файов, и Git, и Hg тут вообще будут ни при чём.

То есть здесь ещё и версии инструментов нужно тщательно подбирать, чтобы оно хоть как-то было работоспособно.

Куча проблем, а полезного выхлопа ноль.

EXL ★★★★★
()
Последнее исправление: EXL (всего исправлений: 1)
Ответ на: комментарий от kirk_johnson

Чей хеш в ветке выше, того и старше.

То есть к трем файлам на руках нужно раздобыть какую-то дополнительную информацию по sideband каналу? И метаданных самих файлов нам недостаточно?

А, ну да, нам же их git испортил. Давайте придумывать проблемы, чтобы их героически потом решать.

baka-kun ★★★★★
()
Ответ на: комментарий от EXL

Что, если новый include/dwarf2.h будет содержать правки, которые сломают сборку других проектов в combined tree?

Значит будет regression и поломана обратная совместимость. Ответственный за коммит получит по шапке, и в следующий раз постарается не сломать билд.

baka-kun ★★★★★
()
Ответ на: комментарий от baka-kun

Я сейчас посмотрел, проект newlib вообще не от GNU. То, что они там сделали кривую совместимость с combined tree для GCC, не значит абсолютно ничего. С таким же успехом они и вовсе могли на него забить, и чего?

EXL ★★★★★
()
Ответ на: комментарий от bbk123

Если разработчики заявляют об официальной поддержке combined tree, они должны позаботиться о том, чтобы не разработчики могли такой combined tree относительно легко создать.

Разработчики какого проекта заявляют? GCC или Newlib?

EXL ★★★★★
()
Ответ на: комментарий от EXL

Что, если новый include/dwarf2.h будет содержать правки, которые сломают сборку других проектов в combined tree?

Не будет, потому что все эти проекты периодически синхронизируют общий код, в том числе и этот include/dwarf2.h

bbk123 ★★★★★
() автор топика
Ответ на: комментарий от baka-kun

Я так и не понял, причем тут Git. Если ты тарболы скачал, то там время правильное. Если ты один тарбол заменил слитым из Git кодом, то сам виноват.

kirk_johnson ★☆
()
Ответ на: комментарий от EXL

Я сейчас посмотрел, проект newlib вообще не от GNU.

И что? А если завтра кто-то сломает stdlib.h?

baka-kun ★★★★★
()
Ответ на: комментарий от kirk_johnson

Я так и не понял, причем тут Git.

Насколько я понял ТС, тарболы создаются из слитого из git кода. То есть с заведомо поломанным временем файлов.

baka-kun ★★★★★
()
Ответ на: комментарий от EXL

Я сейчас посмотрел, проект newlib вообще не от GNU.

Не важно кто разработчики. Важно, что newlib - часть GNU. Например тот же gcc configure имеет флаги, связанные с этим newlib.

bbk123 ★★★★★
() автор топика
Ответ на: комментарий от bbk123

Если я возьму tarball самого нового GCC и tarball самого старого newlib, потом смешаю их в combined tree, всё будет компилироваться и работать?

EXL ★★★★★
()
Ответ на: комментарий от baka-kun

Насколько я понял ТС, тарболы создаются из слитого из git кода. То есть с заведомо поломанным временем файлов.

Так и есть.

bbk123 ★★★★★
() автор топика
Ответ на: комментарий от bbk123

Нет, это важно.

Сорцы Newlib вообще на серверах RedHat и не входят в GNU. Я специально зашёл в репозиторий и на офф сайт бибилиотеки и посмотрел в README и в документацию. Нигде там не нашёл упоминания про combined tree или про то, что сперва нужно скачать gcc и потом развернуть исходники newlib в дерево gcc.

Если проект GNU GCC взял эту библиотеку в свою экосистему, и завязал на combined tree, то они и должны tarball'ы редхата выправлять ручками, чтобы этот combined tree работал.

Ты скачал tarball с сайта RedHat, которые, похоже и слухом не слыхивали про этот Combined Tree от GNU, а виноват, внезапно, git?

EXL ★★★★★
()
Последнее исправление: EXL (всего исправлений: 2)
Ответ на: комментарий от EXL

Ты скачал tarball с сайта RedHat, которые, похоже и слухом не слыхивали про этот Combined Tree от GNU, а виноват, внезапно, git?

Слыхивал и ещё как слыхивал. Они используют общую инфраструктуру с gcc. Более того, эта инфраструктура имеет явный механизм интеграции с newlib (configure --with-newlib). Не хотели бы они этого, сделали бы так же, как всякии mpfr, mpc, gmp и прочии isl, которые никакой общий код с gcc не разделяют.

bbk123 ★★★★★
() автор топика
Ответ на: комментарий от EXL

Тогда ты будешь сам себе злобный Буратино. Возьми самое новое ядро Linux и самый старый gcc, а теперь скомпилируй певое вторым. Вот так же и твой пример.

bbk123 ★★★★★
() автор топика
Ответ на: комментарий от baka-kun

Насколько я понял ТС, тарболы создаются из слитого из git кода. То есть с заведомо поломанным временем файлов.

Тогда почему не работает только у ТС?

kirk_johnson ★☆
()
Последнее исправление: kirk_johnson (всего исправлений: 1)
Ответ на: комментарий от EXL

Кстати, glibc combined tree не поддерживает, хотя он точно GNU-тый и тоже libc.

bbk123 ★★★★★
() автор топика
Ответ на: комментарий от kirk_johnson

Тогда почему не работает только у ТС?

Кто сказал? Я тоже вижу, что в архиве newlib файл предыдущей ревизии имеет слишком свежую дату модификации.

baka-kun ★★★★★
()
Ответ на: комментарий от kirk_johnson

Почему только? У тебя работает? Собери мне gcc-7.2.0+binutils-2.29.1+newlib-2.5.0.20170922 из combined tree стандартными средствами.

bbk123 ★★★★★
() автор топика
Ответ на: комментарий от bbk123

Таг. Я вот сейчас сделал так:

$ git clone https://github.com/mirror/newlib-cygwin
$ cd newlib-cygwin/
$ git archive --prefix=newlib-2.5.0/ -o newlib-2.5.0.tar.gz newlib-2_5_0
$ tar -tvzf newlib-2.5.0.tar.gz | grep include/dwarf2.h
-rw-rw-r-- root/root     12232 2016-12-23 09:33 newlib-2.5.0/include/dwarf2.h

Более того:

$ git archive --prefix=newlib-2_3_0/ -o newlib-2_3_0.tar.gz newlib-2_3_0
$ tar -tvzf newlib-2_3_0.tar.gz | grep "include/dwarf2.h"
-rw-rw-r-- root/root     12230 2015-12-22 08:32 newlib-2_3_0/include/dwarf2.h

Дата файла в tarball-е меняется. Скорее всего это не дата последнего изменения файла, а дата установки тега. Но оно работает.

Видимо разработчики RedHat каким-то особенным образом делали эти TarBall'ы.

EXL ★★★★★
()
Ответ на: комментарий от EXL

Ох, бл*джд, да там у них форменная наркомания.

2.5.0 и 2.5.0.20170922 это вообще разные версии. В репозитории ~280 веток и 650 (!) тегов, в которых номера версий вида:

newlib-1_14_0
newlib-1_15_0
newlib-1_16_0
newlib-1_17_0
newlib-1_18_0
newlib-1_19_0
newlib-1_20_0
newlib-1_9_0
newlib-2000-02-17
newlib-2_0_0
newlib-2_1_0
newlib-2_2_0
newlib-2_3_0
newlib-2_4_0
newlib-2_5_0

Смешаны с какими-то непонятными Snapshot'ами вида:

newlib-snapshot-20150323
newlib-snapshot-20150423
newlib-snapshot-20150526
newlib-snapshot-20150623
newlib-snapshot-20150723
newlib-snapshot-20150824
newlib-snapshot-20150924
newlib-snapshot-20151023
newlib-snapshot-20160104
newlib-snapshot-20160226
newlib-snapshot-20160527
newlib-snapshot-20160923
newlib-snapshot-20170228
newlib-snapshot-20170323
newlib-snapshot-20170421
newlib-snapshot-20170519
newlib-snapshot-20170623
newlib-snapshot-20170720
newlib-snapshot-20170818
newlib-snapshot-20170922

Как тут понять, какой версии какой снэпшот принадлежит?! Как разрабы вообще выставляют тут версии: ftp://sourceware.org/pub/newlib/ по Git'у?

Какой ужас и бардак.

И вы ещё хотите, чтобы они кропотливо и придирчиво следовали Combined Tree? Бгг.

EXL ★★★★★
()
Последнее исправление: EXL (всего исправлений: 1)
Ответ на: комментарий от Iron_Bug

автотулзы как раз предлагают максимально унифицированный сборочный тулкит. он даже умеет работать со всякими пакетными менеджерами. а это тот ещё зоопарк. так что у него очень много плюсов. и при этом он собирается нормальными средствами, теми же, которыми собирают ядро, без всякого выпендрёжа и сотен мегабайт ненужно, тянущегося в довесок к скриптоязыкам для школоты. это просто работает.

А почему Дженту вынуждено поддерживать 12 несовместимых версий автотулзхов?

question4 ★★★★★
()
Ответ на: комментарий от kirk_johnson

Combined tree - не единственно возможный способ сборки. Можно собирать и раздельно. Более того в большинстве дистрибутивов даже gcc разделён на несколько пакетов. Тем не менее combined tree всё ещё официально поддерживается и имеет свои преимущества.

bbk123 ★★★★★
() автор топика
Ответ на: комментарий от kirk_johnson

В том, что непонятно, каким снепшотам и какой дате, какая версия библиотеки соответствует.

EXL ★★★★★
()
Ответ на: комментарий от tailgunner

Некоторые считают хеш-суммы, некоторые следят за изменениями.

Как можно следить за изменениями, не используя ни время правки, ни хеши? Сделать собственные копии? Это ещё дольше хешей. Держать запущенным демона, который отслеживает все операции записи?

question4 ★★★★★
()
Ответ на: комментарий от EXL

gcc сразу собирается тем же binutils которые есть в combined tree и с тем же libc (newlib). gcc поддерживает трёхпроходную bootstrap сборку самого себя, а combined tree позволяет интегрироваться в существующий bootstrap не изобретая своего. Ну и иногда проще запустить один configure && make && make install чем несколько.

bbk123 ★★★★★
() автор топика
Ответ на: комментарий от question4

Держать запущенным демона, который отслеживает все операции записи?

У Gradle есть watch-плагин, который может мониторить изменившиеся файлы и демон, который сильно сокращает время сборки.

https://docs.gradle.org/current/userguide/gradle_daemon.html#sec:how_does_the...

EXL ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.