BitKeeper освободился

Так это если есть branch. Иногда я хочу конкретный коммит (до момента, как всё поломалось).

Делается так:

git clone git://gitorious.org/project_name/software_name.git // скачиваем последний GIT
git checkout commit_sha // откатываемся назад

скачиваем последний GIT

Медицина, похоже, бессильна.

Но всё же: в --branch можно указать тэг. И, думаю, SHA1 тоже

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

Все, иду ставить. Даже удаление трекают, подумать только!

И, думаю, SHA1 тоже

А вы попробуйте. Именно с хэшем коммита, т.к. --branch понимает имена веток и имена тегов, но не коммиты.

а при чём здесь винда, лошара?

Повторюсь: там есть ссылки на репозитории. Все желающие могут взять и посравнивать самостоятельно.

Я и прошу сделать такой тест того, кто уверен в бенчах bk.

Только вместо этого флейм о том, «могут или не могут разработчики git-а быть профнепригодными».

И кто этот флейм поддерживает? :)

Откуда взялось «значительно удобнее»?

Вот отсюда:

мне лично (повторюсь: лично мне), проще запомнить, как работать с hg, чем с git-ом

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

Вот и возникает вопрос: а нахрен это все, если мне нужны совершенно обыденные вещи, а не весь комплект навороченной функциональности git-а?

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

а при чём здесь винда, лошара?

А при чем тут тетрис, энтерпрайз-девелопер?

В hg заметно проще следующее, например:

* rebase; * показать файл из конкретного коммита; * посмотреть разницу с репкой на сервере.

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

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

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

Это странная постановка вопроса. Серьезно странная. Поясню.

У меня было несколько подходов к изучению git-а. Каждый раз после штудирования литературы (вроде Pro Git) оставалось ощущение того, что ничего не понимаю. Зазубриваются некоторые команды, но понимания нет. Когда приходится работать с git-ом достается шпаргалка и нужные операции выполняются по ней. Когда не приходится пользоваться git-ом, минимальные знания опять улетучиваются.

В то же время для hg достаточно было прочитать небольшую брошюрку с введением в hg и все. Шпаргалка, время от времени, требуется, но не постоянно.

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

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

Замечательный вопрос. Для себя я могу пользоваться чем угодно. Но если выкладываешь что-то в публичный доступ не на github-е, то сразу же вопрос: «а почему не на github-е?» А уж когда подключаешься к какому-то проекту, то там выбора вообще нет.

Непонятно что такое «правильно созданные условия». Я могу пропатчить ядро и сказать, что в каждый syscall процесса, в названии которого есть буква «g», вставляется sleep(1000), после чего заявить - смотрите, при правильно созданных условиях svn с cvs обгоняют git и hg! Говорит ли это что-то о производительности в real-world сценариях? Нет.

Перечитал еще раз страницу: полная херня же написана.

1. «у фейсбука тормозит гит на больших репозиториях, они пропатчили себе hg. Давайте теперь сравним bk с git на большом репозитории.» Почему не с hg?

2. «Real world conditions», блядь. Топовый i7, 64 (!) гига оперативки и вертящийся диск с ext3 через NFS. Дада, именно так в real world все и делают.

http://stackoverflow.com/a/26135822

Говорит ли это что-то о производительности в real-world сценариях?

Я себе это вижу так: авторы BitKeeper-а нашли условия, провели эксперименты, выложили и результат, и исходные данные. Что позволяет им говорить о том, что в таких условиях BK быстрее git.

Что же в ответ? Где какие-то другие цифры в ту или иную пользу?

Всех приверженцев git-а в этой ветке данные цифры почему-то задели. Фиг знает почему. Но вместо своей цифири здесь идут разговоры про профпригодность, про NFS и пр. херню.

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

Или дайте ссылку на тех, кто такие замеры делал.

у фейсбука тормозит гит на больших репозиториях, они пропатчили себе hg. Давайте теперь сравним bk с git на большом репозитории.

