А язык запросов в Git есть?

Пока хватало git filter-branch, но не скажу что это был приятный опыт.

Ты же не имел в виду под «подробностями реализации» исходники гита? Верно?

Подробности архитектуры звучит лучше?

миллионы пользователей гитхаба прекрасно справляются

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

Просто rsync для дистрибуции портов совсем никак не подходит, обязательно нужно vcs использовать?

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

При этом «минимальном использовании», доступном миллионам, уже проявляются какие-либо преимущества DCVS?

«Форкни меня» и Pull request самые модные фишки уходящего сезона. Ты чувак вообще не в теме))

Продолжаем веселиться:

Alexandr Kovalenko ( о закапывании неофициальных зеркал репов):

http://docs.freebsd.org/cgi/getmsg.cgi?fetch=88009 0 current/freebsd-ports

Erich Dollansky о том-же: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=155631 0 current/freebsd-ports

Steven Hartland о том-же:

http://docs.freebsd.org/cgi/getmsg.cgi?fetch=160545 0 current/freebsd-ports

Процитирую второго автора:

this all sounds like a inside job to kill FreeBSD.

I just wrote the other message saying that it seems to me that the huge user base outside the USA is ignored.

What will happen to the project when all non-US servers cannot be used anymore?

Как-то много лет пользовались CVS и не напрягались ваще. А тут вдруг «ущербным» стал.

Как-то много лет пользовались CVS и не напрягались ваще. А тут вдруг «ущербным» стал.

Разработка в FreeBSD уже давненько идет на svn. Просто экспортировать в CVS больше не будут.

Вкуснее — это git и mercurial.

Git на огромных блобах помирает частенько.

dvcs для хранения блобов не предназначены. Есть конечно костыли типа largefile в hg, но всё равно, лучше svn никто с блобами не работает :)

+1, я про тоже. Один раз сам столкнулся и много раз читал (и на ЛОРе тоже) как вываливается git после коммита файла в районе 4 Гб.

> А язык запросов в Git есть?

Пока хватало git filter-branch, но не скажу что это был приятный опыт.

По-моему он спрашивал про man gitrevisions.

По-моему он спрашивал про man gitrevisions.

Стоит признать, по сравнению с hg они вообще не о чем.

Во-первых, объясни как «новый принцип работы» dvcs поможет разработчикам портов

Никак, для них svn по-видимому оптимален. Хотя сами порты можно разрабатывать черз git-svn, а потом коммитить результат.

Во-вторых, объясни чем инопланетный гит лучше человеческого меркуриала, который построен на том же новом принципе работы

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

Времена меняются

То есть нормальный пользовательский интерфейс для тебя это плохо?

Меркуриал - это тот же свн по идеологии

Гыгы. И эти люди еще что-то говорят о «принципах работы VCS».

Вывод.

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

Не надо ерничать, я думаю понятно, что я имел в виду.

Что значит «нормальный»? У гита нормальный интерфейс, и намного более эффективный. Если, кончено, не цепляться зубами за концепции свн

В чем эффективный и в чем состоят концепции svn?

Меркуриал - это тот же свн по идеологии

Гыгы. И эти люди еще что-то говорят о «принципах работы VCS».

Не надо ерничать

Над этим - надо.

я думаю понятно, что я имел в виду.

Да, вполне:

annulen> так прет свнщиной, что я так и не смог его полюбить.

тебе нужно было что-то, что не напоминало бы тебе о SVN.

/me чудовищным усилием воли сдерживается от вопроса в стиле «вас в детстве SVNщики унижали?».

А вывод из этой истории простой. Хотите писать долго - пишите на C

fixed

Наиболее важные, на мой взгляд, концепции git:

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

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

вас в детстве SVNщики унижали?

нет, просто осталось много плохих воспоминаний о воркфлоу с свн. Когда наша компания перешла на гит, большинство проблем испарилось

в hg для всего этого придется поставить

4.2

Ололо, даже букмарк не включен по умолчанию

К какому из твоих пунктов относится букмарк?

в hg для всего этого придется поставить тучу плагинов

Тебе придется включить в .hgrc rebase и mq, но ставить ничего не нужно (и mq удобнее, чем stash).

и все равно отсанется осадок, что разработчики этого не планировали и жди подвоха

Это у тебя отходняк после git.

и mq удобнее, чем stash

ога, и stash появился в git'е спустя годы (!) после mq

mq и stash - это разные вещи. В git я беру локальную ветку и сквошу серию последовательных связанных коммитов в один, безо всяких лишних сущностей типа mq.

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

В git я беру локальную ветку и сквошу серию последовательных связанных коммитов в один, безо всяких лишних сущностей типа mq.

И чем это отличается от аналогичной операции в mq кроме дополнительного телодвижения по включению mq, которое делается один раз ?

В git я беру локальную ветку и сквошу серию последовательных связанных коммитов в один

Ох лол. Если это всё, что тебе нужно, в Mercurial это делается вообще без плагинов.

безо всяких лишних сущностей типа mq.

mq умеет объединять коммиты, но предназначен он для поддержки обычной повседневной работы (со стеком патчей, да).

что же вы безграмотные все, кто вам сказал что stash как-то соотносится с mq

Это единственное, что в стандартном Git напоминает mq.

Если это всё, что тебе нужно

Не все. Еще нужно разделять и переставлять коммиты.

в Mercurial это делается вообще без плагинов.

как?

Обычный гитовый бранч - это и есть твой mq

и кто-то после этого смеет говорить о безграмотности ?

в Mercurial это делается вообще без плагинов.

как?

hg co bottomcommit; hg revert -r topcommit .; hg ci -m"Сквошнул коммиты"

Обычный гитовый бранч - это и есть твой mq

Приведешь аналог последовательности «hg qpop -a; hg qpush» (снимает все патчи, кроме первого)?

Это только для верхних коммитов, насколько я понимаю. В git rebase -i возможностей куда больше

нет, в истории всё сохранится

git rebase -i (открывается редактор, в котором ты стираешь ненужные патчи)

нет, в истории всё сохранится

Естественно. И появится новая голова, состоящая из «сквошенных коммитов».

Это только для верхних коммитов, насколько я понимаю

Это для любых.

git rebase -i (открывается редактор, в котором ты стираешь ненужные патчи)

Кхм. Я не хочу их стирать, я хочу их _временно_ снять, а потом наложить на обновленный первый патч.

ok, а как потом назад накатить?

ЕМНИП portsnap каждый раз качает всё дерево, а не только изменения.

Всё-таки с прискорбием вынужден тебе сообщить, можешь подавать на развод. Память уже очень давно не твоя.

Всё дерево качается только в первый раз (причем, текущее). Далее только патчсеты.

А вывод из этой истории простой. Хотите писать долго - пишите на C

fixed

Долгота написания важна для программ однодневок и их авторов.

Для пользователя на это вообще положить ....

А вот время поддержки - то на что заточен бизнес.

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

Сделай первый патч последним, отредактируй (e), и git rebase --continue

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