Вышел GNU Mach 1.4

Истории чего?

Да блин куда уж тоньше-то? Это типа нормально когда каждый файл закоммиченный как в CVS'е хранится в отдельном файле хранилища?

Я не возражаю против того что он для повседневной работы. Просто зачастую эту же работу удобнее делать через rebase -i, а не через mq.

А что я такого в гите не знаю о хранилище?

Истории.

Истории чего?

Хм. Вроде же очевидно, что ты не знаешь истории о хранилище Git, не? О том, как дико оно тормозило в начале, о том, как это наконец поправили теми самыми паками. Емнип, в Git без паков каждый измененный файл хранится отдельно (т.е. даже без дельта-компрессии), а за отображение SHA1 -> данные отвечает файловая система.

Это типа нормально когда каждый файл закоммиченный как в CVS'е хранится в отдельном файле хранилища?

Да. И по тестам скорости (не твоим личным, конечно), Mercurial иногда обгонял Git, в основном отставал, но никогда не отставал намного.

зачастую эту же работу удобнее делать через rebase -i

Т.е. когда у тебя есть стек патчей, и тебе необходимо поправить патч где-то в середине, ты делаешь rebase -i? У любителей Git реально странные представления об удобстве.

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

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

Ну а нафига мне делать кучу команд qpop и т.п., когда я могу сразу поправить прямо поверху, потестить всё вместе, закоммитить изменение, а потом rebase -i + выбор squash/fixup мне эти изменения засадит в нужный патч? Так и делаю, ага :)

Зато git жутко распиарен.

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

QNX, не?

А что вы выбрали, скорость работы или безопасность? Они молодцы. Позволяют выбрать. Вот, правда, сразу и то и то ну никак не получиться.

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

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

Ну блин, так это когда было-то?

Ну ты же вспоминаешь времена, когда в Mercurial не было rebase.

Ну а нафига мне делать кучу команд qpop

Кучу? Ровно один. Ты реально не знаешь ни зачем нужен mq, ни как им пользоваться.

когда я могу сразу поправить прямо поверху, потестить всё вместе, закоммитить изменение, а потом rebase -i + выбор squash/fixup

squash - это схлопнуть коммиты в один? Походу, ты так и не понял.

потом rebase -i + выбор squash/fixup мне эти изменения засадит в нужный патч? Так и делаю, ага :)

Ожидаемый ответ.

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

Что за фича?

Человеческий эквивалент 'git ls-files -v | grep «^[a-z] »'

Человеческий эквивалент 'git ls-files -v | grep «^[a-z] »'

revsets и filesets давно сделаны :)

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

Из чего я делаю вывод, что эта фича не так и важна.

Что за фича?

Вышел GNU Mach 1.4 (комментарий)

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

Из чего я делаю вывод, что эта фича не так и важна.

...разработчикам git. Неужели трудно понять, что Git - это система, сделанная для Линуса? А Линусу нужен просто навороченный транспорт патчей.

Что за фича?

Вышел GNU Mach 1.4 (комментарий)

Как обычно, бесполезный ответ.

revsets и filesets давно сделаны :)

Конкретно, какую команду запускать?

Конкретно, какую команду запускать?

hg log или hg st :)

Я про git спросил.

После 11 лет интенсивного кодирования

Ощущение, будто следующая фраза будет про написание «Войны и мира»... :)

...разработчикам git. Неужели трудно понять, что Git - это система, сделанная для Линуса? А Линусу нужен просто навороченный транспорт патчей.

Так это проблема?

Неужели трудно понять, что Git - это система, сделанная для Линуса? А Линусу нужен просто навороченный транспорт патчей.

Так это проблема?

Для тех, кто себя под Линуса чистит - нет.

Как обычно, бесполезный ответ.

Вы спросили о фиче (видимо самому пробежаться по линкам для вас проблема), я указал на сообщение об этой фиче. Для вас это бесполезный ответ? Ну ок.

Вы спросили о фиче

Да, мы спросили о фиче. Не об URL поста, на который ты отвечал.

Для тех, кто себя под Линуса чистит - нет.

А ведь раньше вы были адекватны. На наркоту подсели?

Да, мы спросили о фиче. Не об URL поста, на который ты отвечал.

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

А ведь раньше вы были адекватны