Т.е. то, что у FB hg работает быстрее и лучше, чем git, вас устраивает?

В hg заметно проще следующее, например:
* rebase; * показать файл из конкретного коммита; * посмотреть разницу с репкой на сервере.

А что значит проще? Можно посмотреть как вы это делаете и в hg, и в git?

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

Ваш поток сознания красноречиво говорит о ваших умственных способностях.

В то же время для hg достаточно было прочитать небольшую брошюрку с введением в hg и все. Шпаргалка, время от времени, требуется, но не постоянно.

А для git нельзя было прочитать небольшую брошюрку с пояснением?

Соответственно, когда я вижу в проекте, над которым с кем-то совместно работаем, некую проблему, то в случае с hg у сразу возникает понимание того, как сделать форк, как вести разработку некоторое время автономно, как время от времени мержить правки из основного репозитория. А вот для случая git-а такого понимания нет.

Так как все это делается в hg? Пока я слышу только одно - «в hg просто, а в git сложно».

Для себя я могу пользоваться чем угодно.

И это право у вас никто не отнимает.

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

Не уловил проблемы. Кто виноват-то?

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

Это очевидно.

А для git нельзя было прочитать небольшую брошюрку с пояснением?

Уже говорил:

Каждый раз после штудирования литературы (вроде Pro Git) оставалось ощущение того, что ничего не понимаю

Вот не нашел пока такой книжки, после которой бы захотелось git использовать.

Так как все это делается в hg?

В принципе, практически так же. Но на практике, почему-то, мне с hg проще.

Взять хотя бы теги. В hg просто tag и все, при следующем push-е тег уйдет в удаленный репозиторий. В git-е сколько способов создать tag? Что нужно сделать, чтобы запушить его?

Или вот как делается в git-е откат файла к первоначальному состоянию (то, что hg revert)? Есть git reset HEAD, есть git checkout --. Нужно понимать, в чем разница между ними. Хотя в большинстве случаев это вообще не нужно.

И таких мелочей может набраться порядком.

У меня, кстати, как раз наоборот. После того же Pro Git я довольно быстро начал работать с git. Правда в основном использую только fetch/push/pull/add/commit. Для работы более чем устраивает.

А с hg как-то это не сложилось.

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

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

Ваш поток сознания красноречиво говорит о ваших умственных способностях.

Сложно сказал, да? Ну ничего, попроси учительницу разъяснить.

Уже говорил:

Я это прочел. Мой поинт был в том, что бы найти такую же простую брошюру и по гиту.

Вот не нашел пока такой книжки, после которой бы захотелось git использовать.

Я один раз прошелся по https://git-scm.com/

В принципе, практически так же. Но на практике, почему-то, мне с hg проще.

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

Взять хотя бы теги.

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

Или вот как делается в git-е откат файла к первоначальному состоянию

Если не хочется запоминать, то можно сделать альяс на команду. Можно воспользоваться плагином git-fugitive к вим.
А еще есть хорошая консольная морда tig, для любителей морд.

И таких мелочей может набраться порядком.

Наверняка есть какие-то отличия, но так ли они принципиальны?

Сложно сказал, да? Ну ничего, попроси учительницу разъяснить.

Мне ваша учительница сказала, что сама не может вас понять. Говорит в с первого класса такой, даже добравшись до пятого класса так и остались тугим.

Можно посмотреть как вы это делаете и в hg, и в git?

rebase: git'у нужно указать три ветки. Я не в силах запомнить, что в каком порядке. У hg проще: --source, --dest и т.д.

Вытащить файл: `hg cat -r $REV $FNAME`. Всё. В git мне даже не удаётся запомнить, какой командой это делается. `cat-file`? `show`?

Посмотреть разницу с сервером: `hg in (out)`. Ну и `git log master..origin/master`. Или наоборот?

А кстати, git планирует переходить на что-нибудь вменяемое для хэшей, или так и будет в sha1 до конца своих дней?

Чем плохо SHA1?

Спасибо, сравнение принято. Тут гит проиграл.

