Знаю, тема много раз подымалась. Но нужна более свежее мнение по поводу выбора в использовании Git или Mercurial.
Необходимость выбора возникла из-за того, что компания Аtlassian (которая делает Jira) на своём хосте проектов прекращает поддержку Subversion (SVN) хранилищ. Соответственно, предлагает перейти на Git или Mercurial.
И теперь руководитель проекта требует сделать выбор. А так как, я все время проработал с SVN, иногда сталкивался с TFS и в начале своей карьеры видал MS SourceSafe, в общем, не имею практического использования ни Git, ни Mercurial, то выбор сделать сложно.
Поэтому прошу помочь и поделиться свежими впечатлениями.
----
"Ответить на вопрос — значит согласиться с правильностью его постановки.", Карстен Бредемайер
Здравствуйте, MaLS, Вы писали:
MLS>И теперь руководитель проекта требует сделать выбор. А так как, я все время проработал с SVN, иногда сталкивался с TFS и в начале своей карьеры видал MS SourceSafe, в общем, не имею практического использования ни Git, ни Mercurial, то выбор сделать сложно.
Mercurial очень похож по командам на SVN, поэтому вам на него будет проще переходить. Git очень умный, но очень сложный и непривычный в управлении.
Здравствуйте, MaLS, Вы писали:
MLS>..., в общем, не имею практического использования ни Git, ни Mercurial, то выбор сделать сложно. MLS>Поэтому прошу помочь и поделиться свежими впечатлениями.
Если в команде есть люди, предпочитающие одну из систем, брать её. Обе достаточно хороши для production. В крайнем случае, попробовать самому. Остальное скатится в holywar.
Здравствуйте, MaLS, Вы писали:
MLS>Поэтому прошу помочь и поделиться свежими впечатлениями.
Git. К сожалению, не работал с Hg, но есть большой опыт с SVN, в том числе и сложным CM. Также работал с cvs и perforce.
После работы с GIT пришёл к выводу, что он самый удобный из всех для команды с грамотным CM.
Здравствуйте, MaLS, Вы писали:
MLS>Поэтому прошу помочь и поделиться свежими впечатлениями.
Git, лично я в свое время повелся на кажущуюся простоту меркуриала, но потом все равно пришел к гиту. Меня обманули, гит оказался проще. Главное не начинать с командной строки если конечно она не является для вас родным домом.
Возьмите GitExtensions (я их даже под линуксом использую иногда) и поиграйтесь. Еще есть хорошая вводная статья
MLS>Знаю, тема много раз подымалась. Но нужна более свежее мнение по поводу выбора в использовании Git или Mercurial.
Я за Git. Вполне легко перешел с SVN.
Рекомендую сначала почитать принципы работы. Не стоит начинать с поиска прямых аналогий с SVN.
Подскажите, пожалуйста, у нас сейчас в одном хранилище храниться множество под проектов. Соответственно, используя SVN я локально получаю только нужную под-ветку и работаю с ней.
Как мне сказали, в Mercurial требует скачивать локально всё хранилище от корня. Для нас нет смысла перегонять весь огромный проект локально.
Таким образом в Git можно получить только часть хранилища, т.е. под-ветку?
----
"Ответить на вопрос — значит согласиться с правильностью его постановки.", Карстен Бредемайер
Здравствуйте, MaLS, Вы писали:
MLS>Здравствуйте, TimurSPB,
MLS>Подскажите, пожалуйста, у нас сейчас в одном хранилище храниться множество под проектов. Соответственно, используя SVN я локально получаю только нужную под-ветку и работаю с ней. MLS>Как мне сказали, в Mercurial требует скачивать локально всё хранилище от корня. Для нас нет смысла перегонять весь огромный проект локально.
Прочитай вводные статьи, там объясняется концепция репозитория git. MLS>Таким образом в Git можно получить только часть хранилища, т.е. под-ветку?
Git следит за всем деревом исходников. Т.е. в вашем случаее нужно будет делать одно git хранилище под каждый проект чтобы получить только один проект. Если все проекты будут в одном репозитории, то придётся выкачиваться всё.
Здравствуйте, MaLS, Вы писали:
MLS>Соответственно, предлагает перейти на Git или Mercurial.
Я использовал все три: и Bazaar, и Git, и Mercurial. Они очень похожи. Концепции чуть различаются, например, ветки в них всех сделаны по-разному. У каждой из них есть свои недостатки, некоторые очень неприятные. Ни про один из использованных подходов нельзя сказать, что он строго лучше любого другого.
Bazaar тормозит.
Mercurial тормозит.
Git не тормозит.
Здравствуйте, vsb, Вы писали:
vsb>Mercurial технически лучше. Git распиарен и популярен. Поэтому лучше git.
У меня сложилось противоположное мнение. Технически git лучше продуман, поэтому невероятно гибкий и расширяемый.
Устройство git — очень простое, как и всё гениальное. И всё в подробностях описано в документации.
Как мне кажется, собственно поэтому он и пиарится легче. Где аналог gerrit для hg?
А кто нибудь может рассказать о Mercurial как он устроен, что там внутри творится?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, MaLS, Вы писали:
MLS>Знаю, тема много раз подымалась. Но нужна более свежее мнение по поводу выбора в использовании Git или Mercurial.
За git, по следующим причинам:
1. Некоторые чрезвычайно удобные фишки, которые в конкурентах отсутствуют, в первую очередь это отдельное понятие "индекса", которое на порядки упрощает действия типа "я тут пол-файла наменял, разбираясь в этой хрени, а теперь мне это надо логически разделить на десять разных коммитов, причём часть действий пока не отправлять, потому что не уверен, а некоторые вообще только мои локальные хаки, их тем более не отправлять".
У аналогов в лучшем случае жалкая подделка. Аналогично, переформатирование предварительно сложенного локально набора коммитов перед их отправкой вверх — помогает предельно просто и ясно разделить разные изменения по ролям и сделать каждое из них однозначным и легко понятным.
2. Инфраструктурные средства для коллективной работы, такие, как gerrit. Аналоги хуже (например, универсальный review board значительно менее удобен). Впрочем, при Jira непонятно, на что это влияет.
3. В разы большее количество людей, уже знакомых с ним.
Здравствуйте, MaLS, Вы писали:
MLS>Поэтому прошу помочь и поделиться свежими впечатлениями.
Git, по моему мнению, чрезмерно черезжопен и обладает топой яростных и шумных фанатов. Mercurial -- опять же, по моему мнению -- прост и понятен; коммьюнити не такое большое и не так популярен.
Я за Hg.
HgLab: Mercurial Server and Repository Management for Windows
Здравствуйте, MaLS, Вы писали:
MLS>Привет народ.
MLS>Знаю, тема много раз подымалась. Но нужна более свежее мнение по поводу выбора в использовании Git или Mercurial.
MLS>Необходимость выбора возникла из-за того, что компания Аtlassian (которая делает Jira) на своём хосте проектов прекращает поддержку Subversion (SVN) хранилищ. Соответственно, предлагает перейти на Git или Mercurial. MLS>И теперь руководитель проекта требует сделать выбор. А так как, я все время проработал с SVN, иногда сталкивался с TFS и в начале своей карьеры видал MS SourceSafe, в общем, не имею практического использования ни Git, ни Mercurial, то выбор сделать сложно.
MLS>Поэтому прошу помочь и поделиться свежими впечатлениями.
меркуриал более легковесен в установке на венду чем гит, установка гита на венде тянет установку MSys, и если вы ставите отдельный пакет типа TortoiseGit — то это еще 1 мсис к уже имеющимся, и тутначинаются танцы с конкуренцией мсисов ранее установленых продуктов. меркуриал за счет полной питоновости совершенно прозрачен и легок для установки везде.
помимо этого для меня просто эпичен и незаменин плагин mq и в полка в мекруриале. Собственно за них я "ртуть" и полюбил и свн анафеме предал.
аналоги их наверное есть в гите и вообще в линях, но меркуриал их таскает с собой как интегрированные а в TortoiseGit и в базаре я их не нашел.
сборки и базара и гита для венды частенько выдают ошибки и падения на венде. от меркуриала видел весьма стабильную, по сравнению с теми, работу.
походу гит более распространен и более поддержан. меркуриал в теории имеет средства синхронизации с свн, на практике они походу работают только под линями, а под венду чтобы соотвествующий плагин поставить надо попотеть. он может нормально затягивать из меркуриала но из свн — наилоегчайшее что я нашел скрипты hgsvn. он они конечно убоги, и требуют большой работы еще.
Здравствуйте, alexraynepe196, Вы писали:
A>меркуриал в теории имеет средства синхронизации с свн, на практике они походу работают только под линями, а под венду чтобы соотвествующий плагин поставить надо попотеть. он может нормально затягивать из меркуриала но из свн — наилоегчайшее что я нашел скрипты hgsvn. он они конечно убоги, и требуют большой работы еще.
Пользуюсь hgsubversion больше 2х лет. Практически абсолютная интеграция. И я не встретил никаких серьезных проблем за это время.
Ты работаешь с репозиторием svn как будто он меркуриаловский. Единственное что, это невозможность мержа из меркуриала и hg rebase --svn после пула. Но причины обоих ограничений понятны и, в принципе, не доставляют проблем вообще.
СУВ, Aikin
... << RSDN@Home 1.2.0 alpha 5 rev. 1539>>
Re[3]: Git или Mercurial в замен SVN
От:
Аноним
Дата:
08.06.13 13:07
Оценка:
Здравствуйте, MaLS, Вы писали:
MLS>Здравствуйте, TimurSPB,
MLS>Подскажите, пожалуйста, у нас сейчас в одном хранилище храниться множество под проектов. Соответственно, используя SVN я локально получаю только нужную под-ветку и работаю с ней. MLS>Как мне сказали, в Mercurial требует скачивать локально всё хранилище от корня. Для нас нет смысла перегонять весь огромный проект локально. MLS>Таким образом в Git можно получить только часть хранилища, т.е. под-ветку?
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, minorlogic, Вы писали:
M>>Первое впечатление о GIT, кусок Г. Не позволяет прозрачно отследить историю изменения файла.
N>Что значит прозрачно? git {log|annotate|blame} $file — чем плохо?
Плохо тем , что я понятия не имею что ты написал. Если для этого надо изучать 3х томный мануал , то в баню всю систему.
M>> Родной клиент GIT это каждый коммит == русская рулетка.
N>Не понимаю. Никаких проблем с коммитами в родном клиенте.
Не шути, родной клиент это издевательсво над здравым смыслом. Такие операции , как отследить историю изменений файла , простые ресолвы конфликтов , синхронизация с анешним хранилищем отсутствуют. Это просто эпик фейл
Здравствуйте, minorlogic, Вы писали:
M>>>Первое впечатление о GIT, кусок Г. Не позволяет прозрачно отследить историю изменения файла.
N>>Что значит прозрачно? git {log|annotate|blame} $file — чем плохо?
M>Плохо тем , что я понятия не имею что ты написал. Если для этого надо изучать 3х томный мануал , то в баню всю систему.
Трёхтомный мануал — это миф. Для описания основных действий и методов работы достаточно десятка легко читаемых страниц. И то же самое нужно для любой SCM.
M>>> Родной клиент GIT это каждый коммит == русская рулетка. N>>Не понимаю. Никаких проблем с коммитами в родном клиенте. M>Не шути, родной клиент это издевательсво над здравым смыслом. Такие операции , как отследить историю изменений файла , простые ресолвы конфликтов , синхронизация с анешним хранилищем отсутствуют. Это просто эпик фейл
Я не знаю, как ты считаешь, что их нет, если они все есть.
История изменений? git log — показать историю коммитов. git blame, git annotate — показать для каждой строчки id коммита, из которого она возникла.
Резолвинг конфликтов? Выполняется в рамках той операции, в которой возник конфликт. Это может быть merge, cherry-pick, stash pop или ещё какая-то.
Синхронизация? git {push|pull|fetch}.
Всё есть и никакого фейла, сплошной вин
Здравствуйте, minorlogic, Вы писали:
N>>Что значит прозрачно? git {log|annotate|blame} $file — чем плохо? M>Плохо тем , что я понятия не имею что ты написал. Если для этого надо изучать 3х томный мануал , то в баню всю систему.
Единственный интуитивно-понятный интерфейс — это сиська у мамы. Всё остальное надо изучать.
Конкретно у git есть свои... эээ... идиосинкразии, но ни один из упомянутых примеров к ним не относится.
N>>Не понимаю. Никаких проблем с коммитами в родном клиенте. M>Не шути, родной клиент это издевательсво над здравым смыслом. Такие операции , как отследить историю изменений файла , простые ресолвы конфликтов , синхронизация с анешним хранилищем отсутствуют. Это просто эпик фейл
1) Отследить историю: "git log <filename>". Что сложного и непонятного? Блин, что вообще может быть ПРОЩЕ?
2) Резольвинг конфликтов — делаем "git pull" (merge, ...) и файлы с конфликтами помечаются специальными маркерами в местах конфликтов. Стандартное для VCS поведение.
3) "Синхронизация с внешним хранилищем отсутствуют" — это вообще что такое?
Здравствуйте, netch80, Вы писали:
N>Трёхтомный мануал — это миф. Для описания основных действий и методов работы достаточно десятка легко читаемых страниц. И то же самое нужно для любой SCM.
Если у системы отсутствует удобный клиент под основыне ОС (оконный, полнофункциональный), то она не имеет права на существование в 2013 году. У меня много более важных дел , чем тратить время на бесполезное изучение очередного Г.
C>1) Отследить историю: "git log <filename>". Что сложного и непонятного? Блин, что вообще может быть ПРОЩЕ? C>2) Резольвинг конфликтов — делаем "git pull" (merge, ...) и файлы с конфликтами помечаются специальными маркерами в местах конфликтов. Стандартное для VCS поведение. C>3) "Синхронизация с внешним хранилищем отсутствуют" — это вообще что такое?
Вы простите в 1970 г пришельцы ??? как можно пользоваться системой которая не уважает пользователя и его личное время ?
Здравствуйте, minorlogic, Вы писали:
M>Вы простите в 1970 г пришельцы ??? как можно пользоваться системой которая не уважает пользователя и его личное время ?
Она его отлично уважает. Я при текущем стиле разработки на гите получаю значительно меньше затрат на фиксацию изменений, подготовку их в ясном и пригодном виде, чтении истории, поиске проблемы, переносах между ветками и трейнами и т.д., чем на любом другом SCM. Конечно, я не исследовал их всех. Я не пробовал, например, Monotone, а ещё мне страшно не понравился Arch, я не пробовал Darcs, и так далее. Но среди основных — git на сейчас лучший.
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, minorlogic, Вы писали:
M>>Вы простите в 1970 г пришельцы ??? как можно пользоваться системой которая не уважает пользователя и его личное время ?
N>Она его отлично уважает. Я при текущем стиле разработки на гите получаю значительно меньше затрат на фиксацию изменений, подготовку их в ясном и пригодном виде, чтении истории, поиске проблемы, переносах между ветками и трейнами и т.д., чем на любом другом SCM. Конечно, я не исследовал их всех. Я не пробовал, например, Monotone, а ещё мне страшно не понравился Arch, я не пробовал Darcs, и так далее. Но среди основных — git на сейчас лучший.
Мне есть с чем сравнивать. На SVN Perforce и т.п. клиенты я затрачивал ровно 0 времени на изучение. В этом контексте GIT проигрывает в бесконечное число раз.
Здравствуйте, Cyberax, Вы писали:
C>1) Отследить историю: "git log <filename>". Что сложного и непонятного? Блин, что вообще может быть ПРОЩЕ?
Справедливости ради надо сказать, что если <filename> был переименован/перемещён, то "git log <filename>" покажет историю именно <filename>, а она начинается с момента переименования/перемещения. Чтобы посмотреть историю <filename> до того, приходится делать некоторые приседания.
Здравствуйте, minorlogic, Вы писали:
N>>Трёхтомный мануал — это миф. Для описания основных действий и методов работы достаточно десятка легко читаемых страниц. И то же самое нужно для любой SCM.
M>Если у системы отсутствует удобный клиент под основыне ОС (оконный, полнофункциональный), то она не имеет права на существование в 2013 году.
Хм. Сказал "git gui". Вижу клиента — оконного и, наверно, полнофункционального (пока не вижу, чего он не умеет). Чего тебе ещё не хватает?
M> У меня много более важных дел , чем тратить время на бесполезное изучение очередного Г.
Здравствуйте, minorlogic, Вы писали:
M>Мне есть с чем сравнивать. На SVN Perforce и т.п. клиенты я затрачивал ровно 0 времени на изучение. В этом контексте GIT проигрывает в бесконечное число раз.
То есть ты банально не осилил. Может, изложишь тут, чего именно ты не смог осилить? Может, поможем всем миром.
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, minorlogic, Вы писали:
M>>Мне есть с чем сравнивать. На SVN Perforce и т.п. клиенты я затрачивал ровно 0 времени на изучение. В этом контексте GIT проигрывает в бесконечное число раз.
N>То есть ты банально не осилил. Может, изложишь тут, чего именно ты не смог осилить? Может, поможем всем миром.
Я перечислил задачи которые не смог решить в стандартной клиенте. Я скачал клиент от GIThub для мака и винды. Как в них в них сделать перечисленные действия ? или укажите другой клиент который все это делает.
Комманд лайн не предлагать, за убогостью самой концепции.
N>Хм. Сказал "git gui". Вижу клиента — оконного и, наверно, полнофункционального (пока не вижу, чего он не умеет). Чего тебе ещё не хватает?
ССылку дайте , может поможет (без иронии).
M>> У меня много более важных дел , чем тратить время на бесполезное изучение очередного Г.
N>Весьма полезное изучение.
Однозначно ент. Любой command line интерфейс в 2013 г, это пустая трата времени.
Здравствуйте, rising_edge, Вы писали:
C>>1) Отследить историю: "git log <filename>". Что сложного и непонятного? Блин, что вообще может быть ПРОЩЕ? _>Справедливости ради надо сказать, что если <filename> был переименован/перемещён, то "git log <filename>" покажет историю именно <filename>, а она начинается с момента переименования/перемещения. Чтобы посмотреть историю <filename> до того, приходится делать некоторые приседания.
"git log --follow" тогда помогает. Хотя и с ограничениями, из-за фундаментальных особенностей хранения истории.
Впрочем, SVN точно так же может ломать историю, если вместо "svn mv" сделать пару add/remove.
Здравствуйте, minorlogic, Вы писали:
C>>3) "Синхронизация с внешним хранилищем отсутствуют" — это вообще что такое? M>Вы простите в 1970 г пришельцы ??? как можно пользоваться системой которая не уважает пользователя и его личное время ?
Что не так? Ниасилил командную строку? Впрочем на то и похоже, так как Гугл тоже ниасилил — там ведь тоже командная строка для ввода текста.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, minorlogic, Вы писали:
C>>>3) "Синхронизация с внешним хранилищем отсутствуют" — это вообще что такое? M>>Вы простите в 1970 г пришельцы ??? как можно пользоваться системой которая не уважает пользователя и его личное время ? C>Что не так? Ниасилил командную строку? Впрочем на то и похоже, так как Гугл тоже ниасилил — там ведь тоже командная строка для ввода текста.
Повторяю в 4й раз, не осилил. Командная строка это полное неуважение к пользователю и растрата моего личного времени. (особенно учитывая что я 2мя пальцами печатаю). Т.е. любая аппеляция к командной строке я считаю посыланием нах , меня как пользователя.
Здравствуйте, minorlogic, Вы писали:
M>Повторяю в 4й раз, не осилил. Командная строка это полное неуважение к пользователю и растрата моего личного времени. (особенно учитывая что я 2мя пальцами печатаю). Т.е. любая аппеляция к командной строке я считаю посыланием нах , меня как пользователя.
Мне кажется что о растрате вашего личного времени вам должно быть неловко упрекать кого-то еще, учитывая то что печатаете 2мя пальцами. И что если вы действительно печетесь о своем личном времени и у вас нет каких либо физических ограничений, то следует рассмотреть вопрос об освоении более продвинутых техник печати... Имхо, окупите затраченное на освоение время и нервы.
Здравствуйте, samius, Вы писали:
S>Мне кажется что о растрате вашего личного времени вам должно быть неловко упрекать кого-то еще, учитывая то что печатаете 2мя пальцами. И что если вы действительно печетесь о своем личном времени и у вас нет каких либо физических ограничений, то следует рассмотреть вопрос об освоении более продвинутых техник печати... Имхо, окупите затраченное на освоение время и нервы
Вы совершенно не правы. Для моей работы быстрая печать вообще не являтся как либо ощутимым фактором.
Здравствуйте, minorlogic, Вы писали:
M>>>Вы простите в 1970 г пришельцы ??? как можно пользоваться системой которая не уважает пользователя и его личное время ? C>>Что не так? Ниасилил командную строку? Впрочем на то и похоже, так как Гугл тоже ниасилил — там ведь тоже командная строка для ввода текста. M>Повторяю в 4й раз, не осилил. Командная строка это полное неуважение к пользователю и растрата моего личного времени.
Ну вот и нефиг заставлять разработчиков git тратить их (крайне ценное!) личное время на поддержку пользователей, которые не могут пользоваться Гуглом.
Кстати, SVN, вообще-то, тоже только из командной строки работает. Не знал?
Здравствуйте, minorlogic, Вы писали:
M>Здравствуйте, samius, Вы писали:
S>>Мне кажется что о растрате вашего личного времени вам должно быть неловко упрекать кого-то еще, учитывая то что печатаете 2мя пальцами. И что если вы действительно печетесь о своем личном времени и у вас нет каких либо физических ограничений, то следует рассмотреть вопрос об освоении более продвинутых техник печати... Имхо, окупите затраченное на освоение время и нервы
M>Вы совершенно не правы. Для моей работы быстрая печать вообще не являтся как либо ощутимым фактором.
Конечно, видимо вам виднее. Но я когда-то тоже так думал. Дело даже не в скорости печати, а в том что когда печатать все-таки приходится, то 2 пальца и необходимость постоянной перефокусировки зрения с монитора на клавиатуру очень утомляют.
S>Конечно, видимо вам виднее. Но я когда-то тоже так думал. Дело даже не в скорости печати, а в том что когда печатать все-таки приходится, то 2 пальца и необходимость постоянной перефокусировки зрения с монитора на клавиатуру очень утомляют.
да текста. M>>Повторяю в 4й раз, не осилил. Командная строка это полное неуважение к пользователю и растрата моего личного времени. C>Ну вот и нефиг заставлять разработчиков git тратить их (крайне ценное!) личное время на поддержку пользователей, которые не могут пользоваться Гуглом.
Здравствуйте, minorlogic, Вы писали:
M>да текста. M>>>Повторяю в 4й раз, не осилил. Командная строка это полное неуважение к пользователю и растрата моего личного времени. C>>Ну вот и нефиг заставлять разработчиков git тратить их (крайне ценное!) личное время на поддержку пользователей, которые не могут пользоваться Гуглом. M>Ну тогда в нулл, их продукт. Логично ?
Абсолютно. Тем программистам, кто не может освоить Гугл — лучше использовать RAR-архивы.
Или вообще не трогать клавиатуру и компьютер вообще, сохранив огромное количество личного времени всех.
Здравствуйте, minorlogic, Вы писали:
C>>Абсолютно. Тем программистам, кто не может освоить Гугл — лучше использовать RAR-архивы. M>Ты же понимаешь , что это совершенно неадекватно , лазить в гугл для очевидных операций которые могут всплывать в меню по нажатию кнопки мышки ?
Если ты ставил официальный msysgit, то там есть интеграция Git Bash из правой кнопки. Что не нравится?
Здравствуйте, minorlogic, Вы писали:
M>Первое впечатление о GIT, кусок Г. Не позволяет прозрачно отследить историю изменения файла. Родной клиент GIT это каждый коммит == русская рулетка.
под виндой для гита лучше использовать встроенный в ide гуй. консоль там ущербная имхо(а с двумя пальцами так вообще смертельно), некоторые гуёвые клиенты кривы до ужаса. например, tortoisegit делали люди далёкие от юзабилити. даже человеку с опытом нелегко понять последовательность действий.
из отдельных гуёв я бы порекомендовал gitg. достаточно наглядный.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, minorlogic, Вы писали:
C>>>Абсолютно. Тем программистам, кто не может освоить Гугл — лучше использовать RAR-архивы. M>>Ты же понимаешь , что это совершенно неадекватно , лазить в гугл для очевидных операций которые могут всплывать в меню по нажатию кнопки мышки ? C>Если ты ставил официальный msysgit, то там есть интеграция Git Bash из правой кнопки. Что не нравится?
Здравствуйте, neFormal, Вы писали:
F>Здравствуйте, minorlogic, Вы писали:
M>>Первое впечатление о GIT, кусок Г. Не позволяет прозрачно отследить историю изменения файла. Родной клиент GIT это каждый коммит == русская рулетка.
F>под виндой для гита лучше использовать встроенный в ide гуй. консоль там ущербная имхо(а с двумя пальцами так вообще смертельно), некоторые гуёвые клиенты кривы до ужаса. например, tortoisegit делали люди далёкие от юзабилити. даже человеку с опытом нелегко понять последовательность действий. F>из отдельных гуёв я бы порекомендовал gitg. достаточно наглядный.
Спасибо , может руки дойдут. А про source tree что скажете ?
Здравствуйте, minorlogic, Вы писали:
M>>>Первое впечатление о GIT, кусок Г. Не позволяет прозрачно отследить историю изменения файла. N>>Что значит прозрачно? git {log|annotate|blame} $file — чем плохо? M>Плохо тем , что я понятия не имею что ты написал. Если для этого надо изучать 3х томный мануал , то в баню всю систему.
если ты не способен найти сам(!) и оценить, какой объём инфы надо изучить, то тебе давно пора в руководители без права принятия технических решений
Здравствуйте, neFormal, Вы писали:
F>если ты не способен найти сам(!) и оценить, какой объём инфы надо изучить, то тебе давно пора в руководители без права принятия технических решений
F>из вот этого: F>http://git-scm.com/book/ru F>тебе надо 2-3 достаточно скромных по объёму главы
я уже писал , это бесконечно большие затраты по сравнению с нормальным клиентом. А в командной строке я ковырялся , ибо не было другого выхода. Удовольствия это мне не доставляет.
Здравствуйте, minorlogic, Вы писали:
F>>из отдельных гуёв я бы порекомендовал gitg. достаточно наглядный. M>Спасибо , может руки дойдут. А про source tree что скажете ?
ничего не могу сказать, т.к. хг я активно не использую. тем более под виндой, тем более в гуях. я в основнов в консоли всё делаю, к гуям обращаюсь лишь изредка за наглядностью.
то, что я использую обычно в работе, примерно аналогично в хг и гите. от stash'а до слияния коммитов.
для полноценной работы нужно команд/действий 5 всего знать. в консоли это проще, т.к. в гуях ещё надо попривыкнуть к "оригинальному" переводу знакомых фич.
Здравствуйте, minorlogic, Вы писали:
F>>тебе надо 2-3 достаточно скромных по объёму главы M> я уже писал , это бесконечно большие затраты по сравнению с нормальным клиентом. А в командной строке я ковырялся , ибо не было другого выхода. Удовольствия это мне не доставляет.
я тут категорически несогласен. и вот почему.
раньше я использовал гуёвые клиенты для гита, хг(через eclipse) и svn. всё вроде бы неплохо, жить можно. но потом случилось так, что стал работать только под линухом, и, например, хороших svn клиентов там толком и не было(всё, что мог, перепробовал). как раз свой собственный перевод знакомых фич, непонятная логика гуёв и т.п.. тут-то и пришлось переползать в консоль.
и я понял, что удобство использования консольного клиента зависит в основном от скорости печати и настроенного автокомплита. и даже с быстрыми пальцами без автокомплита больно. всё дело в нём
Здравствуйте, neFormal, Вы писали:
F>ничего не могу сказать, т.к. хг я активно не использую.
забавно. в заголовке сайта написано, что клиент hg и git, а на странице только git.
впрочем, для гита я его тоже не использовал. вот у idea хороший гуй. процентов эдак на 80 может быть, т.к. есть к чему придраться.
Здравствуйте, ., Вы писали:
.>А кто нибудь может рассказать о Mercurial как он устроен, что там внутри творится?
neFormal, а можно как-нибудь объяснить за что минус?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, minorlogic, Вы писали:
M>Я перечислил задачи которые не смог решить в стандартной клиенте. Я скачал клиент от GIThub для мака и винды. Как в них в них сделать перечисленные действия ? или укажите другой клиент который все это делает. M>Комманд лайн не предлагать, за убогостью самой концепции.
Здравствуйте, minorlogic, Вы писали:
M>Первое впечатление о GIT, кусок Г. Не позволяет прозрачно отследить историю изменения файла. Родной клиент GIT это каждый коммит == русская рулетка.
Курить GitExtensions. В нём всё что надо. Есть куча плагинов к студии с прикольными фичамими типа отмены части изменения файла.
... << RSDN@Home 1.2.0 alpha 5 rev. 69>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, alexraynepe196, Вы писали:
A>меркуриал в теории имеет средства синхронизации с свн, на практике они походу работают только под линями, а под венду чтобы соотвествующий плагин поставить надо попотеть.
Ставишь тортилу, ставишь плагин (hg clone http://bitbucket.org/durin42/hgsubversion/ hgsubversion), идешь в настройки меркуриала и добавляешь
[extensions]
hgsubversion = path/to/hgsubversion
После этого усе работает
Правда, только со "стандартными" лайоутами svn-репов. У нас был нестандартный, чтоб потянуть историю, ветки и теги, пришлось писать свой конвертер...
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, MaLS, Вы писали:
MLS>>Знаю, тема много раз подымалась. Но нужна более свежее мнение по поводу выбора в использовании Git или Mercurial.
N>За git, по следующим причинам: N>1. Некоторые чрезвычайно удобные фишки, которые в конкурентах отсутствуют, в первую очередь это отдельное понятие "индекса", которое на порядки упрощает действия типа "я тут пол-файла наменял, разбираясь в этой хрени, а теперь мне это надо логически разделить на десять разных коммитов, причём часть действий пока не отправлять, потому что не уверен, а некоторые вообще только мои локальные хаки, их тем более не отправлять".
хз, что такое индекс, в меркуриаловской торитиле при коммите можно расставить галки напротив каждого куска в дифе файла, будут закоммичены только выбранные N>Аналогично, переформатирование предварительно сложенного локально набора коммитов перед их отправкой вверх — помогает предельно просто и ясно разделить разные изменения по ролям и сделать каждое из них однозначным и легко понятным.
Не проблема на меркуриале, есть histedit и mq
Здравствуйте, enji, Вы писали:
MLS>>>Знаю, тема много раз подымалась. Но нужна более свежее мнение по поводу выбора в использовании Git или Mercurial.
N>>За git, по следующим причинам: N>>1. Некоторые чрезвычайно удобные фишки, которые в конкурентах отсутствуют, в первую очередь это отдельное понятие "индекса", которое на порядки упрощает действия типа "я тут пол-файла наменял, разбираясь в этой хрени, а теперь мне это надо логически разделить на десять разных коммитов, причём часть действий пока не отправлять, потому что не уверен, а некоторые вообще только мои локальные хаки, их тем более не отправлять".
E>хз, что такое индекс, в меркуриаловской торитиле при коммите можно расставить галки напротив каждого куска в дифе файла, будут закоммичены только выбранные
То в тортилле, а в git это можно любым средством. При этом можно ещё и править их по смыслу, если нужно. add-interactive в этом смысле чрезвычайно мощное средство.
N>>Аналогично, переформатирование предварительно сложенного локально набора коммитов перед их отправкой вверх — помогает предельно просто и ясно разделить разные изменения по ролям и сделать каждое из них однозначным и легко понятным. E>Не проблема на меркуриале, есть histedit и mq
Тоже хорошо, но интересно, какой набор возможностей присутствует в этом случае. Например, перестановка коммитов? Слияние и разделение? Редактирование промежуточного? Исполнение команды на каждый коммит? Спрямление истории из многоветочной в одну прямую ветку?
Здравствуйте, netch80, Вы писали:
N>То в тортилле, а в git это можно любым средством. При этом можно ещё и править их по смыслу, если нужно. add-interactive в этом смысле чрезвычайно мощное средство.
Править прамо в окне тортилы нельзя, но в некоторых просмотрщиках дифов — можно. Возможно, дифы можно как-то и в консоли выбирать, но я за ненадобностью не разбирался.
E>>Не проблема на меркуриале, есть histedit и mq
N>Тоже хорошо, но интересно, какой набор возможностей присутствует в этом случае. N>Например, перестановка коммитов?
да N>Слияние
да N>и разделение?
явно — нет, но с помощью mq можно организовать N>Редактирование промежуточного?
да N>Исполнение команды на каждый коммит?
хз, не интересовался. Подозреваю что несложно прикрутить самому N>Спрямление истории из многоветочной в одну прямую ветку?
да, rebase
Если нам не помогут, то мы тоже никого не пощадим.
