Здравствуйте, woah, Вы писали:
W>>>·>В каком случае ты столкнёшься с этим неудобством? Опиши сценарий. W>>>Кейсы когда надо git reflog не знаешь? W>·>reflog обычно нужен для того, чтобы посмотреть какие действия и когда делал, типа "какую ветку я вчера утром смотрел?". И, иногда, откатиться к предыдущим состояниям после того, как понял, что сделал что-то не так, типа "хотел смержить ту ветку, а смержил эту", или "ну и накой я удалил тот коммит?!". W>Не только. Бывалоча отматаешь бошку ветки на Nкоммитов назад и растишь оттуда. А потом хочешь этот отросток отловить чтобы черрипикнуть оттуда. W>Чем кроме рефлога это делать?
Самое простое — при отмотке башки сразу сказать что ты такое задумал: "git checkout -b weird_stuff HEAD~N" — т.е. ветку созать.
Или можно в stash затолкать.
Но если тебе ни жить, ни быть такой же подход как в hg, с бессмысленнымибезымянными ветками, то можно реализовать, писал выше примерно как.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
_>>Да, это я чуть спутал. Это я с netch80 обсуждал, а не с тобой, насчёт минимального режима по 2 ветки на репозиторий для Git'a. ) ·>Минимальный режим — одна ветка. Если ты регулярно синхронизируешься с одним и тем же репозиторием, то имеет смысл (но не обязательно, просто задалбывает каждый раз урл вбивать) добавить его URL как remote, что _автоматически_ создаст удалённые ветки (ветки с префиксом remote/) для отслеживания состояния удалённого репо и состояния синхронизации с ним.
Не, речь была про одну ветку для локальной работы и одну для синхронизации с коллегами. )
_>>Ну смотри. Вот допустим у нас кто-то сделал не одну ревизию относительно init, а две, причём параллельные (для этого в git придётся ещё одну ветку завести, да?). ·>Можно не заводить, но тогда эту ревизию будет сложнее найти потом (только неявно, как в hg, читая коммит-сообщения и т.п.) и она может собраться GC через месяц (если хочется, можно увеличить время или вообще отключить).
ОК, покажешь ниже как будет выглядеть в git данный процесс без создания ветки. )
_>>А теперь он хочет сделать слияние одной из этих ревизий с чужими результатами (как в изначальном сценарии). Теперь представь себе как будет выглядеть весь процесс в каждом из двух случаев (ревизия_алт1 или ревизия_алт2) ·>Да ровно так же. Бранчевание локальное или бранчевание между разыми клонами репов — не отличается вообще никак.
А мы тут говорим не про разделение, а наоборот про слияние. )
_>>и насколько будут похожими после этого выглядеть репозитории участников. ·>После синхронизации — репы будут идентичны.
Хыхы, ну вот покажешь сейчас. )
_>>Да, кстати, а в Mercurial не только итоговые графы будут одинаковые ·>По дефолту не будут из-за разных номеров ревизий. Или эти номера можно отключить?
Номера локальны же, к чему ты их постоянно упоминаешь? ) Может тогда ещё локальные закладки припомнишь и т.п? ) Это всё не сильно отличается по аргументации от претензии на разную отрисовку графа разными GUI.
_>>, но и сам процесс синхронизации/слияния не будет отличаться для этих двух параллельных ревизий. А в Git?))) ·>Не понимаю на что ты намекаешь. А что будет в git по-твоему? ·>Короче, я уже перестал понимать что конкретно ты хочешь. Скачай гит, обыграй некий сценарий, сравни его с hg и покажи результаты исследований здесь что там плохо, и мы посмотрим, можно ли улучшить.
Зачем git? ) Давай я тебя покажу как оно на Mercurial, а ты покажешь аналог на Git. Заодно и проверим насчёт одинаковых графов или возможности работы без веток.
Значит сценарий такой:
1. Создаём начальный репозиторий с начальной ревизией. (hg init; hg ci -A -m init).
2. Клонируем его рядом и создаём там развилку (hg clone; hg ci -m change2A; hg up 0; hg ci -m change2B)
3. Делаем новую ревизию в изначальном месте (hg ci -m change1) и синхронизируем репозитории (hg pull; hg up). В итоге в обоих должна появиться одинаковая картинка такого вида:
@ changeset: 3:5f9b580862e3
| tag: tip
| parent: 0:62aedd8b1f53
| user: Alex
| date: Mon Feb 15 19:32:14 2016 +0300
| summary: change1
|
| o changeset: 2:c1bbf51c5aaa
|/ parent: 0:62aedd8b1f53
| user: Tester
| date: Mon Feb 15 19:31:41 2016 +0300
| summary: change2B
|
| o changeset: 1:ee7810161f92
|/ user: Tester
| date: Mon Feb 15 19:31:22 2016 +0300
| summary: change2A
|
o changeset: 0:62aedd8b1f53
user: Alex
date: Mon Feb 15 19:30:21 2016 +0300
summary: init
4.1. Пользователь Tester решил что в дальнейшем правильнее будет использовать развитие по ветке B (хотя вариант A естественно должен остаться в репозитории, на будущее) и делает слияние этого варианта с чужими изменениями (hg merge 2; hg ci -m merge). И получает картинку вида:
@ changeset: 4:ceabd71628b6
|\ tag: tip
| | parent: 2:c1bbf51c5aaa
| | parent: 3:5f9b580862e3
| | user: Tester
| | date: Mon Feb 15 19:35:19 2016 +0300
| | summary: Merge
| |
| o changeset: 3:5f9b580862e3
| | parent: 0:62aedd8b1f53
| | user: Alex
| | date: Mon Feb 15 19:32:14 2016 +0300
| | summary: change1
| |
o | changeset: 2:c1bbf51c5aaa
|/ parent: 0:62aedd8b1f53
| user: Tester
| date: Mon Feb 15 19:31:41 2016 +0300
| summary: change2B
|
| o changeset: 1:ee7810161f92
|/ user: Tester
| date: Mon Feb 15 19:31:22 2016 +0300
| summary: change2A
|
o changeset: 0:62aedd8b1f53
user: Alex
date: Mon Feb 15 19:30:21 2016 +0300
summary: init
4.2. Пользователь Tester решил что в дальнейшем правильнее будет использовать развитие по ветке A (хотя вариант B естественно должен остаться в репозитории, на будущее) и делает слияние этого варианта с чужими изменениями (hg merge 1; hg ci -m merge). Картинка получается в точности такая же (только change2A и change2B поменяны местами)
5. Синхронизируем изначальный репозиторий (hg pull; hg up) и видим в нём точно такую же картинку, как и в пункте 4.
Соответственно интересно взглянуть на аналогичные картинки для пунктов 4.1, 4.2, 5 в Git. А так же наборы команды для реализации пунктов 2, 3, 4.1 и 4.2. )
Здравствуйте, ·, Вы писали:
_>>Я имею в виду, что если у тебя в кривой линуксовой ревизии были файлы a.txt и A.txt, то после исправления на винде у тебя в ревизии очевидно должно быть что-то вроде a.txt (с содержимым a.txt, а не некой рандомной хренью, создаваемой git'ом) и a1.txt (с содержимым А.txt), а не просто отсутствие файла A.txt. ·>"git mv A.txt a1.txt"?
Так это только на Линухе сработает. А на винде у тебя же нет A.txt в рабочей копии (там только a.txt имеется). Ну точнее я не знаю как там git на винде реализует команду mv (может он и выполнит команду, переименовав a.txt вместо A.txt), но в любом случае корректных данных не будет.
_>>Если кратко, то под винду существует множество реализаций Git'а и при этом каждая убога по своему. ))) ·>В чём официальная убога? "Устарвешая версия" — да, немного отстаёт от линуховой, но незначительно, на пару месяцев по моим наблюдениям.
Вот как раз с msysgit я и наблюдаю периодические баги. Типа проблем с пробелом и т.п. ) Правда у меня старая версия стоит (ещё более старая, чем в статье), не проверял последнюю (из готовых для винды). )))
_>>Да, а последний раздел (про 64-ёх битный вариант) я вообще без смеха читать не мог. ))) ·>И что?.. egit/jgit это pure java имплементации, оно изначально было сделано для работы с репозиториями из ява-приложений, чтобы не звать внешние тулзы или нативные либы. Для hg такого и нет. ·>Остальное — какие-то эксперименты, что в этом плохого? Не нравится — используй официальную версию. ·>64 бита — хз, понятия не имею, в последнее время проблем вроде нет. Хотя не удивлюсь что были, из-за разного понимания 64 под виндой и линухом.
Ну так я собственно про это всё и писал изначально — под виндой у Git торчат косяки из каждого угла. )))
Здравствуйте, ·, Вы писали:
_>>Например? ) ·>Ссылки (ветки, теги, stash, етс), reflog. Перечисляли же, не раз. ·>Вот скажем stash гораздо удобнее в git, чем анонимные ветки. А в hg это полная хрень, прикрученная сбоку, сделанная "шоб було" слабосвязанная фича, с которой даже diff нельзя сделать. Не удивительно, что приходится использовать анонимные ветки и считать их за благо.
Вот если бы stash можно было бы синхронизировать с коллегами, то возможно ещё какое-то бледное подобие и вышло бы... )
_>>·>Будет у тебя 20 экспериментов... и как их различать-то? _>>Вообще то у каждого есть подробное описание в комментарии к ревизии. ))) ·>Почему подробное описание писать не лень (мне наоборот — лень, ибо потом всё равно менять — добавить story number, перечитать/переписать раза два для понятности ревьюверам), а одно-два слова сочинить для имени ветки — проблема?
Потому что описание к ревизии — это обязательная вещь (и в Git и в Mercurial), а имена веток нет (в Mercurial)... )))
Здравствуйте, alex_public, Вы писали:
_>>>Да, это я чуть спутал. Это я с netch80 обсуждал, а не с тобой, насчёт минимального режима по 2 ветки на репозиторий для Git'a. ) _>·>Минимальный режим — одна ветка. Если ты регулярно синхронизируешься с одним и тем же репозиторием, то имеет смысл (но не обязательно, просто задалбывает каждый раз урл вбивать) добавить его URL как remote, что _автоматически_ создаст удалённые ветки (ветки с префиксом remote/) для отслеживания состояния удалённого репо и состояния синхронизации с ним. _>Не, речь была про одну ветку для локальной работы и одну для синхронизации с коллегами. )
Локально ветку можно не создавать. Но когда общаешься между репозиториями — да, ветка нужна. Культура такая — в своей песочнице делай что хочешь, а когда публикуешь — будь добр назвать.
_>>>А теперь он хочет сделать слияние одной из этих ревизий с чужими результатами (как в изначальном сценарии). Теперь представь себе как будет выглядеть весь процесс в каждом из двух случаев (ревизия_алт1 или ревизия_алт2) _>·>Да ровно так же. Бранчевание локальное или бранчевание между разыми клонами репов — не отличается вообще никак. _>А мы тут говорим не про разделение, а наоборот про слияние. )
Всё равно... какая разница — две репы с одной веткой или две ветки в одной репе.
_>>>Да, кстати, а в Mercurial не только итоговые графы будут одинаковые _>·>По дефолту не будут из-за разных номеров ревизий. Или эти номера можно отключить? _>Номера локальны же, к чему ты их постоянно упоминаешь? )
Потому что они жутко с толку сбивают. И смысла не имеют в DVCS.
_>Может тогда ещё локальные закладки припомнишь и т.п? ) Это всё не сильно отличается по аргументации от претензии на разную отрисовку графа разными GUI.
Так отключить-то можно, чтобы графы выглядели идентично? А то из-за этих номеров всё перемешивается. Причём тут гуи..
_>·>Не понимаю на что ты намекаешь. А что будет в git по-твоему? _>·>Короче, я уже перестал понимать что конкретно ты хочешь. Скачай гит, обыграй некий сценарий, сравни его с hg и покажи результаты исследований здесь что там плохо, и мы посмотрим, можно ли улучшить. _>Зачем git? ) Давай я тебя покажу как оно на Mercurial, а ты покажешь аналог на Git. Заодно и проверим насчёт одинаковых графов или возможности работы без веток.
_>Значит сценарий такой: _>1. Создаём начальный репозиторий с начальной ревизией. (hg init; hg ci -A -m init).
Я не понял смысл от начального репозитория, он выглядит как зеркало.
_>Соответственно интересно взглянуть на аналогичные картинки для пунктов 4.1, 4.2, 5 в Git. А так же наборы команды для реализации пунктов 2, 3, 4.1 и 4.2. )
Разница будет в том, что когда ты делаешь push в "начальный" репозиторий, ты должен будешь указать имя ветки. git
Т.е. в клонированном делаешь
git checkout HEAD^// (предыдущая ревизия)
hack-hack....
git commit ...
git push origin HEAD:a_branch_name // передаём текущую ревизию как a_branch_name имя
Ибо git передаёт между репозиториями только по имени ссылки (читай бранч). Притом, в последних версиях, по умолчанию ("git push") передаётся только текущий бранч.
Передачу произвольной ревизии и неопределённой пачки веток запретили из соображений безопасности.
На структуру графа это никак не влияет, графы будут идентичны (для синхронизованных частей, естественно).
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, alex_public, Вы писали:
_>>>Я имею в виду, что если у тебя в кривой линуксовой ревизии были файлы a.txt и A.txt, то после исправления на винде у тебя в ревизии очевидно должно быть что-то вроде a.txt (с содержимым a.txt, а не некой рандомной хренью, создаваемой git'ом) и a1.txt (с содержимым А.txt), а не просто отсутствие файла A.txt. _>·>"git mv A.txt a1.txt"? _>Так это только на Линухе сработает. А на винде у тебя же нет A.txt в рабочей копии (там только a.txt имеется). Ну точнее я не знаю как там git на винде реализует команду mv (может он и выполнит команду, переименовав a.txt вместо A.txt), но в любом случае корректных данных не будет.
Ну и что, у git есть index, который учитывает case.
_>>>Если кратко, то под винду существует множество реализаций Git'а и при этом каждая убога по своему. ))) _>·>В чём официальная убога? "Устарвешая версия" — да, немного отстаёт от линуховой, но незначительно, на пару месяцев по моим наблюдениям. _>Вот как раз с msysgit я и наблюдаю периодические баги. Типа проблем с пробелом и т.п. ) Правда у меня старая версия стоит (ещё более старая, чем в статье), не проверял последнюю (из готовых для винды). )))
Только дата публикации статьи годовой давности... Не надо просто такое старьё использовать.
_>·>Остальное — какие-то эксперименты, что в этом плохого? Не нравится — используй официальную версию. _>·>64 бита — хз, понятия не имею, в последнее время проблем вроде нет. Хотя не удивлюсь что были, из-за разного понимания 64 под виндой и линухом. _>Ну так я собственно про это всё и писал изначально — под виндой у Git торчат косяки из каждого угла. )))
Да, с этим я уже согласился, винда для него — не родная, как уж напилят, так и работает. Пользуйся пока 32-битной, она работает замечательно.
Но это всё детали имплементации, на общую архитектуру это не влияет.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, alex_public, Вы писали:
_>·>Ссылки (ветки, теги, stash, етс), reflog. Перечисляли же, не раз. _>·>Вот скажем stash гораздо удобнее в git, чем анонимные ветки. А в hg это полная хрень, прикрученная сбоку, сделанная "шоб було" слабосвязанная фича, с которой даже diff нельзя сделать. Не удивительно, что приходится использовать анонимные ветки и считать их за благо. _>Вот если бы stash можно было бы синхронизировать с коллегами, то возможно ещё какое-то бледное подобие и вышло бы... )
Cинхронизируй, разрешаю.
_>>>Вообще то у каждого есть подробное описание в комментарии к ревизии. ))) _>·>Почему подробное описание писать не лень (мне наоборот — лень, ибо потом всё равно менять — добавить story number, перечитать/переписать раза два для понятности ревьюверам), а одно-два слова сочинить для имени ветки — проблема? _>Потому что описание к ревизии — это обязательная вещь (и в Git и в Mercurial), а имена веток нет (в Mercurial)... )))
Кстати, интересно. А что будет если поменяешь описание ревизии? Создаётся ещё один отросток? А если старый уже был запушен?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Всё равно... какая разница — две репы с одной веткой или две ветки в одной репе.
Вот в Mercurial и нет разницы. А как в git сейчас увидим. )))
_>>Значит сценарий такой: _>>1. Создаём начальный репозиторий с начальной ревизией. (hg init; hg ci -A -m init). ·>Я не понял смысл от начального репозитория, он выглядит как зеркало.
Пункт 3 перечитай. И взгляни ещё раз на картинки (Alex — это пользователь изначального репозитория, а Tester — второго).
_>>Соответственно интересно взглянуть на аналогичные картинки для пунктов 4.1, 4.2, 5 в Git. А так же наборы команды для реализации пунктов 2, 3, 4.1 и 4.2. ) ·>Разница будет в том, что когда ты делаешь push в "начальный" репозиторий, ты должен будешь указать имя ветки. git ·>Т.е. в клонированном делаешь ·>git checkout HEAD^// (предыдущая ревизия) ·>hack-hack.... ·>git commit ... ·>git push origin HEAD:a_branch_name // передаём текущую ревизию как a_branch_name имя ·>Ибо git передаёт между репозиториями только по имени ссылки (читай бранч). Притом, в последних версиях, по умолчанию ("git push") передаётся только текущий бранч. ·>Передачу произвольной ревизии и неопределённой пачки веток запретили из соображений безопасности.
Давай для начала ты так же по пунктам покажешь наборы команд (я же это сделал тривиально), чтобы мы смогли сравнить удобство работы для такого сценария.
·>На структуру графа это никак не влияет, графы будут идентичны (для синхронизованных частей, естественно).
Что значит "синхронизированных частей"? ))) У меня есть граф в репозитории и всё. Теперь уже делаем оговорки, что будет одинаковое кусками? ))) Кстати, ты так и не показал свои варианты картинок (git log --graph которые)...
Здравствуйте, netch80, Вы писали:
N>Именно в таком варианте в анализаторе истории будет обнаружено полное совпадение файла и показан факт копирования. N>Но этот метод полезен только для того, чтобы помочь с автослежением по истории.
ну так не получится сделать — мне нужен как минимум компилируемый коммит.
а это в приведенном примере для первого (нового) файла скажем около 30% оригинального содержимого + правки, т.к. класс превратили в partial и попутно переимновали, для второго — оставшееся с похожими правками.
в итоге мне для меня неясен подход гита в отношении контроля версий файла. его выходит как бы и нет...
а blame это больше похоже на костыль ну или я вообще не догоняю философию гита
Здравствуйте, ·, Вы писали:
_>>·>"git mv A.txt a1.txt"? _>>Так это только на Линухе сработает. А на винде у тебя же нет A.txt в рабочей копии (там только a.txt имеется). Ну точнее я не знаю как там git на винде реализует команду mv (может он и выполнит команду, переименовав a.txt вместо A.txt), но в любом случае корректных данных не будет. ·>Ну и что, у git есть index, который учитывает case.
Ну т.е. никаких преимуществ у git тут нет, а недостатки имеются — даже не предупредит о проблеме. Хотя теоретически это конечно тоже можно отнести к проблеме реализации под Виндой... Но пользователям то от этого не легче (вот прямо в этой темке были вопросы с подобной мистикой).
Здравствуйте, ·, Вы писали:
_>>·>Вот скажем stash гораздо удобнее в git, чем анонимные ветки. А в hg это полная хрень, прикрученная сбоку, сделанная "шоб було" слабосвязанная фича, с которой даже diff нельзя сделать. Не удивительно, что приходится использовать анонимные ветки и считать их за благо. _>>Вот если бы stash можно было бы синхронизировать с коллегами, то возможно ещё какое-то бледное подобие и вышло бы... ) ·>Cинхронизируй, разрешаю.
Каким образом? )
_>>·>Почему подробное описание писать не лень (мне наоборот — лень, ибо потом всё равно менять — добавить story number, перечитать/переписать раза два для понятности ревьюверам), а одно-два слова сочинить для имени ветки — проблема? _>>Потому что описание к ревизии — это обязательная вещь (и в Git и в Mercurial), а имена веток нет (в Mercurial)... ))) ·>Кстати, интересно. А что будет если поменяешь описание ревизии? Создаётся ещё один отросток? А если старый уже был запушен?
Описания ревизий в Mercurial неизменные (ну если не считать редактирования истории с помощью ненормальных расширений), так же как и имена веток. )
Здравствуйте, alex_public, Вы писали:
_>>>Значит сценарий такой: _>>>1. Создаём начальный репозиторий с начальной ревизией. (hg init; hg ci -A -m init). _>·>Я не понял смысл от начального репозитория, он выглядит как зеркало. _>Пункт 3 перечитай. И взгляни ещё раз на картинки (Alex — это пользователь изначального репозитория, а Tester — второго).
А, ну понятно. Если бы автор бы был одинаков — фиг бы что было понятно на графе.
_>>>Соответственно интересно взглянуть на аналогичные картинки для пунктов 4.1, 4.2, 5 в Git. А так же наборы команды для реализации пунктов 2, 3, 4.1 и 4.2. ) _>·>Разница будет в том, что когда ты делаешь push в "начальный" репозиторий, ты должен будешь указать имя ветки. git _>·>Т.е. в клонированном делаешь _>·>git checkout HEAD^// (предыдущая ревизия) _>·>hack-hack.... _>·>git commit ... _>·>git push origin HEAD:a_branch_name // передаём текущую ревизию как a_branch_name имя _>·>Ибо git передаёт между репозиториями только по имени ссылки (читай бранч). Притом, в последних версиях, по умолчанию ("git push") передаётся только текущий бранч. _>·>Передачу произвольной ревизии и неопределённой пачки веток запретили из соображений безопасности. _>Давай для начала ты так же по пунктам покажешь наборы команд (я же это сделал тривиально), чтобы мы смогли сравнить удобство работы для такого сценария.
1. "git checkout HEAD^" (вернутся на предыдушую ревизию) или "git checkout origin/master" (вернуться ровно на текущую в начальном репозитории).
2. hack-hack...
3. git commit -m change2B
4. git push origin master HEAD:clones_branch //пушим обе ветки — master (локальный) в master (удалённый) и безымяную (локальный) в clones_branch (удалённый)
Альтернатива, именовать бранч локально, но имена могут быть разными:
1. "git checkout HEAD^ -b trying_stuff"
2. hack-hack...
3. git commit -m change2B
4. git push origin master trying_stuff:clones_experiment_with_stuff
Графы ревизий будут идентичные, только ссылки на ревизии будут отличаться. В клоне будут две ветки master (локальная) и origin/master (указывает на положение ветки master в репозитории origin), главный ничего не знает о клоне, поэтому там будет только master, указывающий на тот же sha1 что и origin/master.
_>·>На структуру графа это никак не влияет, графы будут идентичны (для синхронизованных частей, естественно). _>Что значит "синхронизированных частей"? ))) У меня есть граф в репозитории и всё. Теперь уже делаем оговорки, что будет одинаковое кусками? ))) Кстати, ты так и не показал свои варианты картинок (git log --graph которые)...
Что когда ты создаёшь коммиты, ты их создаёшь локально. Другой репозиторий увидит эти коммиты только если сделать fetch или push этих коммитов.
Как я понял, "hg up 0; hg ci -m change2B; hg up 1; hg push" запушит и ченджсет 2. В git нет, начиная с версии 2 пушится только то что скажешь, по дефолту только текущий бранч.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
_>>Давай для начала ты так же по пунктам покажешь наборы команд (я же это сделал тривиально), чтобы мы смогли сравнить удобство работы для такого сценария. ·>1. "git checkout HEAD^" (вернутся на предыдушую ревизию) или "git checkout origin/master" (вернуться ровно на текущую в начальном репозитории). ·>2. hack-hack... ·>3. git commit -m change2B ·>4. git push origin master HEAD:clones_branch //пушим обе ветки — master (локальный) в master (удалённый) и безымяную (локальный) в clones_branch (удалённый) ·>Альтернатива, именовать бранч локально: ·>1. "git checkout HEAD^ -b clones_branch" ·>2. hack-hack... ·>3. git commit -m change2B ·>4. git push origin master clones_branch ·>Альтернатива, именовать бранч локально, но имена могут быть разными: ·>1. "git checkout HEAD^ -b trying_stuff" ·>2. hack-hack... ·>3. git commit -m change2B ·>4. git push origin master trying_stuff:clones_experiment_with_stuff ·>Графы ревизий будут идентичные, только ссылки на ревизии будут отличаться. В клоне будут две ветки master (локальная) и origin/master (указывает на положение ветки master в репозитории origin), главный ничего не знает о клоне, поэтому там будет только master, указывающий на тот же sha1 что и origin/master.
Ну для начала ты тут не осилил даже мои пункты 1-3, т.к. у тебя нет синхронизации без обязательного слияния. Т.е. нет состояния с тремя головами в каждом репозитории. А я может хочу просто сделать 2 альтернативные ревизии и заслать их народу (у которого тоже там какие-то свои ревизии есть), а слияния уже может другой кто-то будет производить. Соответственно у тебя поэтому и картинки из пункта 3 получить нельзя.
Далее, прямо по твоему набору команд (в любой вариации) видно, что они сильно не симметричны относительно ревизий A и B. Т.е. вот прямо из твоих примеров не видно как собственно можно направить на слияние с основной веткой ревизию B (напоминаю, что точка принятия решения, какую ревизию мы выбираем для дальнейшей работы в основной ветке должна быть уже после фиксации обеих ревизий).
Ну и наконец, хотелось бы всё же реального аналога моих пунктов с полным набором всех необходимых команд (редактирование тестового файла пропускаем естественно), чтобы можно было количественно (ну хотя бы по числу необходимых команд) сравнить удобство работы с обеими системами.
_>>·>На структуру графа это никак не влияет, графы будут идентичны (для синхронизованных частей, естественно). _>>Что значит "синхронизированных частей"? ))) У меня есть граф в репозитории и всё. Теперь уже делаем оговорки, что будет одинаковое кусками? ))) Кстати, ты так и не показал свои варианты картинок (git log --graph которые)... ·>Что когда ты создаёшь коммиты, ты их создаёшь локально. Другой репозиторий увидит эти коммиты только если сделать fetch или push этих коммитов. ·>Как я понял, "hg up 0; hg ci -m change2B; hg up 1; hg push" запушит и ченджсет 2. В git нет, начиная с версии 2 пушится только то что скажешь, по дефолту только текущий бранч.
То, что Mercurial по умолчанию синхронизирует весь репозиторий, а Git только текущую ветку, тут уже давно обсуждали. Но я же тебя не ограничиваю тебя в использование параметров к командам Git. ))) Используй любые режимы и настройки, главное чтобы результат получился нужным — нам требуются полная синхронизация двух репозиториев по всем данным (и в Mercurial при этом будут одинаковые графы ревизий).
Здравствуйте, alex_public, Вы писали:
a> Ну и наконец, хотелось бы всё же реального аналога моих пунктов с полным набором всех необходимых команд (редактирование тестового файла пропускаем естественно), чтобы можно было количественно (ну хотя бы по числу необходимых команд) сравнить удобство работы с обеими системами.
Я слежу за спором весьма поверхностно (можно даже сказать не слежу), но выглядит пока все так что в Меркуриал есть единственно правильный воркфлоу, который почему-то считается единственно удобным и основываясь на этом весьма цпорном утверждении ты пытаешься доказать ущербность гита. У меня реального опыта с hg нет, но похоже это скорее svn с некоторыми фишками распределенности.
Здравствуйте, Dziman, Вы писали:
a>> Ну и наконец, хотелось бы всё же реального аналога моих пунктов с полным набором всех необходимых команд (редактирование тестового файла пропускаем естественно), чтобы можно было количественно (ну хотя бы по числу необходимых команд) сравнить удобство работы с обеими системами. D>Я слежу за спором весьма поверхностно (можно даже сказать не слежу), но выглядит пока все так что в Меркуриал есть единственно правильный воркфлоу, который почему-то считается единственно удобным и основываясь на этом весьма цпорном утверждении ты пытаешься доказать ущербность гита. У меня реального опыта с hg нет, но похоже это скорее svn с некоторыми фишками распределенности.
Как раз наоборот, это Mercurial включает в себя как все возможности Git (во всяком случае начиная с той версии Mercurial, в которой добавили закладки), так и набор своих уникальных решений. Соответственно как раз с помощью Mercurial можно выбирать для одной задачки разные решения, на свой вкус. И как итог этого на практике, в части задач обе системы выглядят абсолютно одинакового, а в части Mercurial удобнее. Естественно все задачки решаемы обеими системами (всё же дополнительные возможности Mercurial по сути являются альтернативными, а не чем-то принципиальным), вопрос только с какой степенью удобства... Собственно именно это я и пытаюсь проанализировать в данной дискуссии — насколько допольнительные (относительно Git'a) возможности Mercurial увеличивают удобство работы с системой. Только вот мой оппонент всё никак не предоставит материал для точного сравнения...
Здравствуйте, alex_public, Вы писали: a> Как раз наоборот, это Mercurial включает в себя как все возможности Git (во всяком случае начиная с той версии Mercurial, в которой добавили закладки), так и набор своих уникальных решений. Соответственно как раз с помощью Mercurial можно выбирать для одной задачки разные решения, на свой вкус. И как итог этого на практике, в части задач обе системы выглядят абсолютно одинакового, а в части Mercurial удобнее. Естественно все задачки решаемы обеими системами (всё же дополнительные возможности Mercurial по сути являются альтернативными, а не чем-то принципиальным), вопрос только с какой степенью удобства... Собственно именно это я и пытаюсь проанализировать в данной дискуссии — насколько допольнительные (относительно Git'a) возможности Mercurial увеличивают удобство работы с системой. Только вот мой оппонент всё никак не предоставит материал для точного сравнения...
Потому что реально бранчи-небранчи-метки-анонимки ни разу не понятная муть польза которой ну вообще вот не понятна
Здравствуйте, Dziman, Вы писали:
D> a> Как раз наоборот, это Mercurial включает в себя как все возможности Git (во всяком случае начиная с той версии Mercurial, в которой добавили закладки), так и набор своих уникальных решений. Соответственно как раз с помощью Mercurial можно выбирать для одной задачки разные решения, на свой вкус. И как итог этого на практике, в части задач обе системы выглядят абсолютно одинакового, а в части Mercurial удобнее. Естественно все задачки решаемы обеими системами (всё же дополнительные возможности Mercurial по сути являются альтернативными, а не чем-то принципиальным), вопрос только с какой степенью удобства... Собственно именно это я и пытаюсь проанализировать в данной дискуссии — насколько допольнительные (относительно Git'a) возможности Mercurial увеличивают удобство работы с системой. Только вот мой оппонент всё никак не предоставит материал для точного сравнения...
D> Потому что реально бранчи-небранчи-метки-анонимки ни разу не понятная муть польза которой ну вообще вот не понятна
Еще номера ревизий униклаьные для каждого локального репо и в то же время глобальный синк всего репо с глобальными именами лучно мне представляются принципиальным фейлом концепции DVCS
Здравствуйте, alex_public, Вы писали:
_>>>·>Вот скажем stash гораздо удобнее в git, чем анонимные ветки. А в hg это полная хрень, прикрученная сбоку, сделанная "шоб було" слабосвязанная фича, с которой даже diff нельзя сделать. Не удивительно, что приходится использовать анонимные ветки и считать их за благо. _>>>Вот если бы stash можно было бы синхронизировать с коллегами, то возможно ещё какое-то бледное подобие и вышло бы... ) _>·>Cинхронизируй, разрешаю. _>Каким образом? )
Ну например просто "git stash pop", "git stash" поверх последних изменений коллег.
_>>>Потому что описание к ревизии — это обязательная вещь (и в Git и в Mercurial), а имена веток нет (в Mercurial)... ))) _>·>Кстати, интересно. А что будет если поменяешь описание ревизии? Создаётся ещё один отросток? А если старый уже был запушен? _>Описания ревизий в Mercurial неизменные (ну если не считать редактирования истории с помощью ненормальных расширений), так же как и имена веток. )
Т.е. пофиксить орфографическую ошибку в сообщении или добавить номер тикета не выйдет без заморочек?
Тебе просто кажется что они неизменные, промыли тебе мозг CVCS наследием. Ревизии в любой DVCS можно отредактировать всегда — сгенерить патчи, грохнуть локальный репозиторий, создать клон снова, чуть подредактировать и зааплаить патчи. Вопрос в другом — реализовать эту возможность нормально, для людей, как в git, или ненормально, через жо расширения, как в hg.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, alex_public, Вы писали:
_>Ну для начала ты тут не осилил даже мои пункты 1-3, т.к. у тебя нет синхронизации без обязательного слияния.
У меня вообще слияния нет. Ты видел команду pull или merge?
_>Т.е. нет состояния с тремя головами в каждом репозитории. А я может хочу просто сделать 2 альтернативные ревизии и заслать их народу (у которого тоже там какие-то свои ревизии есть), а слияния уже может другой кто-то будет производить. Соответственно у тебя поэтому и картинки из пункта 3 получить нельзя.
Да возьми ты гит и поиграйся.
Картинка будет та же, но ветки будут не безымянные отростки, а с символьными ссылками (ака бранчами).
_>Далее, прямо по твоему набору команд (в любой вариации) видно, что они сильно не симметричны относительно ревизий A и B. Т.е. вот прямо из твоих примеров не видно как собственно можно направить на слияние с основной веткой ревизию B (напоминаю, что точка принятия решения, какую ревизию мы выбираем для дальнейшей работы в основной ветке должна быть уже после фиксации обеих ревизий).
Она несимметрична только именами бранча. В моём скрипте бранчи будут master и clones_branch
_>Ну и наконец, хотелось бы всё же реального аналога моих пунктов с полным набором всех необходимых команд (редактирование тестового файла пропускаем естественно), чтобы можно было количественно (ну хотя бы по числу необходимых команд) сравнить удобство работы с обеими системами.
Само разветвление я тебе показал. Команд столько же. Для слияния добавятся pull или merge. Команд будет столько же.
Т.е. допустим что Tester хочет влить изменения "Alex" в change2B, он сделает
git checkout clones_branch // переключает рабочую копию в change2B
git pull origin master // собственно мерж
git push // чтобы отправить результат мержа в начальный репозиторий.
_>·>Как я понял, "hg up 0; hg ci -m change2B; hg up 1; hg push" запушит и ченджсет 2. В git нет, начиная с версии 2 пушится только то что скажешь, по дефолту только текущий бранч. _>То, что Mercurial по умолчанию синхронизирует весь репозиторий, а Git только текущую ветку, тут уже давно обсуждали. Но я же тебя не ограничиваю тебя в использование параметров к командам Git. ))) Используй любые режимы и настройки, главное чтобы результат получился нужным — нам требуются полная синхронизация двух репозиториев по всем данным (и в Mercurial при этом будут одинаковые графы ревизий).
Так я показал вроде всё... Разница только в том, что вместо 0 и 1 надо будет использовать ветки (кстати если так хочется анонимности, назови ветки как "0" и "1").
Разница с синхронизацией может быть выражена в том, что Tester может не публиковать свою локальную ревизию в начальный репо, которую он не вмержил в master. Т.е. если Tester решил замержить change2B, то change2A никогда не появится в начальном репозитории (и естественно не будет видна в графе).
Это может быть полезно, когда есть больше 2 репозиториев. Например такой сценарий. Есть начальный репозиторий. Tester делает клон, создаёт там две конкурирующие (diverged) ветки change2A, change2B, но ещё не знает какая из них лучше. Идёт домой, и дома делает клон от клона — забирая домой обе ветки.
Дома решает что change2B лучше и мержит её в клоне клона с последними изменениями Alex, пушит результат из клона клона напрямую (минуя клон) в начальный репо.
Может так же и в клон запушить. Или завтра запуллить в клон из начального.
Т.е. change2A существует в графах клона и клона клона, но не в начальном репозитории.
В общем, distributed — по полной программе.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Dziman, Вы писали:
D>> Потому что реально бранчи-небранчи-метки-анонимки ни разу не понятная муть польза которой ну вообще вот не понятна D>Еще номера ревизий униклаьные для каждого локального репо и в то же время глобальный синк всего репо с глобальными именами лучно мне представляются принципиальным фейлом концепции DVCS
Так опять же есть локальные номера и есть уникальные хэши (как в git). В режиме по умолчанию идёт синхронизация всего репозитория, но никто не мешает добавить соответствующую опцию и сделать синхронизацию одной ветки (как в git по умолчанию). Т.е. все возможности Git в наличие, плюс ещё кое-что. )
ну или я вообще не догоняю философию гита