Тем что он deprecated. Хотя-бы для новых репозиториев было бы полезно перейти на тот же sha256. Или на keccak.

Мой поинт был в том, что бы найти такую же простую брошюру и по гиту.

Пока не попадалось.

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

Думаю, что речь не про детали, а про более основополагающие вещи. Так, в git-е есть понятие index area (или как она там правильно называется), куда сначала нужно поместить изменение через git add, а лишь затем коммитить. В hg нет.

Если сильно задуматься, что можно найти смысл в том, что у git-а index есть. Но в большинстве случаев мне это не нужно, поэтому подход hg воспринимается более простым и логичным, чем понимание тонких различий между git add; git commit и git commit -a.

Если не хочется запоминать, то можно сделать альяс на команду.

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

Что значит «deprecated» по отношению к алгоритму? Сортировка пузырьком тоже «deprecated»?

Криптографическая стойкость её в случае git не важна.

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

Для этого люди заводят себе на bitbucket/github репки с красноречивыми названиями типа dotfiles и наколенными скриптиками для расставления символьных ссылок.

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

Так, в git-е есть понятие index area (или как она там правильно называется), куда сначала нужно поместить изменение через git add, а лишь затем коммитить.

Для меня это очень удобно. Я сам решаю, что попадет в коммит. Если нужно сразу все, то, как вы заметили, есть ключ -a.

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

У меня на этот случай есть команда git clone repo_with_my_configs, которая позволяет мне получить рабочее окружение на разных компьютерах и разных платформах.

То есть MD5 у нас уже не «криптографическая хэш функция», приехали.

Для меня это очень удобно.

А для меня нет.

У меня на этот случай есть

Ну а мне это и не нужно.

Ну вижу тотальное нежелание пользоваться git. Смысла обсуждать фичи и удобство тут нет. У меня такое же нежелание польоваться hg и нет желания его изучать. Когда есть острая необходимость поработать с hg, приходится гуглить шпаргалку, и каждая команда даётся с мучением, всё неудобно, всё не так, всё противно. Вот CVS и SVN - просты и понятны, git - волшебен, все команды наизусть и просто, а в hg ад какой-то.

А для меня нет.
Ну а мне это и не нужно.

Вас это обижает? :)
В гите есть два способа работы - с ручным управлением и автоматическим. И вы об этом знаете.
Вот анонимус привел хороший пример, где по удобству гит сливает ртути. А вы просто придираетесь. Так можно дойти до того, что команда hg короче на символ, чем команда git.

MD5
криптографическая хэш функция

только в историческом смысле

Вас это обижает?

Нет. Скорее мне это напоминает попытки объяснить, почему левше может быть неудобно носить часы (особенно механические) на левой руке :)

Тут изначально постановка вопроса неправильная. Вы исходите из того, что должны быть веские причины для неиспользования git-а. Я же исхожу из того, что должны быть веские причины использовать git. Т.к. на простых сценариях использования возможности hg/bzr и git сопоставимы.

Ну вижу тотальное нежелание пользоваться hg. И?

Скорее мне это напоминает попытки объяснить, почему левше может быть неудобно носить часы (особенно механические) на левой руке :)

Анонимус сумел.

Вы исходите из того, что должны быть веские причины для неиспользования git-а.

Вы меня с кем-то путаете.

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

Он выполняет поставленную задачу, делает это хорошо, работает быстро, доступен на всех нужных мне платформах. Для меня это веские причины.

Т.к. на простых сценариях использования возможности hg/bzr и git сопоставимы.

Тогда зачем менять git на что-либо другое? :)

Анонимус сумел.

Ну, видимо, для вас с анонимусом rebase — это важная фича. Я тут тоже приводил примеры, но вас они не убедили, тогда как для меня hg revert важнее, чем удобство rebase.

Вы меня с кем-то путаете.

Это вряд ли.

Он выполняет поставленную задачу, делает это хорошо, работает быстро, доступен на всех нужных мне платформах. Для меня это веские причины.

