LINUX.ORG.RU
ФорумTalks

git is really stupid and made by stupid

 


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

★★★★★

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

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

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

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

Ты так и не сказал, на какую DVCS нужно было переходить вместо Git :)

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

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

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

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

А сейчас самый цимес: это client-side расширения :) То есть каждый чувак, который хочет работать с твоим репозиторием, должен их использовать.

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

Необязательно. pull request и дальше mtime выставляется по времени его принятия.

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

Необязательно. pull request и дальше mtime выставляется по времени его принятия.

Шикарно. А что делать с форкнутыми репозиториями? Не забывай, это DVCS.

P.S. Алсо я шото не помню, чтобы ты мог менять содержимое коммита во время его мержа в другой репозиторий.

P.P.S. Алсо получается, что после pull request'а коммит, который послали, будет отличаться от коммита, который приняли (потому что в том же HG файлик с mtime'амами хранится прямо в репозитории).

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

Это работает благодаря тому, что оба проекта используют единую базу инфраструктурного кода gcc и периодически синхронизируются между собой

Ты делаешь безумное криворукое уродство, поскольку мешаешь в одной директории никак не связанный код («периодически» твоим можно подтереться, никто тебе ничего не обещает и работать оно не обязано), отсюда и твои проблемы.

Потому что git не умеет сохранять даты модификаций файлов

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

и я далеко не первый, кто назвал его решение глупым

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

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

Ты делаешь безумное криворукое уродство, поскольку мешаешь в одной директории никак не связанный код («периодически» твоим можно подтереться, никто тебе ничего не обещает и работать оно не обязано), отсюда и твои проблемы.

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

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

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

Не я и он таки связанный.

Иначе, например, у меня есть...

А ты тут причём? Речь шла о создании тарболов, а не о твоих играх с твоими же репозиториями. Должна быть возможность выбора и конфигурации поведения VCS под нужды пользователя, а не жёсткая привязка к мировозрению Бенедикта.

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

А ты тут причём? Речь шла о создании тарболов, а не о твоих играх с твоими же репозиториями. Должна быть возможность выбора и конфигурации поведения VCS под нужды пользователя, а не жёсткая привязка к мировозрению Бенедикта.

Давай уже, напиши свою DVCS, с mtime'ом и анархией.

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

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

И эти люди имеют что-то против combined tree.

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

Давай уже, иди троллить в другом месте.

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

по-моему скромному мнению, разницы между Git и Mercurial в day-to-day development особо нет.

Если придерживаться общего подмножества... то всё равно нет. Даже короткие номера ревизий в Mercurial - уже заметная разница. mq - еще большая, evolve - еще. А еще вещи типа revsets, filesets.

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

Если придерживаться общего подмножества... то всё равно нет. Даже короткие номера ревизий в Mercurial - уже заметная разница.

Честно говоря, не заметил особой разницы. Хотя дело может быть в автокомплите :)

mq - еще большая

MqExtension? А разве он не deprecated?

evolve - еще. А еще вещи типа revsets, filesets.

Вот этим не пользовался.

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

Давай уже, иди троллить в другом месте.

Мне и правда любопытно. Ты столько говоришь о том, что дескать дело в Git нужно было бы взять другой DVCS. Так какой?

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

Честно говоря, не заметил особой разницы. Хотя дело может быть в автокомплите :)

У меня в глазах автокомлита нет.

MqExtension? А разве он не deprecated?

ХЗ. А какая разница? Оно есть и работает. Лучший инструмент для работы, которую делаешь в одиночку.

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

У меня в глазах автокомлита нет.

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

ХЗ. А какая разница? Оно есть и работает. Лучший инструмент для работы, которую делаешь в одиночку.

У них даже на сайте написано:

But if you are learning Mercurial, instead use modern tools, such as hg rebase, hg histedit, hg graft, hg strip, hg strip --keep, and hg commit --amend. Check the documentation for each of these commands.

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

этот пост был шуткой - нормальные люди не пишут вот таких строк на перле, нужно все это писать на Питоне

кроме вот этого про кусок истории

это было в 2010 году, заказчик был специфический, и запрещал изменять состав файлов. И еще он использовал Perforce и SVN. Поэтому я наладил переходник git-svn, и сразу же после синхронизации, уже в локальном гите совершал пачку действий: раздербанивал мегафайлы на маленькие файлы, добавлял правильный .gitignore, исправлял несколько эпических багов (исправлять которые было запрещено). Перед финальным пушем запускался скрипт, который делал все задом наперед, плюс сквошил коммиты (отдельно - UI, отдельно - логику в выделенные мегакоммиты), приписывал коммитам в комментарии мусор (в них надо было писать номер тикета в багтрекере и фамилию-имя), и так далее

если бы этого не делать, а пользоваться SVN как сказали, то на бюрократию могло уйти полдня

потом они ушли с SVN на Mercurial, и там были совершенно другие мозговыносящие проблемы: например, меркуриал на винде не мог обработать длинные пути файлов, несмотря даже на пропатченный NTFS. Mercurial тоже приходилось пердолить прессом скриптов, но их хотя бы можно было уже оформлять как плагины

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

не занимался разбором коммитов по хешам.

С git это не получится даже при желании.

But if you are learning Mercurial, instead use modern tools, such as hg rebase, hg histedit, hg graft, hg strip, hg strip --keep, and hg commit --amend. Check the documentation for each of these commands.

