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) её тоже не было. Линус решил, что он самый умный и вот результат. Ну чем не Поттеринг?

★★★★★

Ответ на: Всё сложно... от Deleted

Полагаю, что из даты последнего изменения содержимого файла. Если файл прошёл ребейс и его содержимое изменили, должен измениться и mtime. Если ребейс делали лишь для того, чтобы подправить commit message, mtime должен остаться прежним, потому что прежним же осталось и его содержимое. Тоесть mtime должен отражать то, ради чего он придуман - modification time, время изменения. Если моё изменение файла основано на старой версии и сделано после того, как в другом репозитории его изменил коллега, оба изменения встретятся во время мерджа, который так же приведёт к изменению файла, а значит и к изменению mtime. В каком месте здесь может возникнуть проблема с mtime?

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

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

вот что по-настоящему медленно - это действительно интерпретаторы. и я их не использую.

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

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

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

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

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

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

на каждом сервере часы свои и синхронизация разных серверов - это гиблое дело

Ты с кластеами никогда не работала? Там даже файловая система работать не будет если часы не синхронизированы.

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

Кластер управляется одни чуваком. Сотни девелоперов в разных странах не управляются ничем. На то Git и DVCS.

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

На сколько поехали? На день, на месяц или может быть на год, как в случае newlib? Разница в несколько минут непринципиальна. Синхронизация времени с большой точностью давно не является проблемой и во время dvcs push сервер всегда может сравнить своё текущее время с твоим и если надо обматерить.

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

Синхронизированные по ntp часы правильные. Если ты не заботишься о синхронизации времени в общем проекте, ты сам себе злобный буратино. И даже если ты буратино, разница в пару минут непринципиальна. Если же твои часы отстают или спешат на несколько часов (не из-за неправильной таймзоны, ибо сранение по UTC, а вообще) и тем более дней, месяцев или лет, то ты не просто буратино - ты наркоман.

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

В каком месте здесь может возникнуть проблема с mtime?

Ещё раз: откуда ты его собрался брать? Попробуй написать конкретный алгоритм псевдокодом.

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

на каждом сервере часы свои и синхронизация разных серверов - это гиблое дело

настроить ntp - гиблое дело?

это никогда не работало и не будет работать

да ну нафиг!

поэтому таймстемпы - это чисто абстрактная информация, которую нельзя учитывать, в частности, при апдейтах сорцов

только если «сорцы» от тех, у кого настроить ntp - это гиблое делло.

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

да ну нафиг! Бенедикт негодует по поводу такой практики
http://markmail.org/message/b45lyln5eig6tp4x

I'm sorry. If you don't see how it's WRONG to seta datestamp back to
something that will make a simple «make» *miscompile* your source tree, I
don't know what defintiion of «wrong» you are talking about.

It's WRONG.

It's STUPID.

And it's totally INFEASIBLE to implement.


Тоесть у Бенедикта проблемы не с timestamp в VCS, а с make и делать make clean он не желает принципиально.

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

Я уже всё расписал. В каком месте осталось непонятно? Ещё раз, совсем уж коротко - mtime берётся из времени последнего изменения связанного с данным коммитом. Если после author date файл не менялся, то mtime == author date. Если менялся, то mtime == дате последнего ребейса или любого другого действия над этим коммитом, приведшего к изменению содержимого файла.

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

Производительность из-за этих дат на больших репозиториях будет страдать, если всё это сохранять и таскать.

Этот newlib тот же довольно крупный и раздутый реп с 270+ ветками.

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

Для меня важна кроссплатформа. Мейк не кроссплатформа не разу. Шелл тоже. Поэтому я считаю их нужно закопать, учесть ошибки и написать заново. Но я этим заниматься не буду, я просто предложил что это было бы куда полезнее, чем переделывать графику в линуксах(что всё пытаются, но в итоге никак не могут).

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

Полностью согласен.

Combined tree это наркомания вообще.

Гораздо удобнее тут был бы хорошо сконфигурированный суперрепозиторий с со скриптами сборки необходимых конфигураций GCC.

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

но в сборки ядра и околосистемных вещей пистон не проникнет. потому что там люди с мозгами сидят.

В иксы уже проник. В Glib тоже.

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

shell на уровне POSIX - вполне себе кроссплатформа. gnu make можно собрать при помощи идущего с ним shell скрипта и тоже пользоваться где угодно. Тоесть опять же кроссплатформа.

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

Нет, не надо говорить за меня. Я уже несколько раз говорил о синхронизации времени.

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

например, веб уже заговнён чуть более, чем на 100%. и его уже не спасти. он так и будет тормозить, пока они не начнут бороться с пистоном.

