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

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

Не очевидно, откуда берутся эти самые «корзина» и «холодильник». И зачем они вообще нужны.

Чем эта команда очевиднее гитовской?

Зайдем на еще один круг. В git-е было решено, что должен быть index. Соответственно, то, что подлежит commit-у, должно быть собрано в index-е.

Кто-то может считать это разумным и удобным. Для таких пользователей нет принципиальной разницы между git add && git commit и hg commit.

Мне думается, что это index — это лишняя сущность и без нее можно обойтись. Соответственно, для меня hg commit удобнее тем, что я делаю нужную мне операцию без промежуточных шагов.

Кстати то, что revert делается по-разному, является следствием этого же решения.

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

Просто не коммитите.

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

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

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

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

Я не смогу объяснить, где для _вас_ hg будет удобнее git-а. Лишь пытаюсь безуспешно объяснить, что для _меня_ hg удобнее git-а.

Не очевидно, откуда берутся эти самые «корзина» и «холодильник». И зачем они вообще нужны.

Согласен, после svn было не очевидно.

Соответственно, для меня hg commit удобнее тем, что я делаю нужную мне операцию без промежуточных шагов.

git commit -a или любой удобный альяс.

Кстати то, что revert делается по-разному, является следствием этого же решения.

Мне повторить про корзину и холодильник? :)

Просто не коммитите.

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

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

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

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

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

Когда в равной степени не знаешь ни одну из этих систем, то сравниваешь их по-другому.

И мы приходим к «каждый кулик свое болото хвалит».

Я не смогу объяснить, где для _вас_ hg будет удобнее git-а. Лишь пытаюсь безуспешно объяснить, что для _меня_ hg удобнее git-а.

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

после svn было не очевидно

После hg так же не очевидно.

git commit -a или любой удобный альяс.

Речь же об отсутствии лишних шагов. Т.е. если у меня изменены три файла f1, f2 и f3, а я хочу закоммитить только f1 и f3, то git commit -a не прокатит. Нужно вспомнить про index. А если в index-е уже лежит f2, то тут мы пойдем куда-нибудь в stages. Тогда как в hg будет просто hg commit f1 f3.

Что значит изначально? Я же не родился со знанием о гите.

Ну и как вы остановились на git-е? Какие были альтернативы? Почему они были отвергнуты?

И мы приходим к «каждый кулик свое болото хвалит».

Что значит «приходим»? Я давно уже здесь.

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

В данной ветке никто. Но есть у меня ощущение, что вы хотите, чтобы вам объяснили, в каких случаях для вас hg будет удобнее git-а.

Вне этой ветки несколько напрягает то, что git сейчас практически де-факто стандарт. Хотя инструмент не простой, и не так уж много разработчиков хорошо его знают (имхо).

Читал, неубедительно. Графики без масштаба, okaaay.

На графике с «hg status» нет гита. Я несколько лет использовал git на репозитории с лямом файлов в working copy, status занимал 2с. Да, это немного медленее чем «мгновенно», но в пределах приемлемого. И с тех пор компы стали быстрее.

Графики с clone/pull тоже плохие. Я не удивлюсь если их remotefilelog показывает лучшее время тупо потому что он меньше скачивает, рассчитывая на то что скачает недостающее on demand. Но это в результате ускоряет одну операцию за счет замедления других (когда наступит этот самый demand).

То же самое с графиком траффика. Окей, из hg стали качать меньше потому что перенаправили траффик на memcached. Где график траффика до memcached? Чем memcached лучше еще одного сервера с hg? И hg и git можно раздавать вообще по http, поверх которого легко навернуть вообще какой угодно балансинг.

Ну и «отправили 500 патчей» - это много, очень много.

В общем да, они ускорили hg, молодцы. А мы просто настроили git-lfs и не патча ничего имеем отличный перфоманс на репозитории в несколько десятков гигабайт.

Читал, неубедительно

Аминь.

hg commit f1 f3

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