Ну в точности про hg :)

BitKeeper, полагаю, так же попадает в эту категорию :)

то, что у FB hg работает быстрее и лучше, чем git, вас устраивает?

Не так. «у FB hg работает быстрее и лучше после изрядного допиливания». В такой формулировке устраивает, масштабы FB действительно нетипичны и на них могут выходить на первый план неэффективные алгоритмы, работающие за приемлемое время на меньших масштабах. Но при этом остается открытым вопрос какие результаты показал бы Git после траты на его допиливание соизмеримых усилий.

С другой стороны, когда я натолкнулся на медленную работу Git'а в довольно нетипичном случае, оказалось достаточным просто отправить подробный багрепорт с описанием действий по воспроизведению в список рассылки, после чего разработчики самостоятельно оптимизировали неэффективный алгоритм (причем между багрепортом и появлением патча с фиксом прошла всего неделя): http://git.661346.n2.nabble.com/git-diff-is-slow-patience-is-fast-td6667216.html

Я тут тоже приводил примеры, но вас они не убедили, тогда как для меня hg revert важнее, чем удобство rebase.

Так реверт в гите отличается только в несколько символов или нежеланием настроить альясы.

Это вряд ли.

Где же я утверждал, что " что должны быть веские причины для неиспользования git-а"?

Ну в точности про hg :)

Он не умеет избирательный коммит:
git add file && git commit

BitKeeper, полагаю, так же попадает в эту категорию :)

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

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

По-моему, в свое время FB рассказывал, что они провели сравнение трудоемкости допиливания git и hg. Оказалось, что за счет плагинной архитектуры hg допиливание hg оказалось дешевле. Т.е. они не просто так отказались от доработки git-а.

Так реверт в гите отличается только в несколько символов или нежеланием настроить альясы.

Могу ошибаться, но у git-а реверт имеет две форму потому, что если измененный файл попал в index, то ревертить его нужно по-другому.

Он не умеет избирательный коммит:
git add file && git commit

hg commit file ?

Где же я утверждал, что " что должны быть веские причины для неиспользования git-а"?

Где же я утверждал, что вы это утверждали? Я сказал вот что: «Вы исходите из того, что должны быть веские причины для неиспользования git-а.» Т.е., у меня сложилось впечатление, что вы считаете git удобным инструментом и хотите узнать, в каких сценариях hg удобнее.

Я не считаю git удобным инструментом. В этом и разница.

Вот здесь Facebook пишет о выборе между git и hg:

We realized that we'd have to solve this ourselves. But instead of building a new system from scratch, we decided to take an existing one and make it scale. Our engineers were comfortable with Git and we preferred to stay with a familiar tool, so we took a long, hard look at improving it to work at scale. After much deliberation, we concluded that Git's internals would be difficult to work with for an ambitious scaling project.

Могу ошибаться, но у git-а реверт имеет две форму потому, что если измененный файл попал в index, то ревертить его нужно по-другому.

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

hg commit file ?

Чем эта команда очевиднее гитовской? Что делать, если я передумал коммитить этот файл или хочу внести исправление до коммита?

Я сказал вот что: «Вы исходите из того, что должны быть веские причины для неиспользования git-а.»

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

Т.е., у меня сложилось впечатление, что вы считаете git удобным инструментом и хотите узнать, в каких сценариях hg удобнее.

Верно, хотел узнать где ртуть будет удобнее гита.

Я не считаю git удобным инструментом. В этом и разница.

Пока ваши доводы меня не убедили. Скорее наоборот.

Чем эта команда очевиднее гитовской? Что делать, если я передумал коммитить этот файл или хочу внести исправление до коммита?

Что делать, если я сделал git commit и передумал коммитить этот файл? :) Вопрос того же уровня по-моему.

git checkout HEAD~ file && git commit --amend file

Что делать, если я сделал git commit и передумал коммитить этот файл? :)

Вопрос по гиту? Если пуш не сделан, то особой проблемы и в этом случае нет.