Пистон недоуменно оглядывает лица жабки, пыха, пёрдла, раби и прочих дотнетов и вопрошает: «Как же так, братцы, почему я один за всех нас отдуваться должен?»
Ну и в браузере, наверное, у вас тоже пистон сидит.

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

Так их заставляют Git использовать? В Git вообще все очень по-своему. Регулярно появляются такие треды, и касаются они не только mtime, а например модели бранчей. Git сделан для одного вполне конкретного сценария использования. Почему бы не использовать Mercurial?

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

Так, вроде и запилили ninja как замену make

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

Ты не себе буратино, ты другим буратино. В этом проблема. Чуваки посчитали так же, и не стали вводить поддержку mtime. Ни авторы HG (о которых ты почему-то не упоминаешь), ни Линус (которого ты зачем-то называешь по второму имени).

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

Ну вот это, кстати, чушь. Шелл офигенно удобная штука, и тот факт, что вендузятнеги не шмогли, этого не меняет.

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

Ты собираешь под эмбеддед на самой железке? Держишь там все средства разработки, исходники?

а почему нет?

Потому что это глупо и обычно невозможно.

если я разрабатываю под эту железку софт - это просто необходимо

Какой бред.

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

Так их заставляют Git использовать?

Давно пришёл к выводу о том, что популярность git связана не столько с какими-то его техническими преимуществами, сколько просто с модой. Бенедикт гораздо более известная личность, нежели авторы Mercurial.

Git сделан для одного вполне конкретного сценария использования.

На сайте Atlassian рассказывают о нескольких разных workflows использования git.

Почему бы не использовать Mercurial?

Это вопрос не ко мне.

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

Как же ловко ты соскочил с темы. Больше аргументов не осталось?

А чем тебе не нравится аргумент? Любой упырь с кривым временем может сломать сборку всем остальным. Это не очень ок.

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

нежели авторы Mercurial

Я тебе ещё раз повторяю: в Mercurial этого тоже из коробки нет. Кто-то, как и ты, написал костыль, и выложил его. Ты тоже можешь написать такой-же для Git.

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

Я тебе ещё раз повторяю: в Mercurial этого тоже из коробки нет.

Ты совсем дурак? Мало того, что влез в чужой разговор, так ещё и не разобрался о чём мы там говорим. Там речь не о поддержке mtime, а лишь об использовании Mercurial вместо git.

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

Ты совсем дурак? Мало того, что влез в чужой разговор, так ещё и не разобрался о чём мы там говорим. Там речь не о поддержке mtime, а лишь об использовании Mercurial вместо git.

LOL. А в чем принципиальная разница между HG и Git, если combined tree ломается в любом случае?

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

А чем тебе не нравится аргумент? Любой упырь с кривым временем может сломать сборку всем остальным. Это не очень ок.

Есть ещё миллион других способов сломать сборку. Кривое время лечится с пол пинка и даже разница в пару минут некритична.

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

Есть ещё миллион других способов сломать сборку. Кривое время лечится с пол пинка и даже разница в пару минут некритична.

Авторы HG и Git считают, что проще устранить источник проблем раз и навсегда.

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

Не влезай в разговор других людей и не задавай глупых вопросов, не относящихся к чужому разговору.

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

Не влезай в разговор других людей и не задавай глупых вопросов, не относящихся к чужому разговору.

А то что?

К слову:

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

Твоя цитата :) Так что, будь ласка, не вводи читателей в заблуждение.

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

К слову это взято из другого разговора и я уже сказал, что меня ввели в заблуждение на stackoverflow. Зачем ты влез в мой разговор с stevejobs и начал троллить не относящимися к чужому разговору заявлениями?

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

На сайте Atlassian

При чем тут Атлассиан? Думаю, что нужно смотреть не сайт Atlassian, а ответы всего одного человека - Линуса Торвальдса. Как он сказал, так и есть, так и правильно. Ну и Хамано.

Кто такой Бенедикт, столь «известная личность»? Есть Линус (torvalds), Хамано (gitster), и все остальные. В «остальных» выделяется Кинг (peff), Пирс (spearce), Шинделин (dscho), Нгуен (pclouds), Хаггерти (mhagger), Наребский (jnareb), еще куча людей по мелочи... И ни одного из них Бенедикта!

Это вопрос не ко мне.

Если выбор контроля версий - это вопрос не к тебе, почему ругаешь систему контроля версий - ты?

Какие-то криворукие наговнокодили, ты за них публично впрягся. Теперь по впрягону на это стреле ты и везешь за них.

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

К слову это взято из другого разговора и я уже сказал, что меня ввели в заблуждение на stackoverflow.

Это «заявление» находится в цепочке разговора с stevejobs :)

Зачем ты влез в мой разговор с stevejobs и начал троллить не относящимися к чужому разговору заявлениями?