Речь же об отсутствии лишних шагов.

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

Ну и как вы остановились на git-е? Какие были альтернативы? Почему они были отвергнуты?

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

Что значит «приходим»? Я давно уже здесь.

Я так и сказал, вы давно хвалите hg. Но почему-то считаете, что это приверженцы git вас к чему-то агитируют.

Но есть у меня ощущение, что вы хотите, чтобы вам объяснили, в каких случаях для вас hg будет удобнее git-а.

Да, об этом я говорил прямым текстом несколько раз.

Вне этой ветки несколько напрягает то, что git сейчас практически де-факто стандарт.

Так почему вас это напрягает?

Хотя инструмент не простой, и не так уж много разработчиков хорошо его знают (имхо).

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

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

Горите в аду, любители выборочно коммитить изменения.

Зачем так категорично?

Не перечесть сколько раз наблюдал ситуации «ой, запушил лишний файл» и обратное «ой, забыл один файл залить».

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

Я так и сказал, вы давно хвалите hg.

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

Так почему вас это напрягает?

Не верю в «one side fits all».

Хороший нож может служить долго и исправно не один десяток лет.

Это если нож применяется по назначению и с должным уходом.

Потому что причинно-следственная связь. Выборочно коммитишь файлы -> время от времени ошибаешься при выборе. Это гарантированно лажающая стратегия. Хороший подход: в working copy не производятся изменения не относящиеся к решаемой задаче, коммитится всегда все.

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

Хороший подход: в working copy не производятся изменения не относящиеся к решаемой задаче, коммитится всегда все.

А заодно и в локальном бранче.

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

Сказал лишь, что для меня hg удобнее, чем git.

Так ваше мнение было услышано уже давно :)

Не верю в «one side fits all».

Я тоже, только какое это имеет отношение к обсуждаемому вопросу?

Это если нож применяется по назначению и с должным уходом.

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

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

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

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

Здесь возможны варианты. Мне к примеру часто лень создавать локальный бранч если я заранее знаю что задача небольшая. Тогда я создаю коммит находясь на мастере, после чего git push origin HEAD:feature-xxx && git reset --hard origin/master

Так ваше мнение было услышано уже давно :)

Извините, не заметил :)

Я тоже, только какое это имеет отношение к обсуждаемому вопросу?

К какому из вопросов?

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

А должно быть как-то иначе?

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

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

А если сравнить обе системы на локальной файловой системе?

Можно сравнить, только кому это будет надо? Bitkeeper (компания), понятно, хочет выделиться на фоне Git-а. А кому будет выгодно показать, что Git эффективнее Bitkeeper?

Если оставаться в рамках этих команд, то никакого профита от git-а нет.

Сразу видно старого SVN-щика. Ты свой SObjectizer до сих пор на sourceforge держишь? У SVN-щиков с Git-том почему-то возникают серьезные проблемы. Я не одного и не двух таких SVN-щиков видел, которые очень болезненно воспринимают Git. Можно уже проследить общую тенденцию.

Если у вас нет стандарта де-факто, а существующие альтернативы не предполагают легкого кросс-взаимодействия

Во-первых, здесь речь идет не о POSIX или ASN1. А о системе контроля версий.

Во-вторых, правильно ли я понимаю, что стандарт де-факто в таких областях, как текстовые редакторы, IDE, статические анализаторы и пр. — это хорошо?

Это они очень своевременно сделали.

Я не одного и не двух таких SVN-щиков видел, которые очень болезненно воспринимают Git. Можно уже проследить общую тенденцию.

Т.е. проблемы не в git-а, а в людях, которые предпочитают git-у другие инструменты?

Пути достижения цели разнообразны, каждому своя дорога :)

Ну и какие проблемы? Думаете, что кто-то плюнул в ваш любимый инструмент?

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

Сейчас вы уже не так категоричны.

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

Можно сделать с другой архитектурой под свои задачи. Но это не значит лучше. Всплывут другие минусы.

