Здравствуйте, Dair, Вы писали:
D>Здравствуйте, netch80, Вы писали: D>>> path/to/another/source.cpp D>>> path/to/another/source.h D>>>Please, commit your changes or stash them before you can merge. D>>>Aborting
N>>Ага. Вот на этой точке как раз надо было остановиться и разобраться, откуда такое возникло, а что оно не смогло, явно сказало. N>>Если эти локальные изменения были до rebase pull, то надо было тут выполнить stash и только после этого продолжать. И после всего pull — сделать stash pop и объединять новые изменения.
D>Дело в том, что эти файлы я не трогал. Вообще.
Значит, оно выделило как-то эти файлы именно в результате процесса rebase. Тогда надо было посмотреть, что за изменения, и закоммитить их или отменить.
N>>Вообще тут странно вот что — по умолчанию оно запрещает делать rebase при любых локальных изменениях файлов, то есть оно вообще не вошло бы в такой процесс, потребовав stash до запуска rebase pull. Это какие-то локальные настройки, что оно проигнорировало запрет? Что за версия git? D>2.6.0
Интересно. Я думаю, что пример воспроизведения этой ситуации будет полезен как problem report.
D>Тут есть предыстория. Я и был в ветке. Закончил, вливаюсь в develop.
D>тут я в ветке my_branch D>commit D>checkout develop D>pull D>merge my_branch D>(разрешение конфликтов) D>add D>add D>add D>commit
Не так важно, если собственно перед pull+rebase было чистое состояние, без локальных правок.
D>Тут в develop другие парни влили ещё два файла из заведомо других каталогов, push не прошёл. D>Решил, что уже тут надо делать rebase. Ну и вот.
То есть было переключение от попытки merge на попытку rebase, от того, что пришло много других изменений?
Хм... вот это случай, когда методы его слияния могли и поломаться. Само по себе появление файлов, которые вдруг стали локально изменены, является признаком в пользу такой гипотезы.
В таком случае варианты — попробовать другой алгоритм слияния (там несколько на выбор),
наконец, если оно дало изменённые, просто исправить эти изменения и закоммитить.
В любом случае, переключение на rebase вместо предыдущего merge это опасная операция.
(Таки в первой критике я был заметно прав — именно опасная операция, не названная в исходном рассказе, послужила причиной поломки. Лучше было это рассказать с самого начала.)
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>С трудом верится, особенно вспоминая жёсткие roundtrip'ы при работе с SVN, даже на мелких репозиториях в пару сотен коммитов. Но хорошо если действительно так. EP>Я думал там тормоза принципиальные, из-за архитектуры.
Перепроверил, взял папку, которая редко менялась. История за четыре года выгреблась секунд за 10.
EP>Но, это же переход на старую ревизию или ветку может быть очень долгим, так? Например в целях поиска коммита внёсшего баг, а-ля git bisect.
Неа. Если чекаут уже сделан — минуту-две, это на относительно свежие ветки. На старые, там где несколько десятков тысяч файлов перекачать приходится — да, минут десять может занять.
Если надо в нескольких ветках одновременно работать, то проще всего сделать пару копий, одна — для основной разработки, вторая — для отрезания релизов/воспроизведения багов и тд и тп.
EP>Например в целях поиска коммита внёсшего баг, а-ля git bisect.
Вот ни разу так не приходилось извращаться. Blame или просмотра истории хватает за глаза.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>А как же скорость? Например log или blame?
Если разработка идет в сети с нормальным каналом, то нет проблем. Я бы даже сказал что переходя на Git с SVN расчитывал увидеть все те сверхзвуковые "чудеса", что обычно описывают в сравнении с SVN. Их не случилось. Да чуть быстрее клонирование (checkout), ну разница порядка в одном 15 сек, в другом 13. Ветки да, шустрее. На Git в основном перешли из за того, что так и не смогли осилить ветки в SVN, а Visual Studio дает встроенную поддержку и не заставляет особо вникать в нюансы.
P.S.
А еще врут что Git репозитории компактнее SVN репозиториев. Они, по крайней мере у нас, больше.
P.P.S.
Возможно конечно что у нас просто не показательные репозитории. Самый сейчас большой порядка 3000 коммитов.
Здравствуйте, Mazenrab, Вы писали:
EP>>А как же скорость? Например log или blame? M>Если разработка идет в сети с нормальным каналом, то нет проблем.
От меня SVN находился на расстоянии долгих roundtrip'ов.
M>Я бы даже сказал что переходя на Git с SVN расчитывал увидеть все те сверхзвуковые "чудеса", что обычно описывают в сравнении с SVN. Их не случилось.
Я сначала использовал Git локально для удалённого SVN — поэтому могу сравнить напрямую. И как раз были сверхзвуковые чудеса — log -p и blame стали моментальными — это качественный переход, я их стал использовать на порядки чаще чем при непосредственно SVN.
Сейчас попробовал сделать поиск по всем diff'ам в репозитории на десяток тысяч коммитов — всего 2 минуты!
И конечно же работая над фичами локально я мог использовать Git'овские ветки, даже при основном SVN — это удобно.
M>P.S. M>А еще врут что Git репозитории компактнее SVN репозиториев. Они, по крайней мере у нас, больше.
ЕМНИП, у меня локальный Git репозиторий (со всеми коммитами!), был меньше чем локальный checkout SVN.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>И конечно же работая над фичами локально я мог использовать Git'овские ветки, даже при основном SVN — это удобно.
У меня когда-то такой бутерброд был очень выгоден при CVS наверху
EP>ЕМНИП, у меня локальный Git репозиторий (со всеми коммитами!), был меньше чем локальный checkout SVN.
При малой истории и большом объёме рабочей копии это очевидное следствие того, что SVN хранит в pristine/ неизменённую копию каждого файла согласно текущей версии, а Git сжимает их.
А еще я умудрился сломать локальный репозиторий в гите буквально на второй день Причем что с ним до сих пор не понимаю. Гит говорил что вообще все файлы в репозитории модифицированны. При этом при побайтовом сравнении с предыдущим коммитом разницы не было.
Здравствуйте, Mazenrab, Вы писали:
M> А еще я умудрился сломать локальный репозиторий в гите буквально на второй день Причем что с ним до сих пор не понимаю. Гит говорил что вообще все файлы в репозитории модифицированны. При этом при побайтовом сравнении с предыдущим коммитом разницы не было.
Здравствуйте, Нахлобуч, Вы писали:
S>>Или использовать ui-инструменты, они хоть предупреждают о возможных косяках, или страдать. Н>...или взять Mercurial
Не помогает
В нём тоже есть инструменты редактирования истории. Если штатных мало, можно других доставить. Я так пару раз терял коммиты, причём из GUI. Виноват я конечно, а не Mercurial.
Здравствуйте, alex_public, Вы писали:
_>>>Mercurial лучше — абсолютно те же самые технические возможности, но при этом более удобно. N>>Нет, в разы менее удобно, идиотская логика на каждом углу. И не надо возражать, этот холивар давно надоел и я всё равно не соглашусь, ничего лучшего за последние лет 5 в меркуриале не случилось. _>Ну естественно если речь не о технических аргументах, а о вере, то попытки убедить бесполезны) Хотя это всё как раз по профилю данного форума. )))
Технические аргументы уже были. http://rsdn.ru/forum/tools/5821081.flat#5821081
Здравствуйте, ·, Вы писали:
_>>Ну естественно если речь не о технических аргументах, а о вере, то попытки убедить бесполезны) Хотя это всё как раз по профилю данного форума. ))) ·>Технические аргументы уже были. http://rsdn.ru/forum/tools/5821081.flat#5821081
Со временем уровень технологических возможностей этих конкурирующих систем (да и не только этих двух, просто они самые известные, а там на самом деле ещё несколько полноценный аналогов есть) только выравнивается (у mercurial же в прошлом был свой аналогичный список). А вот уровень заложенного удобства сохраняется... Разве что GUI для git чуть подрос до уровня аналогичного в mercurial. Но GUI — это не всем интересно.
Здравствуйте, alex_public, Вы писали:
_>>>Ну естественно если речь не о технических аргументах, а о вере, то попытки убедить бесполезны) Хотя это всё как раз по профилю данного форума. ))) _>·>Технические аргументы уже были. http://rsdn.ru/forum/tools/5821081.flat#5821081
_>·>Интересно изменилось ли что с тех пор?
_>Со временем уровень технологических возможностей этих конкурирующих систем (да и не только этих двух, просто они самые известные, а там на самом деле ещё несколько полноценный аналогов есть) только выравнивается (у mercurial же в прошлом был свой аналогичный список).
Можно увидеть этот список? Единственное, что могу припомнить, git плоховато работал на win, ибо изначально разрабатывался unix-only, когда как hg изначально задумывался кроссплатформенным.
_>А вот уровень заложенного удобства сохраняется... Разве что GUI для git чуть подрос до уровня аналогичного в mercurial. Но GUI — это не всем интересно.
Фундамент git — лучше. Вместо традиционного (тянущееся начиная с rcs?) append-only лога, да ещё и per-file используется принципиально другой подход, ассоциативное object-хранилище.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
_>>Со временем уровень технологических возможностей этих конкурирующих систем (да и не только этих двух, просто они самые известные, а там на самом деле ещё несколько полноценный аналогов есть) только выравнивается (у mercurial же в прошлом был свой аналогичный список). ·>Можно увидеть этот список? Единственное, что могу припомнить, git плоховато работал на win, ибо изначально разрабатывался unix-only, когда как hg изначально задумывался кроссплатформенным.
Ну можно посмотреть по соответствующим спорам тех времён. Мне сейчас лень искать соответствующие флеймные ветки на форуме. Сам я такое не составлял, а только видел. Однако я могу перечислить некоторые вещи, которые просто помню (т.е. это будет не результат какого-то анализа в виде полного списка, а просто некий случайный набор проблем) по своему опыту:
— проблема с сохранением истории в git. В mercurial всегда можно найти источник проблемы, а в git'е далеко не всегда.
— возможность получить гигабайтный патч при слияние веток в git.
— проблема с кодировками в путях. Надеюсь хоть это уже исправили? )
— слабая работа с хуками и другими расширениями в git
— заковыристая система команд (субъективно конечно, дело вкуса, но такое мнение можно частенько услышать) в сравнение с другими dcvs.
·>Фундамент git — лучше. Вместо традиционного (тянущееся начиная с rcs?) append-only лога, да ещё и per-file используется принципиально другой подход, ассоциативное object-хранилище.
Это смотря на каком уровне смотреть. Формально да, одно хранит дифы, а другое вроде как сами файлы. Но фокус в том, что если бы оно реально хранило сами файлы, то размер хранилища был бы нереальным. Так что в итоге и второе хранит дифы, просто они там для сжатия, а не для идеологии.
Здравствуйте, alex_public, Вы писали:
_>- проблема с сохранением истории в git. В mercurial всегда можно найти источник проблемы, а в git'е далеко не всегда.
Совершенно непонятно. Что есть "проблема" в данном случае? Источник конкретного изменения? Ищется по истории без проблем, на каждую версию строчки или бинаря есть id коммита, из которого она возникла. Развилки? Они существуют во всех DVCS.
_>- возможность получить гигабайтный патч при слияние веток в git.
Любое слияние отражает дифф с исходными версиями. "Гигабайтный патч" означает сведение существенно несовместимых вариантов. Проблема общая для всех DVCS, но в случае Git имеем один из лучших, испытанный на практике, мержер.
_>- проблема с кодировками в путях. Надеюсь хоть это уже исправили? )
Этой проблемы никогда не было у Git. Имя объекта это NUL-terminated строка байт, даже понимание этого имени как пути уже является свойством внешнего слоя, а не ядра.
Если она есть у Windows, то это проблема кодировок Windows и конкретных реализаций Git клиента. Бардак с кодировками (ANSI/OEM/Unicode) в Windows такой, что я всегда забывал, что в них где, через 5 минут после того, как разобрался.
_>- слабая работа с хуками и другими расширениями в git
Мне не с чем сравнивать, но вопрос в том, насколько реально нужна "сильная" в твоём понимании, и насколько она логична.
_>- заковыристая система команд (субъективно конечно, дело вкуса, но такое мнение можно частенько услышать) в сравнение с другими dcvs.
Система команд очень удобна из логики "если действие с базовой концепцией X, команда будет называться X".
Вот поэтому я и пользуюсь Mercurial. Есть свои проблемы, в частности уже пару раз ломал репозиторий, что приходилось пересоздавать с нуля (хотя может можно было и починить, нз), но в целом ощущения от использования этой VCS очень приятные. Всё чисто, понятно и логично.
Пользоваться меркуриалов по сравнению с гитом всё равно что программировать на питоне вместо си.
Хайпа вокруг гита не понимаю. Ладно самое красноглазное подмножество линуксоидов-ядерщиков в своём мирке юзают что им удобнее (белоглазые же линуксоиды, я слышал, почётно восседают на bazaar), но гит с хрустом начинают жевать маководы и виндузятники (к коим отношусь и я), с улыбкой гарольда-скрывающего-боль нахваливая и зазывая всех присоединиться к их клёвым проектам, худо-бедно выложенным на модный нынче гитхаб (но которые почему-то так и не получают должной популярности), я в недоумении развожу руками.