Потому что потом люди будут читать топик и думать, что HG написан наркоманами.

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

По сабжу, мне кажется, что Git лаконичный (не нужно как виндузятник писать --длинные-параметры), а Github - клёвый. И там можно на шару хранить любой говнокод. И еще там есть Мастер, и не нужно думать лишних вещей по поводу сложной политики бранчевания. Вот и весь секрет успеха. Уверен, что большинство виндузятников, которые используют Git, даже не задумывалось о несчастном святом Бенедикте. Вон сейчас все Microsoft-поклонники сидят на гите, думаешь они вообще хоть что-то в GNU/Linux шарят, кроме того, что это устаревшая ОС, в которой нужно пердолиться с консолью и не работает графика?

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

По сабжу, мне кажется, что Git лаконичный (не нужно как виндузятник писать --длинные-параметры), а Github - клёвый. И там можно на шару хранить любой говнокод. И еще там есть Мастер, и не нужно думать лишних вещей по поводу сложной политики бранчевания. Вот и весь секрет успеха. Уверен, что большинство виндузятников, которые используют Git, даже не задумывалось о несчастном святом Бенедикте. Вон сейчас все Microsoft-поклонники сидят на гите, думаешь они вообще хоть что-то в GNU/Linux шарят, кроме того, что это устаревшая ОС, в которой нужно пердолиться с консолью и не работает графика?

Честно говоря, Mercurial точно такой же. Мб Git действительно взяли потому, что у него Линус в авторах, но, по-моему скромному мнению, разницы между Git и Mercurial в day-to-day development особо нет.

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

Мне нравится, что на в интернете есть куча полезных магических команд для Git.

То есть допустим, если ты хочешь сделать вид перед заказчиком, что над проектом работал не 1 человек, а 6, и делали они это не 1 вечер, а трудились две недели - где-то на StackOverflow есть команды для этого.

Очень полезно историю всегда фильтровать, выбрасывать из нее ненужное и добавлять нужное, и так далее. Например, у меня есть кусок истории в далеком прошлом, который «лично мой» - ни у кого больше его нет - он накатывается каждый раз при заливке кода и удаляется при пуше.

К примеру, вот так можно черри-пикнуть кусок истории в отдельный бранч «myshit»:

git rev-list --reverse --topo-order master... | while read rev; do git checkout myshit; git cherry-pick $rev || break; done

Удобно.

Ну и еще куча разного. У меня прямо стойкое ощущение, что синтаксис Git вот такой не просто так, а чтобы можно было удобно ковыряться, мешать гитовые команды с GNU-шными утилититами

Например, вот так в одну строчку делаются локальные трекинг-бранчи для всех удаленных бранчей:

git branch -a | grep -v HEAD | perl -ne 'chomp($_); s|^\*?\s*||; if (m|(.+)/(.+)| && not $d{$2}) {print qq(git branch --track $2 $1/$2\n)} else {$d{$_}=1}' | csh -xfs;

А вот так посмотреть результаты (какой бранч что трекает):

git for-each-ref --format='%(refname:short)' refs/heads/* | while read b; do if r=$(git config --get branch.$b.remote); then m=$(git config --get branch.$b.merge); echo "$b -> $r/${m##*/}"; fi; done

Слабо привести примеры аналогичных однострочников для Mercurial?

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

Это «заявление» находится в цепочке разговора с stevejobs :)

То, что меня ввели в заблуждение на stackoverflow находится тут же.

Потому что потом люди будут читать топик и думать, что HG написан наркоманами.

Нет, потому что ты тролль и не упускаешь возможность потроллить. Предметный разговор у тебя уже давно закончился. Пойди лучше мануал ntp почитай.

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

То, что меня ввели в заблуждение на stackoverflow находится тут же.

Это я к тому, что разговор якобы не касается mtime :)

Нет, потому что ты тролль и не упускаешь возможность потроллить. Предметный разговор у тебя уже давно закончился. Пойди лучше мануал ntp почитай.

Нет.

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

Как он сказал, так и есть, так и правильно.

А он сказал, что лишь один workflow правильный или ты за него додумал?

Кто такой Бенедикт, столь «известная личность»?

Второе имя Линуса.

Если выбор контроля версий - это вопрос не к тебе, почему ругаешь систему контроля версий - ты?

Потому что считаю её ограничения неправильными. Никто не мешает сохранять mtime всегда и востанавливать его в зависимости от конфигурации. Кому надо включат, кому не надо выключат.

Какие-то криворукие наговнокодили, ты за них публично впрягся.

Их криворукость - вопрос спорный. Что бесспорно, так это то, что combined tree сломался именно из-за git. До перехода на git этого не было.

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