И инструмент не любимый. Мне нравилось пользоваться hg, пока не всплыла проблема и не пришлось заглянуть в его внутренности.

Часто такое слышу, но никто не может внятно объяснить, чем ртуть лучше гита.

Я могу сформулировать для кого она лучше.

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

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

Спасибо, это тоже весомый аргумент в пользу ртути.

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

Я сказал, что git не производит впечатление инструмента, над которым много думали и который тщательно разрабатывали. Как по мне, есть разница между «не думали много» и «особо не думали».

Думали как раз столько, чтобы получилось «good enough». Именно это и получилось.

Как я понимаю, проблемы с git blame на больших историях — это врожденная особенность git-а. Как и заточенность под Unix-ы. Как и некоторые особенности CLI-интерфейса (которые можно только заучить, но невозможно понять). Как по мне, так это свидетельства того, что именно тщательного, кропотливого проектирования в git-е изначально не было. И меня это не удивляет, т.к. git был разработан очень в сжатые сроки.

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

Слишком категорично.

Как минимум один юскейс знаю, когда это выгодно во всех планах.

Добавляешь новую фичу. В процессе обнаружил и исправил мелкий (в плане объема изменений) баг.

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

Он не умеет избирательный коммит:

git add file && git commit

Есть расширение record (в штатной поставке).

Для любителей staging area есть mq.

Проблема того, что по умолчанию есть SA в том, что `git commit` фиксирует не то, что находится в рабочей копии. То есть ты внёс какое-то изменение осмысленное, сделал `git add .`, стал тестировать, и выяснилось, что где-то что-то недоглядел. Исправил строчку, тесты проходят, сделал `git commit`, а потом узнал, что эту строчку забыл добавить.

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

Проще и надёжнее в таких случаях откладывать фичу в сторону, делать фикс, после чего возвращаться к фиче.

Это не проще и не надежнее. Фикс вообще не связан с новым кодом.

От слова «абсолютно». Просто его заметил.

Что может быть проще, чем: закомитил фикс, доработал новую фичу, перенес фикс в нужную ветку? Тестируй.

Во-вторых, правильно ли я понимаю, что стандарт де-факто в таких областях, как текстовые редакторы, IDE, статические анализаторы и пр. — это хорошо?

Да, я так считаю. LSB вроде даже пытается это расширять/углублять, но чо-то вяло.

Это удобно что на любой линуксовой машине есть cat/ls/grep и прочие стандартные-де-факто утилиты. Важно что все они good enough и не вызывают желания искать альтернативы.

Это удобно, что сев за компьютер коллеги (скажем, чтобы помочь ему в написании какого-то кода) вы оказываетесь в той же IDE (включая те же алиасы клавиш), что используете сами. Потому что в противном случае вы либо страдаете об непривычное окружение либо тратите время на то чтобы создать на его машине окружение привычное вам.

Появление альтернатив такой подход не отменяет, просто они (чтобы получить хоть сколько-нибудь массовое применение) должны будут быть в чём-то заметно лучше. Поэтому svn легко вытеснил cvs, поэтому git легко вытесняет svn. Но вот hg уже ничего сделать не сможет, он на старте отстал от git'а по популярности, а теперь не имеет настолько значительных преимуществ чтобы перевесить де-факто-стандартность git'а.

Ваша точка зрения понятна. Красноглазненькая такая.

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

Здесь вы не правы. Если программист выполняет плановую работу, то он может четко заранее определить, какие файлы он меняет. То есть он делает git add _до_ начала работы. Или тогда, когда, определилс со списком изменений. А коммит он делает тогда, когда завершил работу. А до этого он свободен в планировании, какие файлы он включает или удаляет из коммита.

В вашем случае, все это делается в один присест во время коммита, а не тогда, когда собственно, определяется список изменений.

В домашней работе, когда git add всегда идет сразу перед git commit разницы никакой нет, скорее неудобство в git, но в серьезных работах с планированием и разделением ресурсов это большая разница.