Насколько я вижу, это попытка свести Mercurial к общему подмножеству с git и тем самым понравиться поколению гитхаб-«программистов».

В любом случае, я уж точно не «learning Mercurial».

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

С git это не получится даже при желании.

Можешь привести пример?

Насколько я вижу, это попытка свести Mercurial к общему подмножеству с git и тем самым понравиться поколению гитхаб-«программистов».

Собственно, мне интересно, какие ситуации в HG можно решить значительно проще, чем в Git.

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

Можешь привести пример?

Пример чего - что номера ревизий 1234 и 1236 удобнее, чем fd90ae458 и ae90ee432?

Собственно, мне интересно, какие ситуации в HG можно решить значительно проще, чем в Git.

Для этого нужен кто-то, кто хорошо (не одинаково хорошо, а хорошо) знает Mercurial и git. Лично я вообще не знаю аналогов revsets и evolve в git, а аналог mq - это сторонний инструмент (даже не знаю, поддерживается ли он сейчас).

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

Пример чего - что номера ревизий 1234 и 1236 удобнее, чем fd90ae458 и ae90ee432?

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

Для этого нужен кто-то, кто хорошо (не одинаково хорошо, а хорошо) знает Mercurial и git. Лично я вообще не знаю аналогов revsets и evolve в git, а аналог mq - это сторонний инструмент (даже не знаю, поддерживается ли он сейчас).

Ну тут вопрос, какие задачи evolve и revsets решают.

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

Пример чего - что номера ревизий 1234 и 1236 удобнее, чем fd90ae458 и ae90ee432?

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

А мне оно говорят в бесконечность раз больше, чем два хеша.

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

Долго думал - так и не понял, какое это отношение имеет к методу назначения номеров ревизий в SVN.

Ну тут вопрос, какие задачи evolve и revsets решают.

Ну, у меня такого вопроса нет. Есть вопрос, как эти задачи решают в git.

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

Долго думал - так и не понял, какое это отношение имеет к методу назначения номеров ревизий в SVN.

Ну там тоже последовательный рост и маленькие цифры ревизий.

А у меня вопрос, как эти зачдачи решают в git.

Ну давай список задач, что-ли.

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

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

Долго думал - так и не понял, какое это отношение имеет к методу назначения номеров ревизий в SVN.

Ну там тоже последовательный рост

Во-первых, не «тоже» - там другой принцип назначения номеров; во-вторых, какое это отношение имеет к тому, что ты по двадцать раз проверял?

А у меня вопрос, как эти зачдачи решают в git.

Ну давай список задач, что-ли.

Совместная работа над одними и теми же ченджсетами и язык запросов ревизий: https://www.mercurial-scm.org/doc/evolution/ https://www.mercurial-scm.org/repo/hg/help/revsets

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

Во-первых, не «тоже» - там другой принцип назначения номеров; во-вторых, какое это отношение имеет к тому, что ты по двадцать раз проверял?

Ну, есть у тебя две циферки. Кроме того, что одна ревизия старше другой, они тебе ничего не говорят. Даже если одна сильно больше другой, все равно непонятно, что там в коде-то поменялось.

Совместная работа над одними и теми же ченджсетами и язык запросов ревизий: https://www.mercurial-scm.org/doc/evolution/ https://www.mercurial-scm.org/repo/hg/help/revsets

Ладно, я пожалуй не буду в эту тему сейчас лезть. Там шото много всего.

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

Ну, есть у тебя две циферки. Кроме того, что одна ревизия старше другой, они тебе ничего не говорят

А это уже довольно много, особенно по сравнению с git, где они совсем ничего не говорят. И по сравнению с SVN, где 2 почти одинаковые цифры могут относиться к вообще разным проектам.

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

А это уже довольно много, особенно по сравнению с git, где они совсем ничего не говорят. И по сравнению с SVN, где 2 почти одинаковые цифры могут относиться к вообще разным проектам.

Ну, это для наркоманов, которые один репозиторий для всех проектов заводят.

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

Когда в одном репе один проект, там тоже всё плохо - никакой локальности.

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

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

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

2 почти одинаковые цифры

даже комментировать не нужно.

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

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

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

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

С их точки зрения разные версии autotools — такой же зоопарк. Если пакет собирается какой-то версией, нет гарантии, что более новые или старые мажорные версии соберут правильно. Сейчас официально поддерживаются 1.9-1.15, а 1.4-1.8 замаскированы, но их ещё можно ставить.

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

Главный недостаток питона в системе сборки — есть шанс её убить, обновив питон :)

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

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

Самая писечка в том, что автолулзы зависят от перла.

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

автолулзы зависят от перла

Perl vs Python. Let's the fight begin! %)

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

Perl vs Python. Let's the fight begin! %)

Обычно это fight поколений. Старая гвардия предпочитает Perl, потому что он был популярен во времена их молодости. Нынешняя молодёжь предпочитает Python.

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

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

Всем и каждому по cmake?

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

hg clone — даты потеряны
hg archive — даты потеряны
hg checkout — даты потеряны

Остаёмся на SVN?

Как на SVN сделать, чтобы даты сохранялись при клонировании и чекауте? У меня по умолчанию ставит дату чекаута.

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

svn export сохраняет даты. К сожалению это не совсем то, что ты ищешь.

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

Без понятия, пользовался svn последний раз лет 6 назад. Даже cvs чаще встречаю, такие дела.

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