Если сейчас неадекватен - и раньше не был.

Если сейчас неадекватен - и раньше не был.

Ясно, раньше вы просто лучше маскировались.

От indent style зависит. То что вы предлагаете подходит для k&r но если код пишется в стиле allman (это как в моем примере), то лишние скобки будут ухудшать читаемость. Все это ИМХО конечно.

Я вспоминаю когда не было rebase -i! А не просто rebase. И это было недавно. В отличие от отсутствия паков.

Блин, вот ведь лор-стиль комментов. «Походу ты так и не понял» - ну расскажи мне, раз я такой тупой :)

Речь было о распиаренности. Намёк на то, что раз git всего лишь распиарен - распиарьте и hg. Вон, bzr тоже санонисал использует, а толку с этого нет - по популярности даже меньше hg.

это было недавно. В отличие от отсутствия паков.

Зависит от перспективы. Для меня и отсуствие паков в git было недавно.

«Походу ты так и не понял» - ну расскажи мне, раз я такой тупой :)

Когда ты находишь ошибку в середине стека патчей, ты должен ее исправить _там же_ (надеюсь, не нужно объяснять, почему). После чего проверить исправление, прогнать тесты. А потом сделать то же с патчами, которые выше исправления, потому что исправление могла сломать что-то. Как ты всё это сделаешь из rebase -i - я искренне не понимаю. Скорее всего, ты этого просто делать не будешь, а схлопнешь все изменения в один патч и напишешь в комменте «инкрементальные изменения? Не, не слышал».

распиарьте и hg

Ну что за деццтво... пиаром git было «его изобрел Линус» - кто-то как-то должен заставить Линуса изобрести hg?

Как это все? Не все схлопну, а только те, которые к патчу относятся. Я лично фикшу поверх (попутно проверяя работоспособность в целом), потом пересаживаю в середину, потом проверяю в середине, потом проверяю суммарно...

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

Я лично фикшу поверх (попутно проверяя работоспособность в целом), потом пересаживаю в середину, потом проверяю в середине

потом пересаживаю в середину

O_o

потом проверяю в середине, потом проверяю суммарно...

И каким образом ты это делаешь? Из rebase -i?

Мне кажется если бы пиаром гита был только Тролльвардс

Думаю, github тоже сыграл свою роль.

А шо github? bitbucket появился примерно в то же время.

Да простым, checkout на нужный коммит, потом обратно.

Пересаживаю в середину - в смысле из нового коммита и старого коммита делаю один путём squash

checkout на нужный коммит, потом обратно.

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

А шо github? bitbucket появился примерно в то же время.

github, особенно раньше, заметно так выигрывал по функционалу у bitbucket

чтобы else после макроса вызвал compilation error

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

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

Это означает rebase верхних патчей. И так каждый раз, когда правишь патч в середине стека.

Так а как к этому принципиально по-другому подойти (в hg видимо)?

Так а как к этому принципиально по-другому подойти

Стек патчей - mq для Mercurial, stg и guilt для Git. Правда, в принципиальной «другости» я не уверен.

(в hg видимо)?

AFAIK, это впервые реализовано в quilt, до Mercurial и Git.

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

так и не понял

Предположим, у нас есть граф patch1 -> patch2 -> patch3 -> patch4 Приведи аналогичную последовательность команд git:

hg qpop patch2
vi file1.c
make tests # успешно
hg qref
hg qpush patch3
make tests # неуспешно
vi file2.c
make tests # успешно
hg qref
hg qpush patch4
make tests # успешно

Форма графа должна остаться той же.

поддержка некоторых PCMCIA устройств (основано на пакете pcmcia-cs).

2013 год шел.

Я не понимаю, почему всего лишь 4 странички обсуждений такой наболевшей темы, поднятой в данной новости??

Nobody cares

4 запасных аэродрома - хайку,хурд,реактор ,и бсд

Причем только последний действительно готов для продакшена

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

Зачем? Через git rebase -i можно править любой из нижних патчей

После 11 лет интенсивного кодирования

Ощущение, будто следующая фраза будет про запой

fixed

И в чем ошибка создателей Hurd на Ваш взгляд?

Через git rebase -i можно править любой из нижних патчей

Там вверху приведен список команд - изобрази это через git rebase.

да,так и есть.