То есть он делает git add _до_ начала работы.

Простите мне мое незнание git-а, но я думал, что дело обстоит так:

• меняем строку #1 в файле f1;
• делаем git add f1
• меняем строку #2 в этом же файле f1;
• делаем git commit;
• в репозиторий сохраняется версия f1 с измененной строкой #1, но со старой строкой #2.

Соответственно, если вы сделаете git add _до_ начала работы, потом внесете правки и затем сделаете git commit, то как ваши правки окажутся в репозитории?

Есть расширение record (в штатной поставке).

Ну то есть из hg можно сделать git. Не проще ли просто использовать git? ;)

Да, верно. Тут я опозорился на ровном месте.

Добавлять файлы надо после их изменения. Но Добавлять их можно по одному и в процессе работы, когда еще понятно, куда эти изменения идут, а коммит все равно будет один и в конце работы в целом.

Как ни крути, это лишнее действие. Проект всегда весь в системе контроля за исключением игнорируемых путей. В 99% случаев все изменённые файлы коммитятся, любые другие варианты это провокация ошибок. Собственно в любой интеграции Git-а в IDE, которые я видел, никакого Staging-а в интерфейсе нет, все изменённые файлы коммитятся как есть. Staging area это какая-то внутренняя деталь реализации, которая торчит нарушу и мешается. Другой вопрос, что мешается не сильно, git status перед коммитом все всегда делают и там всё видно (ну или в редакторе при вводе сообщения).

Staging area это какая-то внутренняя деталь реализации, которая торчит нарушу и мешается

Staging area - отличная идея, на самом деле, но, как и весь git, сделана через задницу. Правильно сделанная staging area - это mq в Mercurial и, возможно, stgit/guilt/еще-что-то в Git.

что вы хотели этим доказать

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

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

любые другие варианты это провокация ошибок.

«Любое другое мнение ошибочно». Где-то я уже подобное слышал.

Собственно в любой интеграции Git-а в IDE, которые я видел, никакого Staging-а в интерфейсе нет

Это говорит о корявой реализации поддержки гита.
Плагин vim-fugitive позволяет мне самому решить, что коммитить, а что нет. Но ведь vim не ide.

Staging area это какая-то внутренняя деталь реализации, которая торчит нарушу и мешается.

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

git status перед коммитом все всегда делают

Я делаю. Но я уверен, что делают не все.

«Любое другое мнение ошибочно». Где-то я уже подобное слышал.

Да нет, механическое действие, не имеющее особого смысла действительно провоцирует ошибки. Сто раз сделал git add, а на сто первый не сделал и все, файлик не попал в коммит.

«Любое другое мнение ошибочно». Где-то я уже подобное слышал.

Да нет, механическое действие, не имеющее особого смысла действительно провоцирует ошибки. Сто раз сделал git add, а на сто первый не сделал и все, файлик не попал в коммит.

Сто раз сделал git add, а на сто первый не сделал и все, файлик не попал в коммит.

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

Это одно действие и одна вероятность ошибки, а тут два действия и вероятность поэтому выше. Особенно в том, что касается человеческого фактора. Люди не роботы и очень не любят повторяющуюся работу, не имеющую видимого смысла. Даже если эта работа несложная.

В JetBrains'овских IDE можно выбрать, какие файлы попадают в коммит, а какие нет. Те, которые не попадают, IDE самостоятельно предлагает тут же включить в следующий коммит, т.е. ориентируется она, как я понимаю, на тот самый кейс «Я внёс изменения по своей задаче плюс заодно внёс мелкофикс в другом файле».

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

А причём тут избирательное указание файлов для коммита? Это есть в любой системе. Я про Staging Area. Когда можно внести туда файл, потом изменить его и закоммитить ту, внесённую ранее версию. Да, можно придумать случай, когда это может быть полезно, но в 99% случаев это будет ошибка, да ещё и не очень очевидная, если не вглядываться в status каждый раз.