Здравствуйте, ·, Вы писали:
_>>·>Cинхронизируй, разрешаю. _>>Каким образом? ) ·>Ну например просто "git stash pop", "git stash" поверх последних изменений коллег.
И каким образом то оно разойдётся по другим репозиториям? )
_>>Описания ревизий в Mercurial неизменные (ну если не считать редактирования истории с помощью ненормальных расширений), так же как и имена веток. ) ·>Т.е. пофиксить орфографическую ошибку в сообщении или добавить номер тикета не выйдет без заморочек? ·>Тебе просто кажется что они неизменные, промыли тебе мозг CVCS наследием. Ревизии в любой DVCS можно отредактировать всегда — сгенерить патчи, грохнуть локальный репозиторий, создать клон снова, чуть подредактировать и зааплаить патчи. Вопрос в другом — реализовать эту возможность нормально, для людей, как в git, или ненормально, через жо расширения, как в hg.
Если мы говорим об откате последних ревизий (несинхронизированных), то естественно это делается без проблем. Правда это будет не редактированием ревизии, а просто созданием её заново, но это не суть. Я же говорил о редактирование описания ревизии где-то в глубине уже устоявшейся истории... )
Здравствуйте, ·, Вы писали:
_>>Т.е. нет состояния с тремя головами в каждом репозитории. А я может хочу просто сделать 2 альтернативные ревизии и заслать их народу (у которого тоже там какие-то свои ревизии есть), а слияния уже может другой кто-то будет производить. Соответственно у тебя поэтому и картинки из пункта 3 получить нельзя. ·>Да возьми ты гит и поиграйся. ·>Картинка будет та же, но ветки будут не безымянные отростки, а с символьными ссылками (ака бранчами).
Во-втором репозитории я действительно вижу у тебя 3 головы: master, origin/master, clones_branch. А как выглядят 3 головы в изначальном репозитории?
_>>Далее, прямо по твоему набору команд (в любой вариации) видно, что они сильно не симметричны относительно ревизий A и B. Т.е. вот прямо из твоих примеров не видно как собственно можно направить на слияние с основной веткой ревизию B (напоминаю, что точка принятия решения, какую ревизию мы выбираем для дальнейшей работы в основной ветке должна быть уже после фиксации обеих ревизий). ·>Она несимметрична только именами бранча. В моём скрипте бранчи будут master и clones_branch
Да, и они не симметричны, т.к. master настроен на синхронизацию с origin/master. Т.е. для создания реального аналога решения в Mercurial, тебе надо будет создать 2 дополнительные ветки при развилке, а не помещать change2А в master.
_>>Ну и наконец, хотелось бы всё же реального аналога моих пунктов с полным набором всех необходимых команд (редактирование тестового файла пропускаем естественно), чтобы можно было количественно (ну хотя бы по числу необходимых команд) сравнить удобство работы с обеими системами. ·>Само разветвление я тебе показал. Команд столько же. Для слияния добавятся pull или merge. Команд будет столько же.
Ну так ты же очевидно не все команды показываешь. Не видно ни git add, ни git branch и т.п.
·>Разница с синхронизацией может быть выражена в том, что Tester может не публиковать свою локальную ревизию в начальный репо, которую он не вмержил в master. Т.е. если Tester решил замержить change2B, то change2A никогда не появится в начальном репозитории (и естественно не будет видна в графе).
Вообще то это требование было указано прямо в изначальном условие задачи, что альтернативная реализация должна быть сохранена в репозитории и доступна всем в будущем.
Здравствуйте, alex_public, Вы писали:
_>>>·>Cинхронизируй, разрешаю. _>>>Каким образом? ) _>·>Ну например просто "git stash pop", "git stash" поверх последних изменений коллег. _>И каким образом то оно разойдётся по другим репозиториям? )
Да как обычно, делаешь push. Но обычно stash всё-таки локальный, если хочешь куда-то отправлять — удобнее завести под это ветку.
_>·>Т.е. пофиксить орфографическую ошибку в сообщении или добавить номер тикета не выйдет без заморочек? _>·>Тебе просто кажется что они неизменные, промыли тебе мозг CVCS наследием. Ревизии в любой DVCS можно отредактировать всегда — сгенерить патчи, грохнуть локальный репозиторий, создать клон снова, чуть подредактировать и зааплаить патчи. Вопрос в другом — реализовать эту возможность нормально, для людей, как в git, или ненормально, через жо расширения, как в hg. _>Если мы говорим об откате последних ревизий (несинхронизированных), то естественно это делается без проблем. Правда это будет не редактированием ревизии, а просто созданием её заново, но это не суть. Я же говорил о редактирование описания ревизии где-то в глубине уже устоявшейся истории... )
Несинхронизованных с чем? Ты не забыл, что у нас DVCS?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, alex_public, Вы писали:
_>>>Т.е. нет состояния с тремя головами в каждом репозитории. А я может хочу просто сделать 2 альтернативные ревизии и заслать их народу (у которого тоже там какие-то свои ревизии есть), а слияния уже может другой кто-то будет производить. Соответственно у тебя поэтому и картинки из пункта 3 получить нельзя. _>·>Да возьми ты гит и поиграйся. _>·>Картинка будет та же, но ветки будут не безымянные отростки, а с символьными ссылками (ака бранчами). _>Во-втором репозитории я действительно вижу у тебя 3 головы: master, origin/master, clones_branch. А как выглядят 3 головы в изначальном репозитории?
Как запушишь, так и будет. Если сделать в клоне
git push origin master:clones_master clones_branch
то в изначальном будет 3 головы master, clones_master, clones_branch, структура графа — идентична.
_>>>Далее, прямо по твоему набору команд (в любой вариации) видно, что они сильно не симметричны относительно ревизий A и B. Т.е. вот прямо из твоих примеров не видно как собственно можно направить на слияние с основной веткой ревизию B (напоминаю, что точка принятия решения, какую ревизию мы выбираем для дальнейшей работы в основной ветке должна быть уже после фиксации обеих ревизий). _>·>Она несимметрична только именами бранча. В моём скрипте бранчи будут master и clones_branch _>Да, и они не симметричны, т.к. master настроен на синхронизацию с origin/master. Т.е. для создания реального аналога решения в Mercurial, тебе надо будет создать 2 дополнительные ветки при развилке, а не помещать change2А в master.
Не _надо_, _можно_.
Трекинг влияет только на дефолтные значения (т.е. выполняешь команду без явного указания имён веток) для push/pull и на рисование статуса о состоянии синхронизации между ветками.
_>>>Ну и наконец, хотелось бы всё же реального аналога моих пунктов с полным набором всех необходимых команд (редактирование тестового файла пропускаем естественно), чтобы можно было количественно (ну хотя бы по числу необходимых команд) сравнить удобство работы с обеими системами. _>·>Само разветвление я тебе показал. Команд столько же. Для слияния добавятся pull или merge. Команд будет столько же. _>Ну так ты же очевидно не все команды показываешь. Не видно ни git add, ни git branch и т.п.
add тут не нуже, если файлы не добавляешь/удаляешь (можно писать "commit -a").
branch тут не нужен. Имена веток можно указывать в checkout/push/pull.
_>·>Разница с синхронизацией может быть выражена в том, что Tester может не публиковать свою локальную ревизию в начальный репо, которую он не вмержил в master. Т.е. если Tester решил замержить change2B, то change2A никогда не появится в начальном репозитории (и естественно не будет видна в графе). _>Вообще то это требование было указано прямо в изначальном условие задачи, что альтернативная реализация должна быть сохранена в репозитории и доступна всем в будущем.
Кому _всем_??! Мы всё ещё о DVCS?
Это требование выполнилось для пары "клон" и "клон клона". Но не выполнилось для "клон" и "изначальный".
Даже создавая новые клоны можно выбрать какие ветки тянуть.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
_>>Во-втором репозитории я действительно вижу у тебя 3 головы: master, origin/master, clones_branch. А как выглядят 3 головы в изначальном репозитории? ·>Как запушишь, так и будет. Если сделать в клоне ·>git push origin master:clones_master clones_branch ·>то в изначальном будет 3 головы master, clones_master, clones_branch, структура графа — идентична.
Ага... Только вот такого варианта то у тебя в реализации как раз и не было. Ни в одной из множества представленных тобой. ))) Более того, для реального удобства при использование git тут придётся делать 2 дополнительные ветки (кроме master) во втором репозитории. Тогда git более менее справится с задачей. )
_>>Да, и они не симметричны, т.к. master настроен на синхронизацию с origin/master. Т.е. для создания реального аналога решения в Mercurial, тебе надо будет создать 2 дополнительные ветки при развилке, а не помещать change2А в master. ·>Не _надо_, _можно_. ·>Трекинг влияет только на дефолтные значения (т.е. выполняешь команду без явного указания имён веток) для push/pull и на рисование статуса о состоянии синхронизации между ветками.
Дело не только в трекинге, но и в распространение всех ревизий среди всех коллег. )
_>>Ну так ты же очевидно не все команды показываешь. Не видно ни git add, ни git branch и т.п. ·>add тут не нуже, если файлы не добавляешь/удаляешь (можно писать "commit -a"). ·>branch тут не нужен. Имена веток можно указывать в checkout/push/pull.
Ну так может ты бы тогда всё написал формализованно, как у меня по пунктам, чтобы могли реально оценить? ) Вот у меня на весь процесс (вне зависимости от итогового выбора варианта A или B) потребовалось ровно 12 команд hg (не считая hg log -G для проверки результата).
_>>·>Разница с синхронизацией может быть выражена в том, что Tester может не публиковать свою локальную ревизию в начальный репо, которую он не вмержил в master. Т.е. если Tester решил замержить change2B, то change2A никогда не появится в начальном репозитории (и естественно не будет видна в графе). _>>Вообще то это требование было указано прямо в изначальном условие задачи, что альтернативная реализация должна быть сохранена в репозитории и доступна всем в будущем. ·>Кому _всем_??! Мы всё ещё о DVCS?
Ещё раз, я ставлю задачу. Не в терминах VCS, а просто словами: я хочу, чтобы мои два альтернативных решения могли увидеть все мои коллеги по команде. И прямо сейчас (когда ещё не произошло выбора варианта) и в любой момент в будущем (когда выбор уже произошёл и одно из решений остаётся альтернативным отростком). Ты считаешь что это какие-то очень странные требования в работе команды или нет? ) И Git способен их удобно реализовать или нет? ) Mercurial, если что, способен...
·>Это требование выполнилось для пары "клон" и "клон клона". Но не выполнилось для "клон" и "изначальный". ·>Даже создавая новые клоны можно выбрать какие ветки тянуть.
Хыхы, что это ещё за неравноправие между разными репозиториями? ) Это точно DVCS? )))
Здравствуйте, alex_public, Вы писали:
_>·>Как запушишь, так и будет. Если сделать в клоне _>·>git push origin master:clones_master clones_branch _>·>то в изначальном будет 3 головы master, clones_master, clones_branch, структура графа — идентична. _>Ага... Только вот такого варианта то у тебя в реализации как раз и не было. Ни в одной из множества представленных тобой. ))) Более того, для реального удобства при использование git тут придётся делать 2 дополнительные ветки (кроме master) во втором репозитории. Тогда git более менее справится с задачей. )
Да просто одно и то же можно сделать разными способами. Можно делать 2 дополнительные ветки (кроме мастер), а можно вообще обойтись нулём локальных веток (даже master грохнуть).
С локальными ветками обычно — удобнее.
_>·>Не _надо_, _можно_. _>·>Трекинг влияет только на дефолтные значения (т.е. выполняешь команду без явного указания имён веток) для push/pull и на рисование статуса о состоянии синхронизации между ветками. _>Дело не только в трекинге, но и в распространение всех ревизий среди всех коллег. )
Локальные ветки на распределение не влияют. Влияет то, куда и как ты пушишь или как ты хочешь чтобы из твоего репо фетчили.
_>>>Ну так ты же очевидно не все команды показываешь. Не видно ни git add, ни git branch и т.п. _>·>add тут не нуже, если файлы не добавляешь/удаляешь (можно писать "commit -a"). _>·>branch тут не нужен. Имена веток можно указывать в checkout/push/pull. _>Ну так может ты бы тогда всё написал формализованно, как у меня по пунктам, чтобы могли реально оценить? ) Вот у меня на весь процесс (вне зависимости от итогового выбора варианта A или B) потребовалось ровно 12 команд hg (не считая hg log -G для проверки результата).
вариант без использования локальных веток:
git clone initialRepo clonedRepo
cd clonedRepo
...
git checkout origin/changeA // or changeB
git pull origin master // merging changes made in initialRepo's master into chosen changeA or changeB
... complete merge if conflicts...
git push origin HEAD:master
_>>>·>Разница с синхронизацией может быть выражена в том, что Tester может не публиковать свою локальную ревизию в начальный репо, которую он не вмержил в master. Т.е. если Tester решил замержить change2B, то change2A никогда не появится в начальном репозитории (и естественно не будет видна в графе). _>>>Вообще то это требование было указано прямо в изначальном условие задачи, что альтернативная реализация должна быть сохранена в репозитории и доступна всем в будущем. _>·>Кому _всем_??! Мы всё ещё о DVCS? _>Ещё раз, я ставлю задачу. Не в терминах VCS, а просто словами: я хочу, чтобы мои два альтернативных решения могли увидеть все мои коллеги по команде. И прямо сейчас (когда ещё не произошло выбора варианта) и в любой момент в будущем (когда выбор уже произошёл и одно из решений остаётся альтернативным отростком). Ты считаешь что это какие-то очень странные требования в работе команды или нет? ) И Git способен их удобно реализовать или нет? ) Mercurial, если что, способен...
Да откуда я знаю что у тебя за команда и как твои коллеги работают. Если у вас централизованнный подход, то просто пуш свои альтернативные решения в центральный репо, коллеги, _если захотят_, их вытянут. Заставить можешь только административными мерами.
_>·>Это требование выполнилось для пары "клон" и "клон клона". Но не выполнилось для "клон" и "изначальный". _>·>Даже создавая новые клоны можно выбрать какие ветки тянуть. _>Хыхы, что это ещё за неравноправие между разными репозиториями? ) Это точно DVCS? )))
Хм.. Я бы не стал требовать равноправие между моим репозиторием и репозиторием Торвальдса, который собирает официальный релиз ядра.
А у вас к комманде коммунизм? Кто что хочет, тот и меняет, без всяких ревью — пуш-пуш и в продакшен?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, alex_public, Вы писали:
_>Ну так может ты бы тогда всё написал формализованно, как у меня по пунктам, чтобы могли реально оценить? ) Вот у меня на весь процесс (вне зависимости от итогового выбора варианта A или B) потребовалось ровно 12 команд hg (не считая hg log -G для проверки результата).
Вариант с локальными ветками:
Здравствуйте, ·, Вы писали:
_>>Дело не только в трекинге, но и в распространение всех ревизий среди всех коллег. ) ·>Локальные ветки на распределение не влияют. Влияет то, куда и как ты пушишь или как ты хочешь чтобы из твоего репо фетчили.
Нуу не суть локальные или в другом репозитории. Главное, что для решения этой задачки в Git, надо вводить две новые именованные ветки. )
_>>Ну так может ты бы тогда всё написал формализованно, как у меня по пунктам, чтобы могли реально оценить? ) Вот у меня на весь процесс (вне зависимости от итогового выбора варианта A или B) потребовалось ровно 12 команд hg (не считая hg log -G для проверки результата). ·>вариант без использования локальных веток: ·>git clone initialRepo clonedRepo ·>cd clonedRepo
·>git checkout origin/master ·>...do stuff A ·>git commit ... ·>git push origin HEAD:changeA
·>git checkout origin/master ·>...do stuff B ·>git commit ... ·>git push origin HEAD:changeB
·>... ·>git checkout origin/changeA // or changeB ·>git pull origin master // merging changes made in initialRepo's master into chosen changeA or changeB ·>... complete merge if conflicts... ·>git push origin HEAD:master
Вооооооооот, наконец то правильный вариант! Это реально реализует в git требуемый сценарий и при этом создаёт одинаковые репозитории после синхронизации.
Что касается числа команд, то ты тут забыл указать код создания изначального репозитория (он у меня тоже считался, хотя можно и выкинуть это) и код добавления ревизии change1 в изначальный репозиторий (которое уже после клонирования). Понятно, что это всё очевидные вещи, но для подсчёта числа команд всё должно быть честно. ) Так вот если добавить недостающее в твой пример и посчитать, то получается, что на данном сценарии git требует процентов на 20 больше команд чем Mercurial. Плюс приходится придумывать имена для веток по каждому чиху.
Т.е. в итоге мы пришли к тому, что я писал в самом начале дискуссии. Обе системы позволяют без проблем реализовывать любые сценарии. Но Mercurial на части сценариев выглядит удобнее (а на остальных одинаково).
_>>Хыхы, что это ещё за неравноправие между разными репозиториями? ) Это точно DVCS? ))) ·>Хм.. Я бы не стал требовать равноправие между моим репозиторием и репозиторием Торвальдса, который собирает официальный релиз ядра. ·>А у вас к комманде коммунизм? Кто что хочет, тот и меняет, без всяких ревью — пуш-пуш и в продакшен?
Нуу ты не путай между техническим неравноправием и административным. )
Здравствуйте, alex_public, Вы писали:
_>>>Дело не только в трекинге, но и в распространение всех ревизий среди всех коллег. ) _>·>Локальные ветки на распределение не влияют. Влияет то, куда и как ты пушишь или как ты хочешь чтобы из твоего репо фетчили. _>Нуу не суть локальные или в другом репозитории. Главное, что для решения этой задачки в Git, надо вводить две новые именованные ветки. )
Да. Но я не понимаю что в этом плохого. Единственная проблема — придумывать имена веток. Но если это так трудно, сделай однострочный скриптик для генерации случайных. Но этот подход, как в hg — не самый разумный, напоминает старые недобрые OnButton38Click в древних редакторах UI типа Visual Basic.
Ведь ветки не нужны самой системе, а они для человеков только.
_>Вооооооооот, наконец то правильный вариант! Это реально реализует в git требуемый сценарий и при этом создаёт одинаковые репозитории после синхронизации.
Так я и говорил, он аналогичен как в hg, только надо задавать имена веток.
_>Что касается числа команд, то ты тут забыл указать код создания изначального репозитория (он у меня тоже считался, хотя можно и выкинуть это) и код добавления ревизии change1 в изначальный репозиторий (которое уже после клонирования). Понятно, что это всё очевидные вещи, но для подсчёта числа команд всё должно быть честно. ) Так вот если добавить недостающее в твой пример и посчитать, то получается, что на данном сценарии git требует процентов на 20 больше команд чем Mercurial. Плюс приходится придумывать имена для веток по каждому чиху.
А откуда +20% взялось? Я ожидаю одинаковое число. Ты наверное посчитал разные push? так можно запушить несколько бранчей массово (git push --all, например).
_>Т.е. в итоге мы пришли к тому, что я писал в самом начале дискуссии. Обе системы позволяют без проблем реализовывать любые сценарии. Но Mercurial на части сценариев выглядит удобнее (а на остальных одинаково).
Даже hg up 1 не выглядит удобнее. В реальном репозитории не будет таких чисел, а скорее всего 5-6 циферок. Символьные имена гораздо лучше в боевых условиях.
Я вот даже stash стараюсь избегать, т.к. они нумеруются, хотя спасает то, что можно указать сообщение к стешу
git stash save "tried Weird Stuff, doesn't work because of foo"
Хотя это не сильно проще чем банальное
git checkout -b WeirdStuff && git commit -a "doesn't work because of foo" && git checkout —
_>·>Хм.. Я бы не стал требовать равноправие между моим репозиторием и репозиторием Торвальдса, который собирает официальный релиз ядра. _>·>А у вас к комманде коммунизм? Кто что хочет, тот и меняет, без всяких ревью — пуш-пуш и в продакшен? _>Нуу ты не путай между техническим неравноправием и административным. )
Технически все репозитории git во всём мире равноправны. Можно пушить/фетчить что угодно куда угодно.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
_>>Нуу не суть локальные или в другом репозитории. Главное, что для решения этой задачки в Git, надо вводить две новые именованные ветки. ) ·>Да. Но я не понимаю что в этом плохого. Единственная проблема — придумывать имена веток. Но если это так трудно, сделай однострочный скриптик для генерации случайных.
Ну да, можно такое. ) Но вот в Mercurial скриптик делать не надо — работает из коробки. )
·>Но этот подход, как в hg — не самый разумный, напоминает старые недобрые OnButton38Click в древних редакторах UI типа Visual Basic. ·>Ведь ветки не нужны самой системе, а они для человеков только.
Ты только не забывай, что подход Git'а с именованными ссылками в Mercurial тоже имеется. Плюс ещё третий вариант (тоже именованный, но по другому).
_>>Что касается числа команд, то ты тут забыл указать код создания изначального репозитория (он у меня тоже считался, хотя можно и выкинуть это) и код добавления ревизии change1 в изначальный репозиторий (которое уже после клонирования). Понятно, что это всё очевидные вещи, но для подсчёта числа команд всё должно быть честно. ) Так вот если добавить недостающее в твой пример и посчитать, то получается, что на данном сценарии git требует процентов на 20 больше команд чем Mercurial. Плюс приходится придумывать имена для веток по каждому чиху. ·>А откуда +20% взялось? Я ожидаю одинаковое число. Ты наверное посчитал разные push? так можно запушить несколько бранчей массово (git push --all, например).
Ну да, плюс там ещё в инициализации лишний add и в развилкe лишний checkout. Зато отдельной команды merge (как hg) не надо. Но в сумме выходит чуть больше Mercurial.
_>>Т.е. в итоге мы пришли к тому, что я писал в самом начале дискуссии. Обе системы позволяют без проблем реализовывать любые сценарии. Но Mercurial на части сценариев выглядит удобнее (а на остальных одинаково). ·>Даже hg up 1 не выглядит удобнее. В реальном репозитории не будет таких чисел, а скорее всего 5-6 циферок. Символьные имена гораздо лучше в боевых условиях.
Я уже выше писал, что если так хочется имён, то в Mercurial с этим проблем нет. ) Зато если не хочешь их, то в Git будет неудобно.
Здравствуйте, alexzz, Вы писали:
A>Брешет. Я не спец в hg (использую для домашних проектов), в git так вообще ноль, поэтому в дискуссию не лезу, но то что он описывает, я проделывал раз сто.
Хм, а каким образом было создано изменение 4:7add6f7ad80b? Мне пока в голову приходит только такой способ:
$ hg up -r 1
$ hg branch experimental
abort: a branch of the same name already exists
(use 'hg update' to switch to it)
Здравствуйте, alex_public, Вы писали:
_>>>Нуу не суть локальные или в другом репозитории. Главное, что для решения этой задачки в Git, надо вводить две новые именованные ветки. ) _>·>Да. Но я не понимаю что в этом плохого. Единственная проблема — придумывать имена веток. Но если это так трудно, сделай однострочный скриптик для генерации случайных. _>Ну да, можно такое. ) Но вот в Mercurial скриптик делать не надо — работает из коробки. )
В git это не работает из коробки, т.к. нафиг никому не надо, ибо провоцирует на неразумное поведение.
_>·>Но этот подход, как в hg — не самый разумный, напоминает старые недобрые OnButton38Click в древних редакторах UI типа Visual Basic. _>·>Ведь ветки не нужны самой системе, а они для человеков только. _>Ты только не забывай, что подход Git'а с именованными ссылками в Mercurial тоже имеется. Плюс ещё третий вариант (тоже именованный, но по другому).
Там имена ссылок глобальные, поэтому приходится думать более осторожно как и что называть.
_>·>А откуда +20% взялось? Я ожидаю одинаковое число. Ты наверное посчитал разные push? так можно запушить несколько бранчей массово (git push --all, например). _>Ну да, плюс там ещё в инициализации лишний add и в развилкe лишний checkout. Зато отдельной команды merge (как hg) не надо. Но в сумме выходит чуть больше Mercurial.
add лишний откуда? Новый файл нужно в обоих системах явно добавлять. А коммит всего это просто "git commit -a".
checkout-ов можно сделать ровно столько же — для соответствующих hg up. "merge" можно использовать из pull. Просто я для красоты привёл:
"merge changeA или changeB" — команда явно и точно показывает намерения что происходит.
_>·>Даже hg up 1 не выглядит удобнее. В реальном репозитории не будет таких чисел, а скорее всего 5-6 циферок. Символьные имена гораздо лучше в боевых условиях. _>Я уже выше писал, что если так хочется имён, то в Mercurial с этим проблем нет. )
Есть проблемы с глобальностью имёт.
_>Зато если не хочешь их, то в Git будет неудобно.
Да так же будет, если альяс написать. Правда лучше так не делать в реальных проектах.
Даже в доке это написано:
push will not allow creation of new heads at the destination, since multiple heads would make it unclear which head to use
...
Extra care should be taken with the -f/--force option, which will push all new heads on all branches, an action which will almost always cause confusion for collaborators.
Т.е. фича конечно настолько крутая и полезная, что в официальных доках явно говорят её не использовать.
Спрашиваетя зачем её сделали вообще? Чтобы выпендриваться на форумах, что можно вместо 30 команд обойтись всего лишь 29-ю?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, alex_public, Вы писали:
_>Так ты ветку experimental закрыл или нет? )
Да, конечно.
_>Хотя если не закрывать, то всё равно можно (параметр -f).
Вот оно как... Не знал про -f. Всегда думал, что "branches are permanent and global, did you want a bookmark?" означает именно существование ветки с экслюзивным правом на своё имя. Спасибо.
Здравствуйте, ·, Вы писали:
_>>·>Но этот подход, как в hg — не самый разумный, напоминает старые недобрые OnButton38Click в древних редакторах UI типа Visual Basic. _>>·>Ведь ветки не нужны самой системе, а они для человеков только. _>>Ты только не забывай, что подход Git'а с именованными ссылками в Mercurial тоже имеется. Плюс ещё третий вариант (тоже именованный, но по другому). ·>Там имена ссылок глобальные, поэтому приходится думать более осторожно как и что называть.
Вот мы сейчас только обсуждали сценарий и там по сути были глобальные ветки в Git. Ну да, ты конечно же можешь сказать, что и там можно было иметь разные имена в разных репозиториях (т.е. придумать 4 новых имени, вместо двух — вообще здорово), но на практике в таком сценарии никто подобного не стал бы делать.
_>>Ну да, плюс там ещё в инициализации лишний add и в развилкe лишний checkout. Зато отдельной команды merge (как hg) не надо. Но в сумме выходит чуть больше Mercurial. ·>add лишний откуда? Новый файл нужно в обоих системах явно добавлять. А коммит всего это просто "git commit -a".
Просто у Mercurial тоже есть свой commit -A. ))) Только он уже означает ещё и добавить/удалить автоматически все файлы в каталоге.
·>checkout-ов можно сделать ровно столько же — для соответствующих hg up. "merge" можно использовать из pull. Просто я для красоты привёл: ·>"merge changeA или changeB" — команда явно и точно показывает намерения что происходит.
Про merge — это же я как раз "в минус" mercurial сказал, т.к. в ней pull не делает автоматический merge. )))
Ну да, если checkоut'ов сделать столько же, то будет уже практически одинаковый результат. Только такой вариант подходит исключительно для сценария без локальных имён. А если захочется локальные имена, то будет уже длиннее.. )
_>>Зато если не хочешь их, то в Git будет неудобно. ·>Да так же будет, если альяс написать. Правда лучше так не делать в реальных проектах. ·>Даже в доке это написано: ·>
push will not allow creation of new heads at the destination, since multiple heads would make it unclear which head to use
·>...
·>Extra care should be taken with the -f/--force option, which will push all new heads on all branches, an action which will almost always cause confusion for collaborators.
·>Т.е. фича конечно настолько крутая и полезная, что в официальных доках явно говорят её не использовать. ·>Спрашиваетя зачем её сделали вообще? Чтобы выпендриваться на форумах, что можно вместо 30 команд обойтись всего лишь 29-ю?
Да, на практике чаще всего синхронизации после ветвления не делают (разве что реально надо посоветоваться с коллегами какой вариант выбрать), а синхронизируются только после слияния. Однако это по сути никак не меняет наш сценарий выше, т.к. в нём главным условием было сохранения в истории реализации альтернативного варианта.
Здравствуйте, alex_public, Вы писали:
_>>>Ты только не забывай, что подход Git'а с именованными ссылками в Mercurial тоже имеется. Плюс ещё третий вариант (тоже именованный, но по другому). _>·>Там имена ссылок глобальные, поэтому приходится думать более осторожно как и что называть. _>Вот мы сейчас только обсуждали сценарий и там по сути были глобальные ветки в Git. Ну да, ты конечно же можешь сказать, что и там можно было иметь разные имена в разных репозиториях (т.е. придумать 4 новых имени, вместо двух — вообще здорово), но на практике в таком сценарии никто подобного не стал бы делать.
Это как? Глобальных веток в git не бывает, даже со всякими сутями. Ты видимо что-то не понимаешь. Есть ветка в локальном репо, есть в ремотном, они _разные_, короткое имя (имя без префикса) может совпадать, но это ни к чему не обязывает.
_>>>Ну да, плюс там ещё в инициализации лишний add и в развилкe лишний checkout. Зато отдельной команды merge (как hg) не надо. Но в сумме выходит чуть больше Mercurial. _>·>add лишний откуда? Новый файл нужно в обоих системах явно добавлять. А коммит всего это просто "git commit -a". _>Просто у Mercurial тоже есть свой commit -A. ))) Только он уже означает ещё и добавить/удалить автоматически все файлы в каталоге.
А, понял. Гит не добавляет новые файлы с "commit -a". Просто сделано по-другому, не знаю почему именно так решили сделать, но это явно не техническое ограничение.
_>·>checkout-ов можно сделать ровно столько же — для соответствующих hg up. "merge" можно использовать из pull. Просто я для красоты привёл: _>·>"merge changeA или changeB" — команда явно и точно показывает намерения что происходит. _>Про merge — это же я как раз "в минус" mercurial сказал, т.к. в ней pull не делает автоматический merge. ))) _>Ну да, если checkоut'ов сделать столько же, то будет уже практически одинаковый результат. Только такой вариант подходит исключительно для сценария без локальных имён. А если захочется локальные имена, то будет уже длиннее.. )
Я же другим ответом привёл вариант с локальными ветками. Команд ровно столько же.
Хотя да, если тебя по каким-то причинам не устроит локальное имя "master" и захочется назвать более подходяще, то да, понадобится ещё одна команда.
_>·>Т.е. фича конечно настолько крутая и полезная, что в официальных доках явно говорят её не использовать. _>·>Спрашиваетя зачем её сделали вообще? Чтобы выпендриваться на форумах, что можно вместо 30 команд обойтись всего лишь 29-ю? _>Да, на практике чаще всего синхронизации после ветвления не делают (разве что реально надо посоветоваться с коллегами какой вариант выбрать), а синхронизируются только после слияния.
Ок, соглашусь, что hg подходит лучше и экономит целую одну команду, если использовать подходы, которые даже разработчиками признаны как плохие. Мне почему-то кажется, что это является аргументом против hg.
Если же почитать доки по hg, и не использовать нерекомендованые подходы, которые, как я понимаю, оставлены лишь для обратной совместимости, то вряд ли ты сможешь обойтись меньшим числом команд.
_>Однако это по сути никак не меняет наш сценарий выше, т.к. в нём главным условием было сохранения в истории реализации альтернативного варианта.
С т.з. гит главной сложностью было использовать кривое (даже с т.з. hg!) решение — отправка безымянных голов в удалённый репозиторий.
А с сохранением истории вообще никаких проблем — все возможожные подходы решения задачи дают идентичную историю.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
_>>Вот мы сейчас только обсуждали сценарий и там по сути были глобальные ветки в Git. Ну да, ты конечно же можешь сказать, что и там можно было иметь разные имена в разных репозиториях (т.е. придумать 4 новых имени, вместо двух — вообще здорово), но на практике в таком сценарии никто подобного не стал бы делать. ·>Это как? Глобальных веток в git не бывает, даже со всякими сутями. Ты видимо что-то не понимаешь. Есть ветка в локальном репо, есть в ремотном, они _разные_, короткое имя (имя без префикса) может совпадать, но это ни к чему не обязывает.
Я всё понимаю, с точки зрения техники. ) Но по факту у тебя используется два эти имени в обоих репозиториях. И скорее всего во всех подобных сценариях так и будет. Хотя конечно формально есть возможность делать любые локальные имена. )
_>>Просто у Mercurial тоже есть свой commit -A. ))) Только он уже означает ещё и добавить/удалить автоматически все файлы в каталоге. ·>А, понял. Гит не добавляет новые файлы с "commit -a". Просто сделано по-другому, не знаю почему именно так решили сделать, но это явно не техническое ограничение.
Нуу кстати в данном случае это явно проявление архитектурной особенности git'a — наличия понятия stage. Это кстати единственный случае в git, где я вообще не понимаю зачем такое ввели, т.к. оно не приносит ни малейшей пользы, а лишнее телодвижения из-за этой хрени делать приходится.
_>>Про merge — это же я как раз "в минус" mercurial сказал, т.к. в ней pull не делает автоматический merge. ))) _>>Ну да, если checkоut'ов сделать столько же, то будет уже практически одинаковый результат. Только такой вариант подходит исключительно для сценария без локальных имён. А если захочется локальные имена, то будет уже длиннее.. ) ·>Я же другим ответом привёл вариант с локальными ветками. Команд ровно столько же.
Да, ровно столько же. Но в варианте без именованных локальных веток один checkout можно выкинуть (он там только для вида у тебя был), а в случае локальных веток нельзя, т.к. он задаёт имя.
·>Хотя да, если тебя по каким-то причинам не устроит локальное имя "master" и захочется назвать более подходяще, то да, понадобится ещё одна команда.
Эм, мы же это уже рассматривали... Нельзя так делать, т.к. не будет тогда требуемой симметрии решения. )
_>>Однако это по сути никак не меняет наш сценарий выше, т.к. в нём главным условием было сохранения в истории реализации альтернативного варианта. ·>С т.з. гит главной сложностью было использовать кривое (даже с т.з. hg!) решение — отправка безымянных голов в удалённый репозиторий. ·>А с сохранением истории вообще никаких проблем — все возможожные подходы решения задачи дают идентичную историю.
Нуу покажи другой вариант решения, чтобы точка выбора между альтернативами находилась после их фиксации и чтобы после слияния одной из альтернатив (естественно не должно быть разницы в командах и графах в зависимости от выбора), другая осталась в истории (и была доступна в других репозиториях).
Здравствуйте, alex_public, Вы писали:
_>>>Вот мы сейчас только обсуждали сценарий и там по сути были глобальные ветки в Git. Ну да, ты конечно же можешь сказать, что и там можно было иметь разные имена в разных репозиториях (т.е. придумать 4 новых имени, вместо двух — вообще здорово), но на практике в таком сценарии никто подобного не стал бы делать. _>·>Это как? Глобальных веток в git не бывает, даже со всякими сутями. Ты видимо что-то не понимаешь. Есть ветка в локальном репо, есть в ремотном, они _разные_, короткое имя (имя без префикса) может совпадать, но это ни к чему не обязывает. _>Я всё понимаю, с точки зрения техники. ) Но по факту у тебя используется два эти имени в обоих репозиториях. И скорее всего во всех подобных сценариях так и будет. Хотя конечно формально есть возможность делать любые локальные имена. )
Используются потому что я так захотел. А по факту это разные имена, их отдельно можно адресовать, указав явно. Полные имена это refs/heads/SomeName и refs/remotes/origin/SomeName — как видишь — они не равны. Просто git видя, что локальное имя SomeName используется в контексте ремотного репозитория origin, по умолчанию сопоставляет их друг другу при push или pull.
_>>>Просто у Mercurial тоже есть свой commit -A. ))) Только он уже означает ещё и добавить/удалить автоматически все файлы в каталоге. _>·>А, понял. Гит не добавляет новые файлы с "commit -a". Просто сделано по-другому, не знаю почему именно так решили сделать, но это явно не техническое ограничение. _>Нуу кстати в данном случае это явно проявление архитектурной особенности git'a — наличия понятия stage. Это кстати единственный случае в git, где я вообще не понимаю зачем такое ввели, т.к. оно не приносит ни малейшей пользы, а лишнее телодвижения из-за этой хрени делать приходится.
Неверно. -a флажок же проблем не было реализовать. Просто, как мне кажется, это наиболее частый сценарий — закоммитить изменённые файлы, но не случайно появившееся.
_>>>Про merge — это же я как раз "в минус" mercurial сказал, т.к. в ней pull не делает автоматический merge. ))) _>>>Ну да, если checkоut'ов сделать столько же, то будет уже практически одинаковый результат. Только такой вариант подходит исключительно для сценария без локальных имён. А если захочется локальные имена, то будет уже длиннее.. ) _>·>Я же другим ответом привёл вариант с локальными ветками. Команд ровно столько же. _>Да, ровно столько же. Но в варианте без именованных локальных веток один checkout можно выкинуть (он там только для вида у тебя был), а в случае локальных веток нельзя, т.к. он задаёт имя.
Локальное имя только для наглядности, можно обойтись и master.
_>·>Хотя да, если тебя по каким-то причинам не устроит локальное имя "master" и захочется назвать более подходяще, то да, понадобится ещё одна команда. _>Эм, мы же это уже рассматривали... Нельзя так делать, т.к. не будет тогда требуемой симметрии решения. )
Какой симметрии? Граф получится идентичный.
_>·>С т.з. гит главной сложностью было использовать кривое (даже с т.з. hg!) решение — отправка безымянных голов в удалённый репозиторий. _>·>А с сохранением истории вообще никаких проблем — все возможожные подходы решения задачи дают идентичную историю. _>Нуу покажи другой вариант решения, чтобы точка выбора между альтернативами находилась после их фиксации и чтобы после слияния одной из альтернатив (естественно не должно быть разницы в командах и графах в зависимости от выбора), другая осталась в истории (и была доступна в других репозиториях).
Была доступна как? Безымянной головой — не выйдет, конечно. А именованным бранчем — просто запушить да и всё. Я уже не понимаю что тебе ещё не понятно.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
·>то в изначальном будет 3 головы master, clones_master, clones_branch, структура графа — идентична.
Слегка не в тему вопрос. Допустим я пилил ветку и слил ее в ремот. Там она была смержена куда надо и удалена. Потом я тоже у себя ее удалил.
Как понять в рамках какой ветки изначально был запилен тот или иной коммит?
Здравствуйте, willie, Вы писали:
W>·>то в изначальном будет 3 головы master, clones_master, clones_branch, структура графа — идентична.
W>Слегка не в тему вопрос. Допустим я пилил ветку и слил ее в ремот. Там она была смержена куда надо и удалена. Потом я тоже у себя ее удалил. W>Как понять в рамках какой ветки изначально был запилен тот или иной коммит?
Никак. А зачем?
Главное же знать, в каких ветках какие есть коммиты. Ветка ссылается на коммит, а не коммит на ветку. Не нужно делать циклической зависимости.
Если надо поместить какую-то информацию в коммит, скажем bug id — просто добавь это в сообщение коммита. И не ограничивай себя только именем ветки, а добавляй что надо — номер спринта, идентификатор истории, фамилию проджект-менеджера, уровень алкоголя в крови, и т.п.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
