Здравствуйте, sergey179, Вы писали:
K>>Вот потому он и не нужен™
S>После работы с такими коммерческими тулами как ClearCase, Synergy, Rational TeamConcert мне Git показался самым разумным что было изобретено в этой области. Особенно в плане написания интеграций с ним.
Единственная причина популярности Git — социальная сеть для миллионов разработчиков Github. Всё, никаких других причин использовать сложную утилиту для поддержки разработки ядра Linux за пределами разработки ядра Linux — нет.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
S>>Хотя лично я предпочитаю не страдать без необходимости и просто поставить svn. EP>А как же скорость? Например log или blame?
Начиная с 1.7 свн здорово допилили почти по всем фронтам, на практике проблем ни разу не возникало, даже на долгоживущих репо с сильно пятизначными номерами коммитов
Хотя не, вру. Если приспичило прокрутить всю историю на лет шесть назад — поседеешь, пока дождёшься. При этом реально нужное, например посмотреть изменения по конкретной папке/файлу, даже если менялось года три назад, работает нормально. Секунд 5 где-то.
Ещё из тормозов — repo browser тортойза, ну и чекаут репо на несколько Гб может минут 20 занять. Больше ничего из тормозов не вспомнил.
Как по мне, плата за модель "тыкнул кнопку — забрал, тыкнул кнопку — отправил" более чем достойная.
P.S. Blame — 2-3 секунды на больших файлах с длинной историей.
Это всё с учётом того, что сервер не в локальной сети.
Здравствуйте, DSblizzard, Вы писали:
DS>Гит от робота и для роботов. Способность "вернуть все взад" — принципиальная возможность систем контроля версий. Если это по каким-либо причинам не получается — на помойку.
Оно получается.
S>>Кэп: гит не работает, если в команде есть хоть один человек, не изучивший мануал. DS>Получаем, что при увеличении команды (а ведь Гит создавался именно для больших сообществ разработчиков) вероятность того, что он не работает, стремится к единице.
Sinix неправ, или неадекватно сформулировал. Или ты слишком обобщаешь.
Да, без понимания принципов (считаем, без изучения доки) конкретный человек не будет понимать, что происходит, что делать и как удовлетворить запросы. Но это совершенно не означает, что он всё сломает у всех. При нормальной организации он всего лишь не выполнит свой личный кусок работы. А тут точно так же дальше как в любой большой группе — кто-то попал под трамвай, кто-то поймал свиной грипп, кто-то ушёл в монастырь, не доделав своего куска — но в целом работа движется.
Пример с некорректным rebase разносит только одну локальную ветку и не более того. Другие ветки живы. Другие репо у того же разработчика живы. У других разработчиков, на сервере — всё живо.
Если этот неадекват начал свои кривые результаты скидывать на сервер — в обычном push эту кривизну не примут. Если он делает forced push — от forced push есть защита.
Если он просто гонит туфту в коммитах — можно обрезать ветки обратно, можно сделать revert'ы, если полезно сохранить неудачу в истории или сложно вырезать коммит по иным причинам.
Если нужно обеспечить peer review и контроль менеджером, чтобы не было туфты, ставятся gitlab, gerrit и тому подобное, или можно работать на чистых pull from peer, сохраняя распределённую сеть. Вариантов — масса. Повторюсь, никакого конца света, никакого "не работает", и никакого в этом смысле принципиального отличия от других DVCS. Кроме одного — мне и многим другим конкретная организация git выглядит наиболее естественной, в том смысле, что больше всего действий "интуитивно ясно" и требуется минимум насилия над логикой при обучении.
Здравствуйте, Vladek, Вы писали:
V>Даже не пытался изучать гит, хоть и использовал его через студию для выкладывания кода на Гитхаб, из-за таких постов где угодно — стопицот команд, какие-то вечные проблемы, постоянные рояли из кустов в виде новых команд, которые решают старые проблемы и привносят новые. Нафиг.
V>Использование гита вне Гитхаба и Линукса — для меня красный флаг, команда идёт на поводу у моды, принимая технические решения.
Никогда не следовал моде, но после знакомства с Git решил, что среди имеющегося это лучшее, что есть. И за последние 8 лет ни разу не пожалел
Жалобы есть на все инструменты, это не фактор.
Здравствуйте, netch80, Вы писали:
V>>Использование гита вне Гитхаба и Линукса — для меня красный флаг, команда идёт на поводу у моды, принимая технические решения. N>Никогда не следовал моде, но после знакомства с Git решил, что среди имеющегося это лучшее, что есть. И за последние 8 лет ни разу не пожалел N>Жалобы есть на все инструменты, это не фактор.
Mercurial лучше — абсолютно те же самые технические возможности, но при этом более удобно. Хотя если делать всё через GUI или вообще из какой-нибудь IDE, то скорее всего разницы не увидишь.
Здравствуйте, Dair, Вы писали:
D>и... моих изменений нет вообще. Ни одного. Пять коммитов. День работы насмарку. Отличный Git
1) все твои коммиты есть в git reflog
2) На сервере стоит принудительно включать запрет на force push — тогда гарантированно репозиторий на сервере никто не сломает
С уважением, Евгений
JetBrains, Inc. "Develop with pleasure!"
Здравствуйте, alex_public, Вы писали:
V>>>Использование гита вне Гитхаба и Линукса — для меня красный флаг, команда идёт на поводу у моды, принимая технические решения. N>>Никогда не следовал моде, но после знакомства с Git решил, что среди имеющегося это лучшее, что есть. И за последние 8 лет ни разу не пожалел N>>Жалобы есть на все инструменты, это не фактор.
_>Mercurial лучше — абсолютно те же самые технические возможности, но при этом более удобно.
Нет, в разы менее удобно, идиотская логика на каждом углу. И не надо возражать, этот холивар давно надоел и я всё равно не соглашусь, ничего лучшего за последние лет 5 в меркуриале не случилось.
Здравствуйте, netch80, Вы писали:
N>Ситуацию, когда в пределах одной рабочей копии status показывает изменение, а hard reset его не сбрасывает, это не даст.
Я подобное наблюдал, когда в репозиторий были добавлены файлы с разным содержимым, но именами, отличающимися только регистром.
Типовой use case такой:
На GNU/Linux (сase-sensitive FS by default) добавляем файлы, имена которых отличаются только регистром.
На OS X (case-insensitive FS by default) делаем pull.
В этом случае "git status" на OS X показывает измененные файлы даже после "git reset --hard".
Здравствуйте, CrystaX, Вы писали:
_>>Какая милая система... ))) CX>Очевидно, что это не проблема git-а. Это проблема различных используемых FS. Подобные проблемы будут с любым софтом. Но git с этим пытается бороться с помощью core.ignoreCase:
Естественно это проблема разных ОС (в данном случае Винда хуже). Но подобный софт должен учитывать эти нюансы и как минимум предупреждать пользователя о потенциальном конфликте.
_>>Кстати, я помнится наблюдал ещё, что git (как и многий другой древний линуксовый софт) до сих пор ломается на каталога с пробелами в именах. ) Это вообще жесть и убогость. ))) CX>Это не так. Если подавать пути ему на вход правильно (т.е. в кавычках или с экранированными пробелами), проблем нет.
А я не про это. Я про инсталляцию самого git'a куда-нибудь в каталог с пробелом в имени (типа "Program Files"). Данная убогость присутствует в очень многих линуксовых программах (и это уже кривизна Линуха).
Здравствуйте, Dair, Вы писали:
D>и... моих изменений нет вообще. Ни одного. Пять коммитов. День работы насмарку. Отличный Git
Даже не пытался изучать гит, хоть и использовал его через студию для выкладывания кода на Гитхаб, из-за таких постов где угодно — стопицот команд, какие-то вечные проблемы, постоянные рояли из кустов в виде новых команд, которые решают старые проблемы и привносят новые. Нафиг.
Использование гита вне Гитхаба и Линукса — для меня красный флаг, команда идёт на поводу у моды, принимая технические решения.
Здравствуйте, sergey179, Вы писали:
V>>Единственная причина популярности Git — социальная сеть для миллионов разработчиков Github. Всё, никаких других причин использовать сложную утилиту для поддержки разработки ядра Linux за пределами разработки ядра Linux — нет. S>Субъективное недовольство. Я вижу как крупные компании целиком или отделами мигрируют с коммерческих тулов на Git имея на то множество объективных причин.
Так весь вопрос в том, с чего они мигрируют. Наверняка же с древних ужасных инструментов, переход с которых на git безусловно оправдан. Другое дело, если сравнивать git с другими современными инструментами, типа mercurial/bazaar/fossil и т.п. В такой компании git выглядит уже далеко не однозначно лучшим выбором. Однако чаще всего выбирают именно его, в основном как раз из-за популярности гитхаба.
Здравствуйте, alex_public, Вы писали:
_>>>Да просто очередной не читавший документацию и не смогший понять, что у него теперь просто две ветки. _>·>Покажи документацию, которую читаешь ты. _>Здесь https://www.mercurial-scm.org/wiki/Branch всё подробно рассказано. Почему-то пользователи git путают "branch name" (всего лишь атрибут ревизии) и реальные ветки (а вот их в упор не видят, хотя они и являются основным инструментом).
Может я буквы читать разучился, но покажи в какой позиции в строке "you must first pull the head of that development line " находится слово "branch"?
В документации branch — это такой монстр, имя которого хранится в атрибуте, у которого есть множество heads. А ещё есть development line, related repositories. А ещё, оказывается, hg мержит не branches, а lines of development.
Столько ненужной и лишней терминологии просто из-за кривого дизайна системы.
_>И в результате получают глупости типа описанных в последнем предложение по моей ссылке. )))
Которой ссылке? Я правильно понял, ты имеешь в виду что в официальной документации hg написана глупость?
_>>>А причём тут централизованные системы? ) Там как раз ничего подобного нет. ) _>·>hg пытается сидеть на двух стульях, вроде как dvcs, а имена веток — глобальные, как в cvcs. А ещё эти приколы с номерами ревизий... _>А расскажи, чем по твоему неудобны глобальные имена веток? )
Тем что это противоречит распределённости. Лишняя сущность, которая нужна далеко не всегда. Что плохого в том, если два разработчика создадут ветки "experiment", а потом захотят обменяться?
_>Про номера ревизий не понял в чём проблема, это всего лишь локальные хоткеи для удобства (если не хочешь, можешь вообще не обращать на них внимание) адресации.
Ещё одна ненужная нашлёпка сбоку, унаследованная от cvcs.
_>>>Эм, какие клоны? ) Ты вообще о чём? ) Я говорил об удобстве работы на базе использования анонимных веток в mercurial (которые автоматически создаются, когда обнаруживается двое или более ревизий потомком у одной базовой). Причём это удобно даже если говорить не о синхронизации нескольких разработчиков (там это вообще идеально полезно), а о просто одиночной работе — неудобно придумывать название и создавать руками отдельную ветку ради маленького одиночного эксперимента с кодом (довольно распространённый сценарий). _>·>Скажи... Ты читал документацию на "hg heads"? Что показывает эта команда в формате "hg heads <branchname>"? В каком словаре слово "head" означает "анонимная ветка"? _>Ну так правильно, heads то показывает не все существующие ветки в репозитории, а только некое подмножество — не слитые. А heads <branchname> показывает ещё более мелкое подмножество — помеченные определённым именем.
Объясни, каким словарём ты пользуешься, что словосочетание "branch heads" ты переводишь как "ветки"? Или в документаци, как всегда, глупость написана?
_>Так а может ты пояснишь, какой аналог анонимных веток у нас в git? ) Т.е. что делать при нескольких параллельных изменения относительно одной родительской ревизии, обязательно заводить отдельную именованную ветку? )
А если не обязательно параллельных?
В общем да, можно и ветку завести — ибо это ничего не стоит и никаких сложностей не создаёт. Это же не hg, где если заведёшь ветку, то это "навсегда". Собственно эта "фича" hg продиктована необходимостью — ветку завести не всегда возможно, вот и пришлось придумать новую сущность — головы.
Ещё можно просто по sha1 обращаться. Можно reflog полистать, можно в stash закинуть. Вариантов куча.
_>·>Так и незапакованные гит-репозитории на практике никогда не встречаются. _>·>А если не учитывать время, то hg тупо слил по размеру в 6 раз! _>Ну давай объясни мне в какой момент произойдёт на практике это чудесная автоматическая перепаковка. Вот завёл я чистый репозиторий. Кинул в него несколько больших (для удобства теста) текстовых файлов — ничего нет. Добавил несколько ревизий — всё равно ничего нет (а размер хранилища уже за мегабайт вылезает, в то время как у mercurial намного меньше). Так когда же? )
Если хочешь разобраться досконально, читай хелп на "git gc", флажок --auto. Там точно указаны правила. Используются несколько имперически подобранных параметров, чтобы в более менее стандартных ситуациях давать хороший результат, если что — можно подкрутить для особых случаев. Вроде очевидно, что "несколько мегабайт" это не то, о чём стоит волноваться.
_>>>·>Враньё. Или факты в студию. _>>>Это общеизвестный факт (если конечно же не делать периодических ручных repack'ов). _>·>Нет, типичное враньё. _>Ага, ага http://draketo.de/proj/hg-vs-git-server/test-results.html. Или это слишком сложно и детально? )
Графики каие-то нечитабельные. И я не понял — а что именно там коммитилось-то? Что-то какие-то случайные модификации каких-то случайных данных...
_>Тогда рекомендую глянуть на такие http://stackoverflow.com/questions/6969385/why-is-my-git-repository-so-much-larger-than-mercurial-version вопросы, периодически возникающие на SO и т.п. местах.
Какой-то вырожденный случай, репозиторий из одного бинарного файла... Мы вроде тут о реальности рассуждали.
_>>>·>Именно это и будет реальный размер в любом долгоживущем или свежесклонированном репозитории. _>>>Уууу) _>>>У себя на диске (у тебя же есть свои проекты в git не так ли?) проверь для начала. ))) _>·>Проверял, неоднократно. Все мои репозитории запакованы. _>Враньё. ) Ну или же ты с ними просто не работаешь (склонировал с каких-то серверов и всё).
Так новые ревизии не заставляют репозиторий распаковываться. То что запаковалось — так и остаётся запакованным.
_>>>Ну так практика то говорит что хуже. ))) Проверь сам. ) Только по честному, без предварительных ручных repack'ов репозитория. ))) _>·>Опиши эксперимент, а лучше проведи сам. Разницу в 10-20% не учитывать, ибо не принципиальна. _>Берём текстовый файл на мегабайт (чтобы ясно была разница, а то там всякие накладные расходы и т.п.). Кидаем в чистый репозиторий. Фиксируем ревизию. Меняем одну строчку в файле, снова фиксируем. Делаем пакет (bundle) из одной последней ревизии и смотрим размер файла (число1, должно быть очень маленькое), делаем пакет из двух последних ревизий (по сути будет весь репозиторий) и смотрим размер файла (число2, должно быть большое). Выполняем эту последовательность и для mercurial и для git, а потом сравниваем в начале две версии числа1, а потом две версии числа 2.
kan@altegol:~/tmp/experiment/bundle/git$ ls -l
total 1424
-rw-rw-r-- 1 kan kan 228253 Feb 6 13:25 1.bundle
-rw-rw-r-- 1 kan kan 419 Feb 6 13:26 2.bundle
-rw-rw-r-- 1 kan kan 1198368 Feb 6 13:18 file
kan@altegol:~/tmp/experiment/bundle/hg$ ls -l
total 1356
-rw-rw-r-- 1 kan kan 157286 Feb 6 13:41 1.bundle
-rw-rw-r-- 1 kan kan 399 Feb 6 13:42 2.bundle
-rw-rw-r-- 1 kan kan 1198368 Feb 6 13:39 file
Разница есть, конечно, но не принципиальна... Вообще не понимаю причём тут бандлы, они от структуры репозитория не зависят.
_>>>Давай всё же подведём какой-то итог данному подразделу нашей дискуссий. Моё утверждение было такое: хранилище mercurial занимает меньше места чем хранилище git без постоянных ручных repack'ов последнего, а этим никто в реальности не занимается. Поясни с какой его частью (первой или второй) ты всё же не согласен. _>·>"постоянных ручных repack'ов последнего, а этим никто в реальности не занимается" — с этим согласен, никто вручную repack не делает в реальности. _>·>"хранилище mercurial занимает меньше места" — не согласен, т.к. надо рассматривать пакованный репо, ибо в реальности репы пакованные. _>Пакованным они будут до добавления новых ревизий, т.е. очень не долго. )
Нет, конечно. Только новые ревизии будут не пакованными, до очередного gc.
_>>>P.S. На самом деле лично мне вообще то совсем не принципиален размер хранилища, просто этот вопрос всплыл в контексте сравнения эффективности внутренней архитектуры этих двух систем. _>·>"Меньше места" не единственный эффект более продуманной архитектуры. Это так же даёт перформанс, простоту алгоритмов. _>Ну для начала с "много места" мы ещё и не разобрались. И кстати говоря у всех подходов есть свои недостатки. Даже если взять за основу идею с repack'ом, то помимо проблем с расписанием данной работы, данная техника к примеру блокирует возможность инкрементальных бэкапов хранилища.
Не блокирует. Просто иногда после repack придётся новые паки бэкапить, старые удалять, вот и всё. А вообще не проще ли --mirror использовать или тупо rsync?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, netch80, Вы писали:
N>Если авторы не в состоянии отработать с точки зрения даже простейший сценарий использования, как можно предлагать использовать их творение?
Резюмирую твои проблемы и вопросы: ты просто не прочитал документацию
Гит в этом плане еще хуже, там нормально пользоваться нельзя пока ты досконально не прочитаешь хотя бы git-scm book.
Вообще то что по использованию гита книги пишут уже хороший показатель "удобства" инструмента. Тот же svn я пользовал из под гуя несколько лет и только пару раз заглядывал в документацию. Просто не было необходимости такой. По гиту то и дело лезу то на стек, то в handbook, то в гугл.
Здравствуйте, CrystaX, Вы писали:
N>>Ситуацию, когда в пределах одной рабочей копии status показывает изменение, а hard reset его не сбрасывает, это не даст. CX>Я подобное наблюдал, когда в репозиторий были добавлены файлы с разным содержимым, но именами, отличающимися только регистром.
Какая милая система... )))
Кстати, я помнится наблюдал ещё, что git (как и многий другой древний линуксовый софт) до сих пор ломается на каталога с пробелами в именах. ) Это вообще жесть и убогость. )))
Здравствуйте, willie, Вы писали:
W>Здравствуйте, vovkab, Вы писали:
V>>Нормальное код ревью подразумевает нормальную историю и комиты в которых нет лишнего. А для этого надо уметь нарезать и потом перенарезать комиты.
W>Нарезать и перенарезать это лишнее. Уши этого "мастерства" торчат из неудобств гита, где при наличии коммитов с месседжами "quickly fix " или "save state" ты хрен разберешься что имелось в виду.
Такие комиты не пройдут код ревью, так что их по определению нет.
V>>Если у тебя есть бранч как в меркуриале то тебе в общем-то пофиг что там внутри, ты оперируешь макро изменениями, а не микро. Разработчикам удобно работать, можно хоть 100 раз коммитить полуготовые файлы перемежая с полноценными коммитами. И изменения не теряются, и всякой фигней вроде git stash пользоваться не надо, и историю "вдумчиво переписывать" не надо сидеть. Ты просто работаешь как тебе удобно, а vcs тебе в этом помогает.
И как это отличается от гит?
Хоть 100 комитов невнятного содержания сделай, пока работаешь над фичей, это твоя локальная песочница.
Другое дело когда ты готовишь код на ревью, там будь добр привести код и историю в порядок.
И потом позже во время код ревью нужно будет вернутся и поправить комиты.
В общем на сколько я вижу, тут проблема не столько в гите, сколько в организации процесса разработки, которого нет.
Здравствуйте, Dair, Вы писали:
D>и... моих изменений нет вообще. Ни одного. Пять коммитов. День работы насмарку. Отличный Git
Без паники. Твои обновлённые файлы, деревья и коммиты уже стали объектами локального хранилища. Даже если каким-то образом ты потеряешь все указатели на них — у них всё равно ещё есть достаточный срок годности, в течении которого GC их не тронет.
Здравствуйте, netch80, Вы писали:
_>>Разная идеология понятия "ветка". N>Вот я _обожаю_ такие высказывания. Как только возникают вопросы про конкретные особенности веток — начинаются рассказы про "идеологию". "У нас тут своя атмосфера", видите ли. При этом ничего конкретного по сути вопроса не говорится, ссылка на идеологию всё спишет.
Разница очевидна. В git ветка — это что-то временное, а в mercurial ветки остаются навсегда в истории.
_>> И на мой взгляд для нормальной контролируемой команды (а не стихийного опенсорса) подход Mercurial правильнее. Да, кстати, вариант веток в стиле git'a там тоже имеется (называется bookmarks), но вроде не пользуется особой популярностью. ))) N>Отлично. Вот у меня сейчас получилась вот такая вот картинка: N>... N>Хорошо видно, что "branch: x1" написано на двух коммитах из разных веток (цепочек из коммитов, a.k.a. changeset'ов)? Простите, это из какой такой идеологии "бранчем" именуется нечто, что может перескочить между реальными ветками разработки? Теперь ветки — это не те ветки, а не те ветки — это ветки?
Покажи к чему приведут аналогичные действия в git'e и мы вместе посмеёмся. )))
О, кстати, ещё один практический нюанс вспомнился... Работа с автоматическими анонимными ветками намного удобнее в Mercurial. Собственно не помню как вообще в Git с ними работать (скажем аналог команды heads?).
_>>Ну вообще то я говорил не про набор хуков, а про удобство расширения. Но даже если говорить про набор, то помнится в git'е раньше не было многих. Например preoutgoing и т.п. Сейчас не знаю, не смотрел, может и добавили. N>Почитал про preoutgoing. Смысла не понял. Заодно прочёл, что в нём ничего не известно и что он не зовётся при push, хотя зовётся при передаче в другое репо. Какая-то совсем вещь в себе, или опять та трава, которая не та трава.
Полезно для создания нестандартных каналов передачи (скажем с шифрованием и т.п.).
_>>По умолчанию фиксируются все модифицированные файлы и это намного удобнее (т.к. это самый частый вариант использования), чем каждый раз писать "-a". Если надо зафиксировать изменение не всех файлов, то точно так же как и в git передаётся список в команду commit. Лично я же в таком случае предпочитаю снимать галочки в TortoiseHg. ))) N>А часть одного файла?
Эээ, что что? )
N>Под Git я лучше алиас напишу типа "aa = add -A", если мне такое потребуется. Пока что не требовалось, я категорически считаю, что если это не какой-нибудь скрипт типа etckeeper, то добавлять все безусловно — диверсия, а если такой скрипт, то он сам сможет вызвать даже с длинной опцией. Считаю это умолчание "не сказано — значит все" грубейшей диверсией.
Ну я же говорю, что дело вкуса. Кто-то любит удобство по умолчанию, а кто-то любит вписывать все детали сам. А при использование из нормального GUI (кстати как раз с этим у git были большие проблемы, но сейчас вроде как частично исправилось) вообще разницы нет какой dcvs пользуешься. )))
_>>Да, что касается формального сравнения разных команд... Я никогда об этом специально не задумывался, просто интуитивно чувствуется удобство в определённых случаях (потому и говорю что дело вкуса). Но вот сейчас решил чуть задуматься. Как там в git'e скажем насчёт аналога команды hg incoming? N>Делается через fetch+diff. А какой смысл в команде в таком виде, как в hg? На каждый вызов выкачивать список изменений, показывать их, но не сохранять локально? А если два вызова, оно в состоянии это закэшировать? Юзкейс совершенно непонятен.
Смысл в том, что просматриваемые изменения не попадают в твой репозиторий. Конечно можно потом извратиться и выкинуть их оттуда, но это уже лишние сложности.
N>И пока что я вижу в hg в основном такие хохмы. "Ветки", которые не ветки. "Закладки", которые тем не менее держат на себе состояние репо, хотя по смыслу названия они должны быть просто тегами. Команды с непонятным юзкейсом и заведомо неэффективным стилем исполнения. Зачем всё это?
Да да, вот у меня такое же впечатление от git. ) Вроде как вся базовая функциональность имеется, но всё как-то через задницу. )
Здравствуйте, netch80, Вы писали:
N>Разница в том, что в Git при ветках, которые ветки, правила просты и логичны. В Hg разрыв между нормальным пониманием ветки и тем, что там называется этим словом, приводит к бардаку. Если переименуете на другой термин, который не конфликтует с языком, часть жалоб уйдёт.
Ещё раз поясняю: в mercurial как раз самые нормальные ветки, просто ты не разобрался. Например ты почему-то считаешь ветками только именованные, созданные с помощью специальной команды (как в git), в то время как в Mercurial любое разветвление (создаваемое автоматически при наличие двух разных изменений относительно одного родительского) является ветками. Причём с ними можно полноценно работать со всеми удобствами.
N>>>Опиши желаемое подробнее, не понимаю. _>>Ну очевидно же) Фиксируем некие изменения, потом откатываемся назад на одну ревизию, N>Как именно откатываемся? Вообще удаляем последнюю ревизию или сохраняем?
Естественно сохраняем и собираемся потом использоваться (возможно ещё пару изменений там добавим, а потом сделаем слияние).
_>> Кстати, аналогичного можно добиться и проще (как раз более практичный вариант) — фиксация своих изменений несколькими разработчиками в одну и ту же ветку, с последующей синхронизацией. N>Пофиг, как ветка называется у каждого конкретного разработчика, важно, в какую в общем репо они вливают (и с какой мержатся).
Зачем нам лишняя сущность типа третьего репозитория? ) Для работы двух разработчиков вполне достаточно их двух локальных. Но если ты так хочешь, то можно и с 3-им. И да, используем одну ветку (с одним названием).
Кстати, в режиме по умолчанию Mercurial синхронизирует сразу все ветки в репозиторию. Это так, к сведению. )
_>>Что будет в таком случае в git и как с этим удобно работать? ) N>Я продолжаю не понимать вопроса. Первый встречный вопрос: то изменение, которое было последним вначале, оно должно быть сохранено или нет?
Ответил выше. )
_>>В Mercurial всё будет крайне удобно и это собственно один из нормальных сценариев работы. N>В Git всё будет "крайне удобно", но после того, как ты наконец объяснишь, чего ты именно хочешь и зачем.
Ну сейчас увидим как удобно будет. )
_>>Ужасы какие) Как раз для таких дел и создают отдельные ветки (отладочная, релизная и т.п.). N>При чём тут вообще какие-то отдельные ветки? Описанные проблемы и методы решения не зависят от того, это develop, old stable или что-то ещё.
Ну если тебе требуется наличие в репозитории двух версий одного кода, одну с отладочной печатью, а другую без, то это как раз удобнее делать через ветки. )
Здравствуйте, koandrew, Вы писали:
K>Вот потому он и не нужен™
Не, почему? Пока используешь gitflow (sourcetree и студия умеют) или любой другой расписанный местным гуру процесс — всё более-менее ок.
Хотя лично я предпочитаю не страдать без необходимости и просто поставить svn. Для команд до 10-20 активно коммитящих человек он точно удобнее.
Во всяком случае в последний раз с ситуацией "необратимо испорчена рабочая копия svn" (не сам репо) я сталкивался где-то в 2007м,
с ситуацией "а что, не надо было делать rebase?" — где-то с год назад.
Здравствуйте, Sinix, Вы писали:
S>Хотя лично я предпочитаю не страдать без необходимости и просто поставить svn. Для команд до 10-20 активно коммитящих человек он точно удобнее.
D>Консольный Git, 2.6.0
Неужели под виндой
D>и... моих изменений нет вообще. Ни одного. Пять коммитов. День работы насмарку. Отличный Git
Совет: Никогда, никогда не делай rebase пока не заучиш GitMagic наизусть на оригинальном языке.
Впрочем когда заучиш, тоже делать rebase его не стоит.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>И конечно же работая над фичами локально я мог использовать Git'овские ветки, даже при основном SVN — это удобно.
У меня когда-то такой бутерброд был очень выгоден при CVS наверху
EP>ЕМНИП, у меня локальный Git репозиторий (со всеми коммитами!), был меньше чем локальный checkout SVN.
При малой истории и большом объёме рабочей копии это очевидное следствие того, что SVN хранит в pristine/ неизменённую копию каждого файла согласно текущей версии, а Git сжимает их.
Здравствуйте, 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. Есть свои проблемы, в частности уже пару раз ломал репозиторий, что приходилось пересоздавать с нуля (хотя может можно было и починить, нз), но в целом ощущения от использования этой VCS очень приятные. Всё чисто, понятно и логично.
Пользоваться меркуриалов по сравнению с гитом всё равно что программировать на питоне вместо си.
Хайпа вокруг гита не понимаю. Ладно самое красноглазное подмножество линуксоидов-ядерщиков в своём мирке юзают что им удобнее (белоглазые же линуксоиды, я слышал, почётно восседают на bazaar), но гит с хрустом начинают жевать маководы и виндузятники (к коим отношусь и я), с улыбкой гарольда-скрывающего-боль нахваливая и зазывая всех присоединиться к их клёвым проектам, худо-бедно выложенным на модный нынче гитхаб (но которые почему-то так и не получают должной популярности), я в недоумении развожу руками.
Здравствуйте, D.Lans, Вы писали:
DL>Вот поэтому я и пользуюсь Mercurial. Есть свои проблемы, в частности уже пару раз ломал репозиторий, что приходилось пересоздавать с нуля (хотя может можно было и починить, нз), но в целом ощущения от использования этой VCS очень приятные. Всё чисто, понятно и логично.
А, то есть поломка репозитория в 0 это логично.
DL>Пользоваться меркуриалов по сравнению с гитом всё равно что программировать на питоне вместо си.
Попробуем-с.
$ hg init
$ echo 1 > a
$ hg add a
$ hg ci -m a=1
$ echo 2 > b
$ hg add b
$ hg ci -m b=2
$ hg log
$ echo 3 > a
$ hd add a
a already tracked!
Это что, я теперь должен говорить hg ci с явным списком файлов?
А если их десятка два, которые надо отобрать среди 60 изменённых, я должен имена всех файлов писать?
А если мне не все изменения из конкретного файла надо отобрать, только часть?
Кстати, я раскомментировал pager в extensions, а hg help log и аналогичные команды продолжают плеваться на экран полным текстом за раз. Почему?
DL>Хайпа вокруг гита не понимаю. DL>я в недоумении развожу руками.
Есть такие понятия — удобство, логичность, соответствие ожидаемому. Наконец, банально современные возможности, а не уровень CVS, как в случае с этим add.
Здравствуйте, D.Lans, Вы писали:
DL>Хайпа вокруг гита не понимаю. Ладно самое красноглазное подмножество линуксоидов-ядерщиков в своём мирке юзают что им удобнее (белоглазые же линуксоиды, я слышал, почётно восседают на bazaar), но гит с хрустом начинают жевать маководы и виндузятники (к коим отношусь и я), с улыбкой гарольда-скрывающего-боль нахваливая и зазывая всех присоединиться к их клёвым проектам, худо-бедно выложенным на модный нынче гитхаб (но которые почему-то так и не получают должной популярности), я в недоумении развожу руками.
ЩИТО? Откуда вы такую траву взяли?
Я не понимаю сторонников hg. Они массово не понимают как вообще работают DVCS. Git вообще тупой как пробка, там сложного нет ничего. Банально достаточно запомнить, что коммиты образуют цепочку хэшей и всё.
Достаточно уметь это понимать, и всё в git становится понятным.
Здравствуйте, alex_public, Вы писали:
_>Трудно читать на украинском) Хотя смысл угадывается конечно. )))
Если ты не в Китае или ещё каком медвежьем углу, есть Google Translate. Навязывать свой вариант перевода я не хотел.
_>Из существенных претензий тут только пункт с close-branch. Если бы он был правдивый (тут уже вроде всё показали на эту тему).
Не-а. Из существенных тут невозможность узнать в любой момент, что в staging. Вот это действительно очень серьёзный злобный фактор. А работа веток, которые не ветки, тут действительно мелкий фактор.
_>А чем по твоему отличаются расширения входящие в поставку Mercurial от обычных команд? ) Лично я не вижу вообще никакой разницы.
Тем, что их ещё включать надо. Значит, авторы считают, что по умолчанию они не нужны. А это как раз показывает, на какой вариант они сами рассчитывают и что пропагандируют. Если возможность изменить уже зафиксированный коммит это для них что-то необычное, то это не нормальная работа, а грязнокодинг.
N>>2. Диверсии в виде неименованных голов, наоборот, вынести в расширения и не включать по умолчанию. _>Как ты себе представляешь отключение по умолчанию базовой функциональности, вокруг которой и строится вся система? )))
Она не базовая. Базовая это цепочки коммитов. А фиксация безымянных голов это уже расширение. И это ещё раз показывает следствия безумного бардака с терминологией.
_>Возможно допилят (я же говорю, что технические возможности систем сходятся постепенно). Хотя лично я и все мои окружающие вообще не пользуются командой record, даже в таком виде. Собственно большинство вообще из IDE работает, где это всё неактуально.
IDE не рассматриваем тут принципиально.
N>>4. Решить остальные описанные Lyubomyr Shaydariv проблемы. Для начала, _>Причём тут изменение хэша ревизии? ) Я вообще про другое говорил. Что предпочитаю подход в котором всё, что попадает в систему контроля версий, уже навсегда остаётся в истории.
Это называется наплевательством на качество результата. Я не могу принять ни такой стиль, ни следствия в виде "нефиг менять, раз однажды закоммитил" для *VCS.
Здравствуйте, alex_public, Вы писали: _>·>Как ты branch переделаешь в bookmark? _>·>Ты говоришь, мол это для короткоживущих, это для долгоживущих... Как ты это определяешь? Ты знаешь будущее? Я не ясновидец, я не умею и не хочу думать об этом выборе. Почему это должно отличаться? _>Зачем переделывать одно в другое? ) Они же все совместимы между собой. Собственно их так обычно и используют. Вот нужна тебе долгоживущая ветка — устанавливаешь имя. Требуется мелкое ответвление в ней — используешь анонимные ветки (правда в данном случае они на самом деле будут не анонимные, а просто с совпадающими именами изначальной). Хочешь как-то выделить одну из этих анонимных подветок — ставишь на неё закладку. ) В общем всё полностью совместимо на любом уровне.
Опять. Почему меня должно волновать долго ли, коротко ли живёт ветка? Зачем меня ставить перед этим выбором? Какую пользу приносит это решение? _>>>·>Расхождение должно появиться только в том случае, если я внёс изменение и в release_candidate, и в default, т.е. появилась ревизия с двумя детьми. А что собственно значит появилось расхождение — это значит, что появилась "альтернативная история", которую можно 3-way мержить. _>>>Ммм, так а ты объясни тогда зачем в твоём сценарии создавать новую ветку и делать в ней пустую ревизию? _>·>А разве можно запушить ветку, если она не закоммичена? _>А что значит "запушить ветку"? ) И зачем это надо? )
Опубликовать в удалённый репозиторий, или, что аналогично, затащить (fetch) из удалённого. Чтобы передать знание о том, что я решил считать релиз-кандидатом. _>·>Не знаю откуда ты берёшь это "формально", в официальной документации это называется named branch, "именованная ветка". Да и команды, работающие с ними "hg branch", "hg branches". "--branch". _>Да, имена команд тоже неудачно вышли, хотя понятно что это так для краткости. Но тут вообще непонятно как было правильно назвать.
Ну "label", ну "tally", например. Или, как в gerrit — "topic". Ещё более кратко — на одну букву короче, а смысла на порядки больше. _>Смотри, тут есть: _>- ветки. Это которые мы в данной дискуссии называем анонимными (хотя на самом деле это неверно, т.к. у любой из них на самом деле есть имя (default или какое-то другое), просто оно может совпадать с именем соседней ветки). _>- имена веток. Просто атрибут у каждой ревизии.
Жуткий бардак в терминологии, Оккама не позвали. _>Так вот команды hg branch и т.п. работают как раз с именами веток, так что теоретически должны были бы называться как-то типа branch_name и т.п. Но это же тоже бредово... )
Бредово, т.к. с твоей верой не согласуется... _>·>Я не понимаю что ты подразумеваешь под нормально работать. Зачем вообще с анонимными ветками работать? Особенно в случае, если с именованными проблем никаких. _>Это уже отдельный вопрос (который мы вроде как тоже параллельно обсуждаем). Но вне зависимости от его результатов у нас останется тот факт, что в Git отсутствует имеющаяся в Mercurial возможность работы с анонимными ветками.
Она отсутствует, т.к. не нужна, не существует сценариев работы, которые дадут анонимную ветку. Если бы кому-то была нужна, добавили бы, т.к. элементарно. _>·>Эти проблемы, надеюсь, уже пофиксили? _>Хы, к mercurial там ровно две претензии: _>1. не позволяет подчищать репозиторий задним числом без особых манипуляций. Смешно, т.к. сохранности историй — это один из базовых принципов Mercurial.
Это базовый принцип CVCS, для DVCS этот принцип выражается как "receive.denyNonFastForwards". _>2. не позволяет сделать push закладки. Видимо автор не в курсе про параметр -B у команды push. )))
Ок, значит пофиксили. Хорошо. Если придётся использовать hg, буду использовать только букмарки. _>>>Собственно я ещё в самом начале дискуссии сказал, что данный вопрос больше дело вкуса. ) _>·>Хорошо, пусть дело вкуса. Но смысла уж точно нет. _>Вот не надо только пропагандировать тут подход Apple — в профессиональной среде он плохо проходит. )))
Вроде ты тут пропагандируешь — смысла нет, остаётся только дело вкуса. _>·>Не понял. В каком начале? Это текущий граф, текущая история. sequence может быть выражена как последовательность точек. Я поменял граф, обозначив точки уникально. Перечисли эти линии. _>Я так и не понял что ты хочешь))) Точнее не пойму чем тебя не устраивает мой ответ в первом же сообщение (много страниц назад). Ну да ладно, мне не сложно повторить в сотый раз, уже с буковками. ))) Последовательности ревизий: {a, b, c}, {d, e, f}, {g}, {h, i, j, k}.
Ок, допустим. Ты говорил, что последовательность ревизий это и есть ветка. Ты говорил, что hg позволяет хорошо работать с ветакми. Какой командой мне вывести эти четыре ветки для этого графа истории? _>·>В hg об Оккаме и не всмоминали: помимо "именованных веток" ввели сущность "анонимные ветки" и прочие закладки с головами. _>·>Мне вообще интересно, опиши сценарий: откуда в git появится ревизия на которую нет ссылкок и что ты с ней хочешь делать, для чего она тебе может понадобится? _>Ну вот работаю над каким-то проектом, решил проверить некое решение, закодировал, убедился что оно сейчас не подходит (но код полезный и пригодится в будущем), зафиксировал его в виде ревизии, откатился назад на одну ревизий и пошёл работать дальше, создавая новые ревизии. При этом у меня там
останется маленький отросток (ветка из одной ревизии), который возможно когда-нибудь пригодится. _>Это я описал сценарий в Mercurial. А как оно будет в Git? ) Будешь создавать по каждому такому поводу отдельную ветку с новым именем? )
Конечно, в гите будет всё очень сложно. Поместил под кат длинный скрипт, чтобы не делать сообщение чрезвычайно очень длинным.
Тут этот офигительно сложный скрипт, который доступен только после двадцатилетних курсов изучения гит фулл-тайм на специальных платных курсах, дарю тебе бесплатно
git stash
Неужели в hg так нельзя?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Сколько себя не помню, официальный "Git for Windows" всегда ставился в "Program Files" или "Program Files (x86)" — проблем не наблюдал.
Этих гитов под виндос как собак развелось.
Каждый настраивается как бог на душу положит. Поди разберись кто из них официальный
Вообще отмазка про неправильный дистрибутив весьма характерна именно для линуксоидов. Позволяет бесконечно вилять задом от неудобных вопросов
Здравствуйте, willie, Вы писали:
W>У тебя просто юскейсы специфичные. Мне вот interactive-add ни разу не нужен был Даже без понятия был что это такое пока твое сообщение не прочитал.
Это же чуть ли на самая часто используемуя фича. Вы видимо не работали над большими фичами, либо нет нормального код ревью.
Правда руками я это не делаю, так как контекста мало. Но какой нить "gitx" или "git gui", справляются на ура.
Здравствуйте, willie, Вы писали:
W>Здравствуйте, vovkab, Вы писали:
V>>Это же чуть ли на самая часто используемуя фича. W>Для тебя да, для меня нет. Код править на лету — легче застрелиться. Поправил — прогнал тесты, закоммитил пошел дальше. Какой тут интерактив и зачем.
Что значит на лету? Что мешает прогнать тесты во время ребэйза? Или делать все эти изменения из иде?
V>>Вы видимо не работали над большими фичами, либо нет нормального код ревью. W>Как раз таки нормальное код ревью и подразумевает нормальные вдумчивые исправления кода. С подсветкой синтаксиса и рефакторингом на лету.
Нормальное код ревью подразумевает нормальную историю и комиты в которых нет лишнего. А для этого надо уметь нарезать и потом перенарезать комиты.
И снова причем тут ваш рефакторинг? Гит позволяет вам всего лишь управлять историей и состоянием кода. Ни кто не запрещает фиксить конфликты или делать изменения в иде.
V>>Правда руками я это не делаю, так как контекста мало. Но какой нить "gitx" или "git gui", справляются на ура. W>Нет, на ура справляется только IDE которая сможет подсказать не привели ли твои интерактивные изменения к ошибкам. Опечатался в названии или забыл обновить где-то имя переменной.
Пример, у тебя большая фича и что бы ее сделать надо выполнить несколько рефакторингов, будешь все в один комит пихать?
А если комиты уже есть и надо их подправить, например, опечатку сделал? Или измельчить пиар что бы твоим товарищам проще ревьювить?
W>Может я конечно не совсем понял что имелось в виду под самой используемой фичей и как именно ее использует автор. Но посмотрев бегло скринкасты на трубе могу сказать что это ужас пользоваться в середине 2010-х такими инструментами как консольный git interactive[add,rebase,whatever] это мазохизм
Я считаю что и не надо делать этого из консоли, используй что удобнее.
Здравствуйте, willie, Вы писали:
w> V>Использовать номер тикета в комите? w> 1) Я не хочу его вписывать руками w> 2) Я не хочу его видеть в git log w> 3) Я хочу полноценное название ветки, а не номер какого-то тикета w> Номер тикета в коммите это костыль. w> W>>Но мне интересно именно отслеживать как кто-то пилил что-то. w> V>Код ревью с пул реквестами не достаточно? w> Мы не на гитхабе работаем. w> V>Как то вы сами себе противоречите w> В чем?
Здравствуйте, willie, Вы писали:
W>Здравствуйте, vovkab, Вы писали:
V>>Вы написали что все время косячите при создании комитов, я вам написал один из сценариев как сделать что бы все было железно.
W>Это не косяки, с чего ты взял-то. Важен момент мержа ветки, а не ее внутренние состояния. В околоисследовательских и научных проектах одно из этих состояний может вдруг резко понадобиться чтобы обкатать отброшенную ранее идейку на новых входных данных.
Изменение должно иметь смысл и фиксироваться комитом. Если ты изменил одно и тоже несколько раз в течении локальной истории, значит это должно быть объединено.
V>>С какого перепугу что то поломается? V>>Ну потянул ты мастер/дев, чего в друго в твоем бранче что то сломается? V>>Ну сделал ты ребэйз поверх мастера, опять же ничего не поломается.
W>Ну ты почитай почему в dcvs считается табу history rewriting удаленного репозитория с которым синкаются другие. И зачем придумали команду revert
Не путай локальную работу и комиты в паблике.
Пока ты в своей песочнице можешь делать что хочешь.
? W>Всегда бесила работа с ветками в гите которые были удалены.
В Maercurial для работы с ветвлением можно использовать один из трёх (а можно и все вместе кстати) инструментов: анонимные ветки, именованные ветки, закладки (практически полный аналог веток git'a). Так вот, если использовать за основу именованные ветки, то это полностью решает описанную проблему.
Здравствуйте, netch80, Вы писали:
_>>- проблема с сохранением истории в git. В mercurial всегда можно найти источник проблемы, а в git'е далеко не всегда. N>Совершенно непонятно. Что есть "проблема" в данном случае? Источник конкретного изменения? Ищется по истории без проблем, на каждую версию строчки или бинаря есть id коммита, из которого она возникла. Развилки? Они существуют во всех DVCS.
Даже если забыть о "низкоуровневых" возможностях правки истории в git, то остаётся ещё главное — разное понимание термина ветка. Вот https://habrahabr.ru/post/123700/ известный пример на эту тему.
_>>- возможность получить гигабайтный патч при слияние веток в git. N>Любое слияние отражает дифф с исходными версиями. "Гигабайтный патч" означает сведение существенно несовместимых вариантов. Проблема общая для всех DVCS, но в случае Git имеем один из лучших, испытанный на практике, мержер.
Нет, всё зависит от способа работы с данными. Тут как раз это и обсуждали выше, называя реализацию git'a более технически совершенной. Однако у всего есть обратная сторона...
_>>- проблема с кодировками в путях. Надеюсь хоть это уже исправили? ) N>Этой проблемы никогда не было у Git. Имя объекта это NUL-terminated строка байт, даже понимание этого имени как пути уже является свойством внешнего слоя, а не ядра. N>Если она есть у Windows, то это проблема кодировок Windows и конкретных реализаций Git клиента. Бардак с кодировками (ANSI/OEM/Unicode) в Windows такой, что я всегда забывал, что в них где, через 5 минут после того, как разобрался.
Проблема не у windows (проблемы будут и в линухе), а именно у git'a при работе с ним из разных ОС. Да, возможно это правильно называть проблемой "конкретных реализаций git клиента"... Но собственно это же и есть сам git (у него нет никакой обязательной серверной части).
Самое забавное, что различные GUI-оболочки/IDE устраняют эту проблему, передавая в git данные в каком-то одном формате. Что мешало сделать это банальное исправление в самом git — непонятно.
_>>- слабая работа с хуками и другими расширениями в git N>Мне не с чем сравнивать, но вопрос в том, насколько реально нужна "сильная" в твоём понимании, и насколько она логична.
Не понял про что ты спрашиваешь) Про нужность хуков и расширений вообще в dcvs или же про удобство их реализации в Mercurial? Если про второе, то достаточно сказать про возможность реализации на уровне внутреннего вызова кода на Питоне.
_>>- заковыристая система команд (субъективно конечно, дело вкуса, но такое мнение можно частенько услышать) в сравнение с другими dcvs. N>Система команд очень удобна из логики "если действие с базовой концепцией X, команда будет называться X".
Ну я уже сказал, что это дело вкуса, а не технический вопрос. ) Но мнение что система команд mercurial удобнее своего аналога из git'a я видел неоднократно. )
Здравствуйте, Dair, Вы писали:
D>Диспозиция: я в своей ветке, наменял разного, делаю коммит (не push) и готовлюсь взять последюю версию от коллег из develop, чтобы не сильно отставать. Для этого надо мне тут сделать commit, переключиться на общий develop, сделать pull,
Нафига???
git fetch origin develop:develop
Никак не зависит от текущей ветки, состояния рабочей копии и т.п., если текущая ветка не develop.
D> переключиться обратно, сделать merge. Делаю:
D>$ git reset --hard D>$ git status D>... D> изменено: some/path/file1.cpp D> изменено: some/path/file2.cpp D> изменено: some/path/file3.cpp D> изменено: some/path/file4.cpp D> изменено: some/path/file5.cpp D>... D>[/code]
D>И вот тут я не понимаю что делать.
D>Проверил сторонние процессы — никого нет, никто к файлам не доступается.
Слушай, а у тебя с RAM, шиной и т.п. на данном компе всё в порядке?
Ничем иным я объяснить подобные чудеса на сейчас не могу, кроме как битым железом.
Здравствуйте, Mazenrab, Вы писали:
AK>>я почему интересуюсь, для меня, как C# программера — это базовая операция — переименование класса (class per file). M>На днях натыкался — есть такая проблема.
Да нет такой проблемы, открой для себя "git log -M" или ещё круче — "git blame -C", который может найти, например, перемещённый метод из одного файла в другой (такого в hg вроде нет).
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, netch80, Вы писали:
_>>Ну как видишь никаких ограничений нет на самом деле (и я кстати об этом говорил изначально). Есть только разница в удобстве (причём в пользу Mercurial). Люди даже подобные https://www.mercurial-scm.org/wiki/GitConcepts#Command_equivalence_table таблички соответствия команд делают. ))) Но опять же там есть не все команды (например нет heads) из-за отсутствия в конкуренте соответствующей концепции (типа анонимных веток). N>Вот тут на родственном форуме (если ты в РФ, то без Tor не прочтёшь) коллега Lyubomyr Shaydariv пишет (месяца 3 назад, так что актуально):
Трудно читать на украинском) Хотя смысл угадывается конечно. )))
N>... N>Заметь, человек для себя предпочитает Hg, но его подобные грабли таки достали. Я до такой глубины ещё даже первично не докопался.
Из существенных претензий тут только пункт с close-branch. Если бы он был правдивый (тут уже вроде всё показали на эту тему).
_>>Ну и зря. Если лично тебе оно не нужно, то это не значит что и другим тоже. Я знаю многих использующих Mercurial вообще без named branches/bookmarks и при этом очень довольных удобством работы. N>Это несекьюрно, годится только для персонального репо, который ни с кем не обменивается. N>Лучше это было бы перенести в extensions и не включать по умолчанию.
Как раз использовали для совместной работы. Правда небольшими командами (в крупных и формализованных командах всё же уже требуются именованные разделители какого-то вида). Очень удобно.
_>>Ох, ну я же ещё в самом начале этой дискуссии писал, что за годы параллельного развития все современные dcvs обрели приблизительно одинаковые технические возможности (ну вот разве что git так и не научился по нормальному анонимным веткам) и выбор должен делаться только по удобству (достаточно субъективная вещь) их использования. Ну если хочешь, можем разобрать по пунктам. ) N>Ну да, теперь осталось сделать совсем немного мелочей: N>1. Внести такие действительно полезные вещи, как shelve, record, histedit, rebase в базовую функциональность, а не расширения.
А чем по твоему отличаются расширения входящие в поставку Mercurial от обычных команд? ) Лично я не вижу вообще никакой разницы.
N>2. Диверсии в виде неименованных голов, наоборот, вынести в расширения и не включать по умолчанию.
Как ты себе представляешь отключение по умолчанию базовой функциональности, вокруг которой и строится вся система? )))
N>3. Описанным расширениям довести функциональность до минимально необходимого набора: N>* показ staging, сброс staging в ноль, частичный сброс (по файлу, по диффу). N>* shelve должен уметь брать не только локальные изменения, но и staging.
Возможно допилят (я же говорю, что технические возможности систем сходятся постепенно). Хотя лично я и все мои окружающие вообще не пользуются командой record, даже в таком виде. Собственно большинство вообще из IDE работает, где это всё неактуально.
N>4. Решить остальные описанные Lyubomyr Shaydariv проблемы. Для начала, переименовать таки "ветки" во что-то другое (покопался в словаре, нашёл замечательное слово tally). Далее, обеспечить возможность их делать неуникальными (а лучше вообще не опираться на "закрытие", эта концепция должна умереть). Решить остальные описанные им проблемы.
Это вроде уже обсудили. )
_>>В Mercurial это тоже реализовано, через команду hg histedit. Однако я крайне не рекомендую использовать этот подход, т.к. правильным методом review в DCVS должно быть создание новой ревизии. N>Я проверил — histedit меняет хэш ревизии, так что тут, похоже, сделано адекватно (как в Git, Monotone и прочих, где хэш гарантированно требуется проверяемым по содержанию конкретной ревизии). А вот то, что ты этого не знаешь, и то, что я про histedit вытащил только после долгой дискуссии, показывает, что твой опыт просто неприменим под мои задачи и подходы.
Причём тут изменение хэша ревизии? ) Я вообще про другое говорил. Что предпочитаю подход в котором всё, что попадает в систему контроля версий, уже навсегда остаётся в истории. Поэтому мне и имена веток в Mercurial больше нравятся и команды типа histedit я не использую в принципе.
Да, кстати, а вот тебе похоже должен был бы понравиться этот https://www.mercurial-scm.org/wiki/MqTutorial инструмент. Он кстати пока входит в поставку, но обсуждается вопрос его удаления... )))
_>>Тут и наличие анонимных веток и их поведение при синхронизации (они просто все возникают у всех) N>Я уже говорил, что в Git ты можешь потребовать синхронизации полного пучка веток, но по умолчанию это отключили в 2.2.
Я не об этом (тут понятно что всего лишь опция команды), а про то, как чужие ветки выглядят в твоём репозитории. )
_>>Я вот здесь http://rsdn.ru/forum/flame.comp/6338865.1
приводил картинку того, что имею в виду. Предположим что ревизии 2 и 3 созданы на разных компьютерах. Как бы ты реализовал подобное с помощью git? ) N>Очевидно — fetch+merge. Если ты хочешь сказать, что тебя утомляет необходимость назвать принятую от другого ветку, то я могу только выразить соболезнования, но не согласиться.
Нуу покажи пример. Что бы git log --graph показал картинку аналогичную той моей (причём в каждом из двух репозиториев). И при этом прикинуть объём команд необходимый для этого. Могу сделать аналогичное для mercurial. )
Здравствуйте, alex_public, Вы писали:
_>>>Ну так это только в git надо корёжится (не допускать gc, непонятным образом искать id и т.п.), а в mercurial это всё идеально удобно. N>>Если хочешь дальше общаться, прекращай это НЛП в виде регулярной мантры "идеально удобно", или я просто прекращу обсуждение и буду считать тебе техническое поражение. Надоело. Или мы говорим проверяемыми аргументами без вкусовщины (во что входит соответствие общепринятым терминам и распространённым практикам), или мне такое не подходит. _>Вообще то как раз только что я и сделал попытку количественного анализа данного субъективного вопроса — предложил сравнить необходимые команды в разных системах для реализации одной и той же задачи. Однако ты её проигнорировал, без внятного объяснения.
Что ты называешь этой задачей? Проведение развития пучка веток без явной маркировки голов названиями веток? Я объяснил уже, почему считаю это не просто бесполезным, но и вредным. Поэтому решение этой задачи я в принципе не рассматриваю.
А вот та задача, на которую должна быть оптимизирована любая DVCS, в основе формулируется следующим образом. Имея некоторый проект (неважно, public/private, opensource/закрытый), выполнить задачу (добавить фичу, полечить баг, whatever), для чего
а) сделать копию репо, если ещё нет
б) отделить в явном виде конкретную работу (что означает её таки назвать, потому что при >=2 таких начинаешь путаться, что где делаешь, а от 4 средний программист совсем потеряет понимание)
в) в процессе работы, войдя в контекст, генерировать последовательность коммитов для её решения (причём, если это совместная работа, каждый коммит сам по себе должен быть, как класс в SOLID, прост, понятен и решает ровно одну цель)
в2) при необходимости, порождать подзадачи и вести их решение отдельно, потом возвращаясь вверх;
г) иметь удобную (что бы это ни значило) возможность в процессе объединения решения с другими производить адаптации уже сделанного
д) в процессе code review иметь возможность обрабатывать замечания, причём к не-последним коммитам
е) иметь удобную (опять же, не уточняем пока детали) возможность иметь локальные изменения, которые остаются только локальными
ж) в следствие экспорта изменений другим, они не должны выглядеть для них принципиально "чужеродными", приходить предельно лёгким путём (любым из) и естественно ложиться в локальные репозитории
А теперь смотрим на Hg, имея в виду сравнение одновременно с CVCS (CVS, SVN) и Git (согласно моему опыту работы больше, чем на сделать пару мелких тестов):
(а) — проблем нет; для CVS, SVN меняется на checkout рабочей копии без репо;
(б) — для DVCS, требует какого-то вида бранчевания (если не решается в один чих), но именованного под растущую ветку => для Hg это bookmarks; для CVCS — всё в рабочей копии, если нет центрального решения выделить под это ветку;
(в) — не проблема, если реализация изначально идеальна для момента коммита; если нет, упираемся в проблемы (г) и (д);
(в2) — решается в любой DVCS суббранчеванием, в CVCS клонированием рабочих копий;
(г),(д) — требует interactive rebase; считаем, работает только в Git;
(е) — требует stash и interactive-add (patch-add как вариант), или даже edit-add; везде, кроме Git, приходилось временно делать копию рабочих файлов, вырезать не запланированное на данный коммит, и потом возвращать;
(ж) — "дискардит" смысл в Hg'шных номерах коммитов в цепочке (как 0: в 0:32f5bb09 и тому подобных знаках), между репо работают только хэши как идентификаторы; в CVS и SVN работает, пока нет конфликтов; конфликты в SVN решаются легче, чем в CVS, но всё равно хуже, чем в Git; про качество решения конфликтов в Hg не в курсе.
Для меня самым ограничительным в плане выбора средств оказывается (е) — и он привязывает только к Git. Причём, были ситуации, что у конторы центральным средством был CVS, но локальное удобство заставляло использовать Git; даже лёгкий гимор на операции "после cvs update пришли обновления, их надо влить локально" оказывался терпимым. Также для того, чтобы было не стыдно смотреть на результат, почти всегда нужен (г).
Часть пунктов не ограничивает, но приводит к тому, что в Hg заморочка локальными фичами типа номеров ревизий (ж) и безымянными головами (б) тратит мозговые ресурсы.
_>Я понял твои мысли там. Но непонятно какое они имеют отношение к вопросу сравнения числа команд для решения конкретной задачки. У тебя какие-то претензии к такому подходу? )
Да. Я считаю бессмысленным сравнивать количество команд, пока не выровнены сами задачи и под идентичную формулировку для сравниваемых средств, и под собственно осмысленность и важность задач. После того, как мы приводим понятие ветки в адекват с общим пониманием и с необходимостью не иметь всякие безымянные головы, со стороны Hg остаются bookmarks и разница исчезает.
_>>>Ну а насчёт удобства... Про принцип Оккама не забываем! ) N>>И что он тут даёт в твою пользу? В мою вижу — появилась излишняя сущность "безымянные цепочки" с диверсионными последствиями. _>Как раз придумывание имени ветки, которая существует например только ради синхронизации — это и есть очевидно лишнее.
Если "синхронизацией" называется слияние с верхним репо — то или эта ветка как образец того, что зафиксировалось в верхнем репо, должна существовать всегда, или она не нужна — pull делает merge, pull+rebase делает rebase.
Если общая схема с изменениями от кого-то другого, то представь себе ситуацию, что он что-то меняет от точки истории, которая на 200 коммитов назад — ты в любом интерфейсе вначале будешь долго мотать, чтобы её найти, или он будет показывать растянутые линии. А если таких несколько, то уже начнётся постоянная путаница, где чьи изменения и что из них надо принимать. Идею оптимизации на набор двух символов я понимаю, но принять её как-то сложно.
Про security issues такой фичи я уже упоминал.
Здравствуйте, Dair, Вы писали:
D>Консольный Git, 2.6.0
D>и... моих изменений нет вообще. Ни одного. Пять коммитов. День работы насмарку. Отличный Git
А я вот уже более года юзаю TortoiseGit в паре с TotalCmd и никогда не было проблем.
Правда некоторые действия все же удобнее из консоли выполнять. Просто отображение списков это явно не для консоли. Тут нужен именно GUI.
Просто я в качестве развлечения разрабатываю прошивки под андройд. И пишу весь код на винде (просто без TotalCmd я как без рук), а собираю все на убунте. На убунте я в git выполняю только простейшие операции.
Здравствуйте, xvost, Вы писали:
D>>и... моих изменений нет вообще. Ни одного. Пять коммитов. День работы насмарку. Отличный Git X>1) все твои коммиты есть в git reflog
Спасибо, всё нашёл, всё ок. 10 минут паники, позорный пост на RSDN — оно того стоило
X>2) На сервере стоит принудительно включать запрет на force push — тогда гарантированно репозиторий на сервере никто не сломает
Годно, сейчас пойду читать, как это сделать.
Здравствуйте, koandrew, Вы писали:
S>>Кэп: гит не работает, если в команде есть хоть один человек, не изучивший мануал.
K>Вот потому он и не нужен™
После работы с такими коммерческими тулами как ClearCase, Synergy, Rational TeamConcert мне Git показался самым разумным что было изобретено в этой области. Особенно в плане написания интеграций с ним.
Здравствуйте, Dair, Вы писали:
D>Выводы команд я не писал. Вывод rebase вот:
[...] D>error: Your local changes to the following files would be overwritten by merge: 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
Ага. Вот на этой точке как раз надо было остановиться и разобраться, откуда такое возникло, а что оно не смогло, явно сказало.
Если эти локальные изменения были до rebase pull, то надо было тут выполнить stash и только после этого продолжать. И после всего pull — сделать stash pop и объединять новые изменения.
Вообще тут странно вот что — по умолчанию оно запрещает делать rebase при любых локальных изменениях файлов, то есть оно вообще не вошло бы в такой процесс, потребовав stash до запуска rebase pull. Это какие-то локальные настройки, что оно проигнорировало запрет? Что за версия git?
D>Сразу после этого я сделал git status, который мне выдал D>[code] D>перемещение в процессе; над aab25a5 D>Вы сейчас перемещаете ветку «develop» над «aab25a5». D> (все конфликты разрешены: запустите «git rebase --continue»)
Хм. Насколько я понимаю, вот это сообщение и дало идею запустить rebase+continue. Оно неверно, и вот это как раз тот момент, где git явно виноват. Всё-таки надо уточнить версию, насколько она старая.
N>>А это ещё зачем? Оно показало конфликт? Если нет, то какой к лешему continue? N>>Если да, то почему не разобрался с тем, что в конфликте? D>Нет, конфликт не показало.
Конфликт не показало, но оставило в промежуточном состоянии — вот это непонятно.
Резюмирую. Надо попробовать повторить на свежей версии и максимально чистом конфиге. Если повторится и вина не в хитрых локальных опциях — это таки серьёзный повод написать problem report — на провокационное поведение. Если нет — значит, залечили и вопрос в том, почему старая версия. Личная недоработка в понимании инструмента есть, но за счёт провокации она не 100% причина. Коммиты, как я понимаю, успешно восстановлены по reflog.
Ещё в будущем в случае потенциальных сложных слияниях сохранять локальное состояние как кратковременную ветку, не принципиально, но восстанавливать с неё удобнее, чем с reflog.
Гит от робота и для роботов. Способность "вернуть все взад" — принципиальная возможность систем контроля версий. Если это по каким-либо причинам не получается — на помойку.
Точнее, надо бы на помойку. На практике я понимаю, что это лучшее из того, что есть. Не знаю, как сейчас, но несколько лет назад Меркуриал был хуже.
S>Кэп: гит не работает, если в команде есть хоть один человек, не изучивший мануал.
Получаем, что при увеличении команды (а ведь Гит создавался именно для больших сообществ разработчиков) вероятность того, что он не работает, стремится к единице.
Программировать сложно. Но не программировать еще сложнее.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>С трудом верится, особенно вспоминая жёсткие roundtrip'ы при работе с SVN, даже на мелких репозиториях в пару сотен коммитов. Но хорошо если действительно так. EP>Я думал там тормоза принципиальные, из-за архитектуры.
Перепроверил, взял папку, которая редко менялась. История за четыре года выгреблась секунд за 10.
EP>Но, это же переход на старую ревизию или ветку может быть очень долгим, так? Например в целях поиска коммита внёсшего баг, а-ля git bisect.
Неа. Если чекаут уже сделан — минуту-две, это на относительно свежие ветки. На старые, там где несколько десятков тысяч файлов перекачать приходится — да, минут десять может занять.
Если надо в нескольких ветках одновременно работать, то проще всего сделать пару копий, одна — для основной разработки, вторая — для отрезания релизов/воспроизведения багов и тд и тп.
EP>Например в целях поиска коммита внёсшего баг, а-ля git bisect.
Вот ни разу так не приходилось извращаться. Blame или просмотра истории хватает за глаза.
Здравствуйте, Mazenrab, Вы писали:
M> А еще я умудрился сломать локальный репозиторий в гите буквально на второй день Причем что с ним до сих пор не понимаю. Гит говорил что вообще все файлы в репозитории модифицированны. При этом при побайтовом сравнении с предыдущим коммитом разницы не было.
Здравствуйте, netch80, Вы писали:
_>>Текущая ревизия — это понятие глобальное на все файлы, т.е. относится к хранилищу. N>Оно не относится к хранилищу. Оно относится к состоянию рабочей копии. Хранилище при этом не меняется, как бы я ни двигал, какой именно коммит текущий выбранный.
И где в рабочей копии по твоему тогда хранится информация о том, к какой ревизии она относится? )
_>>P.S. Что-то ты в этой темке прямо разошёлся (хотя ничего по делу я так и не увидел, правда и не рассчитывал: выбор между git и mercurial — это реально дело вкуса), N>Когда (см. соседнее сообщение) меня какая-то тулза заставляет переопределить давно устоявшиеся, стандартные по отрасли понятия — это уже не обычное дело вкуса, это bdsm.
С чего ты взял, что давно устоявшиеся? ) Git/Mercurial/Bazaar родились в принципе одновременно и все три могут претендовать на основоположников терминологии. Если же говорить о реально устоявшихся, то это будет скорее SVN и более старые системы — как думаешь, к какой из DVCS их терминология будет ближе? )
Здравствуйте, alex_public, Вы писали:
_>>>Разная идеология понятия "ветка". N>>Вот я _обожаю_ такие высказывания. Как только возникают вопросы про конкретные особенности веток — начинаются рассказы про "идеологию". "У нас тут своя атмосфера", видите ли. При этом ничего конкретного по сути вопроса не говорится, ссылка на идеологию всё спишет. _>Разница очевидна. В git ветка — это что-то временное, а в mercurial ветки остаются навсегда в истории.
Не ветки. А их имена на момент коммита. Правильное называние сущностей помогает их правильному пониманию (вольное переложение Конфуция).
N>>Хорошо видно, что "branch: x1" написано на двух коммитах из разных веток (цепочек из коммитов, a.k.a. changeset'ов)? Простите, это из какой такой идеологии "бранчем" именуется нечто, что может перескочить между реальными ветками разработки? Теперь ветки — это не те ветки, а не те ветки — это ветки?
_>Покажи к чему приведут аналогичные действия в git'e и мы вместе посмеёмся. )))
Такой ситуации просто не возникнет. А если ты решишь вписать неадекватное имя ветки вручную в коммит — что ж, это было твоё решение.
_>О, кстати, ещё один практический нюанс вспомнился... Работа с автоматическими анонимными ветками намного удобнее в Mercurial. Собственно не помню как вообще в Git с ними работать (скажем аналог команды heads?).
Опиши желаемое подробнее, не понимаю.
_>>>Ну вообще то я говорил не про набор хуков, а про удобство расширения. Но даже если говорить про набор, то помнится в git'е раньше не было многих. Например preoutgoing и т.п. Сейчас не знаю, не смотрел, может и добавили. N>>Почитал про preoutgoing. Смысла не понял. Заодно прочёл, что в нём ничего не известно и что он не зовётся при push, хотя зовётся при передаче в другое репо. Какая-то совсем вещь в себе, или опять та трава, которая не та трава. _>Полезно для создания нестандартных каналов передачи (скажем с шифрованием и т.п.).
В Git банально переопределяется команда связи.
_>>>По умолчанию фиксируются все модифицированные файлы и это намного удобнее (т.к. это самый частый вариант использования), чем каждый раз писать "-a". Если надо зафиксировать изменение не всех файлов, то точно так же как и в git передаётся список в команду commit. Лично я же в таком случае предпочитаю снимать галочки в TortoiseHg. ))) N>>А часть одного файла? _>Эээ, что что? )
Я занимаюсь лечением бага. Для его диагностики вставлено 6 мест отладочной печати. Затем вписано 4 исправления собственно этого бага, причём 2 из них на рефакторинг "выделить код в отдельный метод" и 2 на исправление ошибки. Всё это в одном файле.
Мне нужно создать 2 коммита — рефакторинг и исправление — и оставить отладочную печать на несколько дней, пока не завершится, грубо говоря, весь деплоймент.
Git даёт сразу несколько методов набирать только те патчи из всех изменений, которые нужны для текущего коммита.
Ни в одной другой VCS я такого не видел. Врапперы во всяких IDE не учитывать.
_>>>Да, что касается формального сравнения разных команд... Я никогда об этом специально не задумывался, просто интуитивно чувствуется удобство в определённых случаях (потому и говорю что дело вкуса). Но вот сейчас решил чуть задуматься. Как там в git'e скажем насчёт аналога команды hg incoming? N>>Делается через fetch+diff. А какой смысл в команде в таком виде, как в hg? На каждый вызов выкачивать список изменений, показывать их, но не сохранять локально? А если два вызова, оно в состоянии это закэшировать? Юзкейс совершенно непонятен. _>Смысл в том, что просматриваемые изменения не попадают в твой репозиторий. Конечно можно потом извратиться и выкинуть их оттуда, но это уже лишние сложности.
OK, хотя и не понимаю практическую важность ситуации.
N>>И пока что я вижу в hg в основном такие хохмы. "Ветки", которые не ветки. "Закладки", которые тем не менее держат на себе состояние репо, хотя по смыслу названия они должны быть просто тегами. Команды с непонятным юзкейсом и заведомо неэффективным стилем исполнения. Зачем всё это? _>Да да, вот у меня такое же впечатление от git. ) Вроде как вся базовая функциональность имеется, но всё как-то через задницу. )
Как раз соответственно проверенным концепциям и подходам.
противоположное мнение высказывается. ) _>·>Ну, если более старые DVCS рассматривать, то да. Но накой DVCS hg начала что-то тянуть из centralised VCS типа svn... это не совсем разумное решение. Может в короткой перспективе, перетянуть юзеров, это и хорошо, но лучше в этом болоте не засиживаться. _>Не, я не про старые DVCS. Там ниже было высказывание, что к CVS и SVN ближе Git, а не Mercurial. )
Там вроде про ветки. Ветки — да, в hg это нечто уникальное, неповторимое понимание, попытка натянуть сову на глобус. Где ещё есть многоголовые ветки?
_>>>Ну возьми просто один большой (скажем на мегабайт, для простоты эксперимента) и кинь его пустой репозиторий. Ну поменяй пару строк и зафиксируй. И посмотри размер хранилища. Для hg и для git. _>·>Игрушечных экспериментов, которые плохо сработают для hg я могу тоже насочинять. Например, добавить тот же файл дважды в разные каталоги. _>ОК, давай возьмём просто любой большой проект и кинем его в чистый репозиторий) Причём это ещё будет максимально лояльным для Git тестом, т.к. у него размер существенно растёт именно с числом изменений.
Дело было вечером, делать было нечего. Я взял openssl-1.0.1r.tar.gz, 4.4мб, распаковал 44мб исходников, 2183 файлов, 130 каталогов... Что-то плохо всё с hg:
-
git
hg
hg/git
init
0.223
0.714
add
2.801
1.143
commit
0.870
5.327
add+commit
3.671
6.470
1.8
size
32
30
0.9
gc
5.670
-
size final
5.8
30
5.2
Время в секундах, размер в мегабайтах. hg 3.4, git 2.0.3, ubuntu, linux 4.2.0-23.
Очень интересно — размер repacked git репо сравним с tar.gz тех же данных.
Проведи такой же эксперимент — интересно будут такие же результаты или я что-то не так померил...
_>>>Ну а что касается обмена изменениями, то для последних ревизий (где пара строк менялась) разница действительно не принципиальна (типа 100 байт или 200), а вот если взять все ревизии (тогда оно будет включать файлы целиком), то опять же будет весьма интересный результат... _>·>Эээ.. А как ещё? Если хочется патчи, бери патчи. _>Не, я не про это. Я про размер получаемого файла (в котором по сути содержится весь репозиторий). Какой он будет у Mercurial, а какой у Git. Тут же утверждали, что низкоуровневая архитектура у Git более продумана и позволяет большее сжатие и т.п. А на практике...
... так и получается.
А вообще, какого файла?.. Если у тебя полная ревизия, то да, будет полный снапшот, если это diff, будет diff. Как это зависит от vcs?
_>>>Согласен. ) И в таком случае выигрывать по размеру хранилища будет скорее Mercurial. _>·>Будет, но не долго, до первого же repack. _>Угу и потом ещё пару изменений продержится на минимуме, а потом снова... )))
Может в каких-то ситуациях так и может быть, но обычно с точностью до наоборот.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Да просто очередной не читавший документацию и не смогший понять, что у него теперь просто две ветки.
_>>Надо просто понимать, что в mercurial есть как именованные ветки, так и анонимные (такого в git насколько я помню вообще нет?). ) ·>Деструктивного влияния централизованных VCS на DVCS? Нет, конечно.
А причём тут централизованные системы? ) Там как раз ничего подобного нет. )
_>> Но при этом это всё полноценные ветки со всеми механизмами работы с ними. ) _>>И кстати говоря это один из самых удобных инструментов работы. ·>Ага, чуть что — создавайте клоны.
Эм, какие клоны? ) Ты вообще о чём? ) Я говорил об удобстве работы на базе использования анонимных веток в mercurial (которые автоматически создаются, когда обнаруживается двое или более ревизий потомком у одной базовой). Причём это удобно даже если говорить не о синхронизации нескольких разработчиков (там это вообще идеально полезно), а о просто одиночной работе — неудобно придумывать название и создавать руками отдельную ветку ради маленького одиночного эксперимента с кодом (довольно распространённый сценарий).
_>>Нормально всё померил) Только вот где "плохо всё с hg"? Всё в точности, как я и говорил. Даже при наличие всего одного набора данных в хранилище mercurial занял 30 мегов, а git 32, как я собственно и говорил. ·>За почти вдвое большее время работы hg мог бы постараться сжать получше, чем на 10%, которые в пределах погрешности измерения.
Ну так про время собственно никто ничего и не говорил. ) Но если уж и говорить, то ты же понимаешь, что такие изменения на практике никогда не встречаются (это только для теста было), так что и подобных задержек тоже.
_>>Причём при дальнейшей работе эта разница ещё увеличится. ·>Враньё. Или факты в студию.
Это общеизвестный факт (если конечно же не делать периодических ручных repack'ов).
_>>Если же ты намекаешь на размер после repack (5,8 мегов), который ты забавно назвал "size final", то мы вроде как уже обсудили, что к реальности оно никакого отношения не имеет. ·>Именно это и будет реальный размер в любом долгоживущем или свежесклонированном репозитории.
Уууу)
У себя на диске (у тебя же есть свои проекты в git не так ли?) проверь для начала. )))
_>>·>... так и получается. _>>·>А вообще, какого файла?.. Если у тебя полная ревизия, то да, будет полный снапшот, если это diff, будет diff. _>>Не важно что) Главное чтобы одинаковое было (по смыслу) и в mercurial и в git. ·>За счёт чего ты ожидаешь какую-то существенную разницу? Я ожидаю разницу в пользу git, т.к. он имеет более подходящие структуры данных.
Мне не важно за счёт чего. Я просто проверял и знаю ответ. Но предлагаю тебе убедиться самому. )
_>>·>Как это зависит от vcs? _>>Разные форматы этих файлов и разные алгоритмы сжатия. Собственно так же как и в самом хранилище. Легко увидеть где оптимальнее... ))) ·>Ну? В git лучше форматы и алгоритмы. Я не понимаю зачем ты доказываешь преимущества git, я и не спорю с этим.
Ну так практика то говорит что хуже. ))) Проверь сам. ) Только по честному, без предварительных ручных repack'ов репозитория. )))
_>>Как же это наоборот, если твои же собственные измерения подтвердили мои слова? ) Или ты всё же настаиваешь на том, что стоит учитывать в оценке размер после repack? ))) ·>Конечно, я же учитываю стандартный реальный юзкейс, а не мысленные эксперименты, основанные на священной вере.
С чего ты взял, что он стандартный? ) Насколько часто лично ты делаешь repack своих личных проектов? )
_>>Кстати, интересно было бы сделать опрос на форуме, среди активных пользователей git. Сколько раз они делали repack для своих проектов? Что-то я подозреваю, что многие даже не в курсе про подобную функцию. ))) ·>Да никто его вручную обычно не делает, он сам выполняется периодически, когда становится слишком много loose objects.
Ага, вот и реальность проявляется...
Давай всё же подведём какой-то итог данному подразделу нашей дискуссий. Моё утверждение было такое: хранилище mercurial занимает меньше места чем хранилище git без постоянных ручных repack'ов последнего, а этим никто в реальности не занимается. Поясни с какой его частью (первой или второй) ты всё же не согласен.
P.S. На самом деле лично мне вообще то совсем не принципиален размер хранилища, просто этот вопрос всплыл в контексте сравнения эффективности внутренней архитектуры этих двух систем.
Здравствуйте, alex_public, Вы писали:
_>·>Столько ненужной и лишней терминологии просто из-за кривого дизайна системы. _>Рекомендую читать с начала: _>
_>The term branch is sometimes used for slightly different concepts. This may be confusing for new users of Mercurial.
_>Branches occur if lines of development diverge. The term "branch" may thus refer to a "diverged line of development". For Mercurial, a "line of development" is a linear sequence of consecutive changesets.
Это ещё сильнее запутывает. Вот в таком репозитории:
т.е. простая линейная история, никакой diverged line нет, но ветка release чуть старее чем development. Сколько тут веток? И как это следует из приведённой тобой цитаты?
Или вот такая история
Вроде это не linear sequence, сколько тут веток?
_>>>И в результате получают глупости типа описанных в последнем предложение по моей ссылке. ))) _>·>Которой ссылке? Я правильно понял, ты имеешь в виду что в официальной документации hg написана глупость? _>Нет, там корректно написано каким путём можно привести систему в глупое состояние. )
Ничего не понял. Давай конкретно. Приведи цитату, что такое глупое состояние системы и бывают ли в hg какие-то другие состояния?
_>>>А расскажи, чем по твоему неудобны глобальные имена веток? ) _>·>Тем что это противоречит распределённости. Лишняя сущность, которая нужна далеко не всегда. Что плохого в том, если два разработчика создадут ветки "experiment", а потом захотят обменяться? _>И в чём будет проблема с этим в Mercurial? )
Да, интересно как. У меня есть репо, у тебя есть репо. Мы оба делали какие-то свои эксперименты, у нас обоих есть ветки с именем "experiment", но совершенно разные по содержимому. Как мне взять твой experiment в свой репозиторий, чтобы не смешивать с моим experiment? В git можно например так:
git fetch <your_repo_url> experiment:alex_public_experiment
_>>>Про номера ревизий не понял в чём проблема, это всего лишь локальные хоткеи для удобства (если не хочешь, можешь вообще не обращать на них внимание) адресации. _>·>Ещё одна ненужная нашлёпка сбоку, унаследованная от cvcs. _>А людям удобно. ) Тем же кому не надо, ничем не мешает. Непонятно что плохого.
С толку сбивает. В git это гораздо проще: есть просто навигация по графу ревизий.
_>>>Ну так правильно, heads то показывает не все существующие ветки в репозитории, а только некое подмножество — не слитые. А heads <branchname> показывает ещё более мелкое подмножество — помеченные определённым именем. _>·>Объясни, каким словарём ты пользуешься, что словосочетание "branch heads" ты переводишь как "ветки"? Или в документаци, как всегда, глупость написана? _>Ну естественно что branch heads — это не ветки, а соответствующие ревизии. Но т.к. их число будет в точности равно числу не слитых веток, то думаю что моя фраза была вполне понятна.
Не будет. Пусть у тебя есть две ветки-в-официальном-понимании b1 и b2, каждая из них будет иметь по две головы. Количество веток-в-официальном-понимании будет всё равно две, а веток-alex_public-вида будет четыре. Команда "hg heads b1" выведет две головы.
Твоя фраза не понятна, ибо ты не используешься терминологией, принятой в документации hg.
_>>>Так а может ты пояснишь, какой аналог анонимных веток у нас в git? ) Т.е. что делать при нескольких параллельных изменения относительно одной родительской ревизии, обязательно заводить отдельную именованную ветку? ) _>·>А если не обязательно параллельных? _>·>В общем да, можно и ветку завести — ибо это ничего не стоит и никаких сложностей не создаёт. Это же не hg, где если заведёшь ветку, то это "навсегда". Собственно эта "фича" hg продиктована необходимостью — ветку завести не всегда возможно, вот и пришлось придумать новую сущность — головы. _>Никакой сущности "головы" в mercurial нет. ))) А команда heads просто показывает список ревизий без потомков (соответственно это получается список конечных ревизий, по одной для каждой ветки).
А о чём рассказывает статья https://www.mercurial-scm.org/wiki/Head ? Статья говорит, что голова — это ревизия без потомков. А ещё я забыл что есть понятие tip. А ещё этот зоопарк понятий:
head
a changeset that has no children
branch
the set of all changesets with the same branch name
branch head
a changeset in a branch that has no children in that branch (not the same as head!)
active branch head
a branch head that is also a head
inactive branch head
a branch head that has a child not in the same branch
closed branch head
a branch head with a closed marker
closed branch
a branch with only closed heads
Жуууть!
_>·>Ещё можно просто по sha1 обращаться. Можно reflog полистать, можно в stash закинуть. Вариантов куча. _>Ага, очень удобно. ) Да, и не забудь заблокировать git gc при этом. )))
Почему? gc соберёт только хлам 3-месячной давности. Если ты забыл что-то безымянное на 3 месяца, ты уже точно не вспомнишь что это было.
А вообще мы вроде говорили о "что-то быстренько попробовать прям щаз".
_>·>Если хочешь разобраться досконально, читай хелп на "git gc", флажок --auto. Там точно указаны правила. Используются несколько имперически подобранных параметров, чтобы в более менее стандартных ситуациях давать хороший результат, если что — можно подкрутить для особых случаев. Вроде очевидно, что "несколько мегабайт" это не то, о чём стоит волноваться. _>Я согласен, что для обычного пользователя это всё не принципиально. Но мы то рассуждаем об архитектурных принципах. И пока что выходит что на практике (а не в теории, где все тесты производятся после repack) подход mercurial лучше.
Ты не понял что-ли ещё? На практике repack происходит сам. На практике непакованный репозиторий найти — проблема.
_>·>Так новые ревизии не заставляют репозиторий распаковываться. То что запаковалось — так и остаётся запакованным. _>А я этого и не утверждал. Я говорил что размер снова вырастет через несколько новых ревизий. )
Чтобы репо в пакованном виде условных 5.8мб вырос до тех же условных 30мб меркуриала и ни разу не выполнился gc — не верю что такое часто случается на практике.
_>·>Разница есть, конечно, но не принципиальна... Вообще не понимаю причём тут бандлы, они от структуры репозитория не зависят. _>Потому что они идеально характеризуют тот объём данных, который необходимо переслать по сети для соответствующей синхронизации репозиториев. Можно конечно и честно по сети замерять, но это намного сложнее. Ну а соответственно размер этих файлов даёт представление о качестве алгоритмов эти двух систем... )
И что? 399 и 419 байт — и какие выводы из этой разницы ты сделаешь? Что неожиданного оказалось в этих цифрах для тебя?
Ещё раз — то что передаётся по сети никак не зависит от формата хранилища.
_>>>Ну для начала с "много места" мы ещё и не разобрались. И кстати говоря у всех подходов есть свои недостатки. Даже если взять за основу идею с repack'ом, то помимо проблем с расписанием данной работы, данная техника к примеру блокирует возможность инкрементальных бэкапов хранилища. _>·>Не блокирует. Просто иногда после repack придётся новые паки бэкапить, старые удалять, вот и всё. А вообще не проще ли --mirror использовать или тупо rsync? _>Ну о пользе и недостатках инкрементального бэкапа можно отдельно говорить. Но факт в том, что операция repack в git сильно вредит данной технике.
А вообще любопытно... Зачем вообще в dvcs нужен инкрементальный бэкап?
Но если так надо, то проще git bundle для этого использовать.
А вот инкрементально бэкапить (особенно hot repo) файлы hg я бы не стал... Вообще — погугли. Принципы бэкапов hg и git ничем не отличаются.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, netch80, Вы писали:
N>>>Ну, если ты знаешь, как провести эти тесты — покажи скрипты и результаты. Не думаю, что они покажут что-то принципиально важное (я лучше бы для сравнения взял результат перегонки чего-то открытого активно разрабатываемого), но просто покрасоваться цифрами — сгодится. _>>Ну тут уже кидали результаты. У меня в принципе похожие — у Mercurial раза в 1,5 меньше получаются пакеты изменений. ) Т.е. где-то так же и сеть загружается при синхронизации.
N>При остальных плюшках Git разница не принципиальна, но имеет смысл попинать авторов.
Чуда не случилось. Разница, как оказалось, в том, что hg использовал bzip2 компрессию, а git — gzip. После смены алгоритма компрессии пакеты стали ровно того же размера.
Странно конечно, что git не использует bzip2, хотя, с учётом того, что этот алгоритм значительно медленнее (раз в 5), может авторы git посчитали это неприемлимым.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, alex_public, Вы писали:
_>·>Собственно да, букмарки и создавались по образу и подобию веток гита. Но проблемы с ними есть. Скажем, управлять нельзя как они пуллятся. И опять — глобальные имена "Be aware that there is only one namespace for bookmarks — it is advised to prefix your local-only bookmarks to avoid conflicts with other users." _>·>И т.к. это опциональная фича с боку... как они поддерживаются другими тулзами? CI сервера, IDE, и т.п.? _>Зато применяются по делу, в отличие от git. _>Смотри, в mercurial и именновые ветки и закладки (выбираешь в зависимости от своего вкуса) применяются исключительно для выделения долгоживующих сущностей. Т.е. если у тебя реально в репозитории намечаются две принципиально разные ветки (скорее всего созданные в самом начале истории), то надо применять что-то из этой области. Если же у тебя реально только одна ветка, которая периодически разделяется и сливается из-за синхронизации работы команды, то выделенные именные сущности просто не нужны.
Собственно по-моему это и есть философское отличие. В hg ты должен заранее решить что и как ты делаешь, что у тебя намечается и в зависимости от этого выбирать какой-то из механизмов, если ты принял неверное решение — исправить ситуацию довольно геморно. В git принципиальной разницы нет. Сделай как-нибудь что-нибудь как кажется правильным на текущий момент, а потом, если что, поменяешь как надо, когда будешь точно знать что тебе надо.
_>В Git же приходится применять ветки не только для реальных выделенных сущностей, но но и для обслуживания ситуации синхронизации параллельной разработки в одной (смысловой) ветке.
Ты так говоришь, как будто это что-то плохое. В стандартном случае у тебя после clone будет две ветки — master — твоя работа и origin/master — ветка оригинального репозитория. Ты сразу можешь точно видеть где твоё, а что идёт от других.
_>>>Нельзя) Нет, ветвления не появится пока не породишь ещё одного потомка из этой точки (не важно с каким именем). А пока у тебя вышло просто переименование одной и той же ветки. ) _>·>Будет ревизия, с новым уникальным id, так ведь? Значит уже история пошла врозь. _>·>И что сбивает с толку, есть коммит, с датой, с автором... но никаких изменений, diff пустой! _>Ммм, я что-то не понял. Вот смотри, у нас идёт цепочка ревизий, в которой используется некое имя ветки (Х). Потом мы с какого-то момента решили продолжать эту цепочку под новым именем (Y). Мы сообщаем об этом mercurial (командой branch, которая по сути ничего не делает в самом хранилище) и следующие ревизии в цепочке будет носить уже новое имя Y. При этом никаких реальных развилок не наблюдается — они появятся только если вернуться назад и добавить новых потомков (не важно под каким именем ветки) к точке развилки.
Да, верно. Чтобы появилось имя ветки надо сделать коммит, даже если содержимое X и Y идентично (тот же snapshot), их sha1 будет разный.
Т.е. если строгаю я всё в default-ветке, потом создаю release_candidate, и продолжу строгать default — появится расхождение графа ревизий. Это алогично, ведь по факту, с т.з. моих рабочих файлов — никаких расхождений нет, история изменений working copy — линейная. release_candidate не разхождение ревизий, а просто left behind ветка, которую можно fast forward.
Расхождение должно появиться только в том случае, если я внёс изменение и в release_candidate, и в default, т.е. появилась ревизия с двумя детьми. А что собственно значит появилось расхождение — это значит, что появилась "альтернативная история", которую можно 3-way мержить.
_>Ну и да, это бредовый способ использования именованных веток (т.к. собственно ветвления тут нет) и его никто не использует. Но если очень хочется (я правда так и не понял зачем оно тебе такое было надо), то технически возможно.
Да, закладки — как возможное решение. Остаётся вопрос — накой нужны ветки. И почему "это" называется "веткой" в hg.
_>·>В git тоже, всё так же. Правда работать с номерами ревизий — не гуманно, git освобождает от этой необходимости когда возможно. Все эти ветки, теги, символические ссылки и т.п. — чисто для удобства человеков, сам гит может обходиться исключительно sha1 (и это удобно, особенно когда пишешь какую-нибудь автоматизацию/скрипты/славароботам). _>В том то и дело, что не так же. Нет в git нормальной работы на уровне чистых ревизий. Вот к примеру как мне узнать список всех "голов" в хранилище? Я уже молчу про то, что git-gc может самовольно удалять подобные данные. Нет, в git нельзя нормально работать без именованных веток, хотя внутри у него в базисе такая же основа как и у mercurial. Но не смогли...
Голов слишком много, их можно найти через "fsck", или через "reflog". Например, когда правишь коммит (скажем поправить орфографическую ошибку в комменте), возникает "голова", которую и не грех собрать gc. Без именнованных веток работать можно, но бессмысленно, человекам имена понятнее, чем циферки. Комфорт работы с безымяными ветками в hg является удобством лишь в сравнении с тем, что с именованными ветками работать хреново.
Скажем, изменения приезжающие из других репозитоиев появляются как безымянные головы именованной ветки — нужно догадываться что откуда. В git они приезжают с префиксом имени других репозиториев, human friendliness, однако.
_>>>Первый раз про такое слышу. Использовать ветки для ситуации без ветвления. Это похоже только от убогости других инструментов git'a. _>·>Ещё раз. Оно расходится _может_, но не обязательно что _будет_. Скажем, если мы зарелизили что-то и оно всё сразу суперски заработало с первого раза — релиз будет в точности равен тому что надевелопилось. А если мы сделали поверх релиза хотфикс(ы) — ветки разойдутся. _>Ну и пускай расходятся просто так — в mercurial всё равно же не обязательны именованные ветки/закладки для этого. Собственно ситуация кратковременного ответвления идеальна для реализации через анонимные ветки. _>А вот реальные именованные ветки/закладки есть смысл использовать при наличие логически выделенных веток разработки, а не для синхронизации работы или установки каких-то меток (для этого есть теги).
А вот представь себе, что в гите неважно кратковременно или долговременно что-то ответвляется. Механизмы те же, инструменты те же, команды те же, и то, и то использовать просто.
_>·>Пусть другой граф, пороще, с расхождением, мержем и одной веткой: _>·>
_>Ну так ты поясни что это. Я вот вижу некую ветку, которая разделяется и потом сливается. Это понятно и нормально. Потом я вижу некую метку "development" на последней ревизии ветки. Что она у тебя должна означать? )
Пусть именованную ветку или закладку. Не важно. Покажи на этом рисунке "a linear sequence of consecutive changesets", например.
_>·>Что ещё за указатели на ветки? Есть просто reference (ссылка) и всё. Сссылка с префиксом refs/heads/ является веткой, с префиксом refs/tags/ — тегом, с префиксом refs/remotes/ — ссылки из чужих репо, и т.п. Там же и stash, там же и notes и кастомные вещи, типа pull requests гитхаба. _>·>Команды какие ещё? update-ref только, остальные (branch, tag, notes) просто надстройки — для удобства человеков только. _>ОК, а если у нас репозитории ревизия на которую нет ссылок через ветки/теги, то как нам с ней работать? )
А почему нет? Создать ссылку — элементарно, ничего не стоит, никаких проблем не создаёт, если вдруг мешается, можно удалить, никаких последствий.
А если ты робот и тебе надо без ссылок, всегда есть id.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, alexzz, Вы писали:
A>Допустим, у Маши с Петей отсутствует фантазия. Маша закоммитила, поставила синхронизируемую закладку, запушила. Петя закоммитил у себя и поставил закладку с таким же именем. Попробовал её синхронизировать, но оказалось, что закладка с таким именем уже есть. Петя переименовал свою закладку, и они жили долго и счастливо.
Вроде я понял чего тебе не понятно. hg имеет жуткое cvcs наследие, которым жестоко коцают мозги юзеров. Ты видишь только два репозитория, притом один из них более главный, или ещё "центральный сервер". А в dvcs — репозиториев потенциально бесконечно и они все равноправны. Маша и Петя это могут быть две БОЛЬШИЕ команды. И закладка команды ПЕТЯ уже разползлась в 1000 реп, закладка команды МАША в 2000 реп. И вот теперь приходит тут такая МАША и указывает ПЕТЕ что он у себя всё везде обязан поменять, т.к. МАША так хочет, как думаешь, куда пошлёт её ПЕТЯ?
A>>>Могут под свои задачи именованные ветки завести, если захотят или потребуется зачем-то. A>·>Ветки же уже заведены — с именем "experiment". Надо будет кому-то из них ветку переименовывать, переписывая историю. А от этой истории уже могут другие зависимости существовать... A>В худшем случае, если Маша с Петей две недели пахали локально в ветках с одинаковым названием, успели наделать много-много ревизий, даже успели засветить где-то на стороне хеши этих ревизий, а потом одновременно запушили на сервер, так что ни у кого из них не было шанса заранее узнать о совпадении имён ― ну, значит, пока будет две ветки "experiment". Хоть три. Можно их сразу закрыть и продолжить с новыми внятными названиями. Можно повесить закладки. Можно оставить как есть.
Это называется ripple effect — где-то небольшая проблема и все вокруг везде должны всё менять, вместо того, чтобы сделать локальное согласование только в точке взаимодействия.
A>Я толком не пользовался Гитом и не могу прочувствовать проблему совпадения имён.
Ты похоже, просто толком мне пользовался dvcs. Это не проблема git, это проблема распределённой разработки.
A>>>Маша и Петя спокойно обошлись без именованных веток, без bookmarks, без тэгов, вообще без всего. A>·>Т.к. при совпадении имён веток, Маша может вытянуть ветку Пети под другим именем, скажем, назвать её в своём репозитории как petya_dev. По смыслу — ветки dev у Пети и у Маши — независимые истории. A>Вот на самом деле зачем Маше Петина ветка под другим именем? По смыслу это одна ветка, у который есть своё имя (если есть). С чего его вдруг менять?
Чтобы их легко различать по имени, а не по неким косвенным признакам.
A>>>·> Почему их нужно насильно сталкивать лишь по тому, что у них случайно совпали имена — хз. A>>>Я думаю, слово "нужно" неверно. Устраивает базовый функционал анонимных веток? Пользуешься им. Испытываешь неудобства? Можешь использовать закладки и/или именованные ветки. A>·>Как выяснилось выше — не могу, проблему они не решают. A>Чем больше перечитываю, тем больше не понимаю, о чём речь. Что конкретно ты не можешь? Hg ругается на совпадение имён, виснет, теряет данные или не даёт коммитить, пушить и т.д.? Ему пофиг.
Ему пофиг на человеков: люди умные — захотят, разберутся.
A>·>Вот. Уже внезапно стало три анонимные ветки, различать их стало ещё сложнее. A>Там всё было подписано.
Т.е. если и Маша, и Петя удосужатся всё аккуратно подписывать и они чётко договорятся как именно подписывать, то возможно разберутся.
A>·>Та же проблема, имена закладок глобальны, да ещё и пушатся без спросу — думай тщательно каждый раз когда даёшь название. A>Можно тщательно думать, давая имена. Можно не думать, давая имена. Можно не давать имена. Имена не на что не влияют.
Они влияют на конфликты.
A>Я так понял из разговоров, что Гит заставляет давать каждой головной ревизии уникальные в пределах репозитория имена.
Нет, гит _сам_ добавляет префикс к имени. Хотя не обязательно, можно и без имён обойтись Например, дефолтным именем FETCH_HEAD
A>Но поскольку головных ревизий бывает много, а слов в языке мало, то названия совершенно разных веток в разных репозиториях периодически совпадают. И тогда чтобы влить в один репозиторий изменения из другого, иногда приходится чужие ветки у себя переименовывать. И тогда в разных репозиториях совершенно разные ветки могут называться одинаково, а одна и та же ветка может называться по-разному. Отсюда, наверное, такая любовь и ненависть к именам?
Они совадают потому что репозитории разные и независимые, потенциально — без какого либо централизованного контроля, distributed vcs однако.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, netch80, Вы писали:
N>Слушай, а у тебя с RAM, шиной и т.п. на данном компе всё в порядке? N>Ничем иным я объяснить подобные чудеса на сейчас не могу, кроме как битым железом.
Скорее всего crlf настройки разные стоят у разных членов команды.
Боянная проблема гитоводов.
Здравствуйте, alex_public, Вы писали:
_>·>Собственно по-моему это и есть философское отличие. В hg ты должен заранее решить что и как ты делаешь, что у тебя намечается и в зависимости от этого выбирать какой-то из механизмов, если ты принял неверное решение — исправить ситуацию довольно геморно. В git принципиальной разницы нет. Сделай как-нибудь что-нибудь как кажется правильным на текущий момент, а потом, если что, поменяешь как надо, когда будешь точно знать что тебе надо. _>Эм, никакой технической проблемы поменять расклад в Mercurial в любой момент. Это я тебе рассказал наиболее логичный и удобный подход на мой взгляд, а не ограничение системы.
Как ты branch переделаешь в bookmark?
Ты говоришь, мол это для короткоживущих, это для долгоживущих... Как ты это определяешь? Ты знаешь будущее? Я не ясновидец, я не умею и не хочу думать об этом выборе. Почему это должно отличаться?
_>>>В Git же приходится применять ветки не только для реальных выделенных сущностей, но но и для обслуживания ситуации синхронизации параллельной разработки в одной (смысловой) ветке. _>·>Ты так говоришь, как будто это что-то плохое. В стандартном случае у тебя после clone будет две ветки — master — твоя работа и origin/master — ветка оригинального репозитория. Ты сразу можешь точно видеть где твоё, а что идёт от других. _>Вот уж свою ветку со своими комментариями к ревизиям я уж как-нибудь отличу от чужих. )))
Вот и говорю — явно отличить невозможно, приходится полагаться на косвенные признаки.
_>·>Расхождение должно появиться только в том случае, если я внёс изменение и в release_candidate, и в default, т.е. появилась ревизия с двумя детьми. А что собственно значит появилось расхождение — это значит, что появилась "альтернативная история", которую можно 3-way мержить. _>Ммм, так а ты объясни тогда зачем в твоём сценарии создавать новую ветку и делать в ней пустую ревизию?
А разве можно запушить ветку, если она не закоммичена?
_>>>Ну и да, это бредовый способ использования именованных веток (т.к. собственно ветвления тут нет) и его никто не использует. Но если очень хочется (я правда так и не понял зачем оно тебе такое было надо), то технически возможно. _>·>Да, закладки — как возможное решение. Остаётся вопрос — накой нужны ветки. И почему "это" называется "веткой" в hg. _>Формально оно называется "именем ветки" и при этом несколько веток официально могут иметь одно название. ))) Но согласен, что название не совсем удачное.
Не знаю откуда ты берёшь это "формально", в официальной документации это называется named branch, "именованная ветка". Да и команды, работающие с ними "hg branch", "hg branches". "--branch".
_>Что касается функциональности, то из их фундаментального отличия (имя ветки идентифицирует целый набор ревизий, а закладка только одну) следует и большая разница в применение. Например имена веток остаются навсегда в истории, что очень полезно для отслеживание работы команды. Кроме того, имена веток не реагируют (наследуются в обе части) на мелкие анонимные разветвления, а закладки соответственно идут только по какому-то одному пути. Так что разница принципиальная. И лично мне для выделения принципиальных долгоживущих частей истории проекта больше нравится использовать именные ветки, а не закладки. Но это дело вкуса. В Mercurial богатый выбор вариантов, в отличие от Git. )))
Польза мне не очевидна. Я за минимализм. Если что-то понадобится, выберешь какой-то подход для этого конкретного требования. Проще линк(и) какой-нибудь добавить более подходящий в коммент: "Bug: 1235", "Story: AB-5565", "Sprint: 17" и т.п. Ветками такое выразить уже не выйдет.
_>·>Голов слишком много, их можно найти через "fsck", или через "reflog". Например, когда правишь коммит (скажем поправить орфографическую ошибку в комменте), возникает "голова", которую и не грех собрать gc. Без именнованных веток работать можно, но бессмысленно, человекам имена понятнее, чем циферки. Комфорт работы с безымяными ветками в hg является удобством лишь в сравнении с тем, что с именованными ветками работать хреново. _>Ну т.е. как я и говорил, нормально работать с анонимными ветками в Git нельзя. Несмотря на то, что где-то на низком уровне там как раз такой же механизм (хэши и связи). Но не смогли...
Я не понимаю что ты подразумеваешь под нормально работать. Зачем вообще с анонимными ветками работать? Особенно в случае, если с именованными проблем никаких.
_>·>Скажем, изменения приезжающие из других репозитоиев появляются как безымянные головы именованной ветки — нужно догадываться что откуда. В git они приезжают с префиксом имени других репозиториев, human friendliness, однако. _>Смешно) В Git мы имеем ровно один способ реализации ветвлений. А в Mercurial мы имеем 3 разных способа (причём один из них совпадает с реализацией в Git) — используй какой тебе больше по вкусу, никто не ограничивает. Но при этом ты считаешь, что Git в этом смысле лучше? )))
Букмарки не совпадают с git, имеют неразрешимые проблемы. Так что я предпочту один способ, но универсальный, чем три — но ограниченных. Эти проблемы, надеюсь, уже пофиксили?
_>>>А вот реальные именованные ветки/закладки есть смысл использовать при наличие логически выделенных веток разработки, а не для синхронизации работы или установки каких-то меток (для этого есть теги). _>·>А вот представь себе, что в гите неважно кратковременно или долговременно что-то ответвляется. Механизмы те же, инструменты те же, команды те же, и то, и то использовать просто. _>Собственно я ещё в самом начале дискуссии сказал, что данный вопрос больше дело вкуса. )
Хорошо, пусть дело вкуса. Но смысла уж точно нет.
_>>>·>Пусть другой граф, пороще, с расхождением, мержем и одной веткой: _>>>·>
_>>>Ну так ты поясни что это. Я вот вижу некую ветку, которая разделяется и потом сливается. Это понятно и нормально. Потом я вижу некую метку "development" на последней ревизии ветки. Что она у тебя должна означать? ) _>·>Пусть именованную ветку или закладку. Не важно. Покажи на этом рисунке "a linear sequence of consecutive changesets", например. _>Ну вот то, что ты нарисовал — это оно и есть как раз. ) В начале одна линия, потом разделяется на две, потом сливается снова в одну. ) Что тут может быть непонятного? )
Не понял. В каком начале? Это текущий граф, текущая история. sequence может быть выражена как последовательность точек. Я поменял граф, обозначив точки уникально. Перечисли эти линии.
_>>>ОК, а если у нас репозитории ревизия на которую нет ссылок через ветки/теги, то как нам с ней работать? ) _>·>А почему нет? Создать ссылку — элементарно, ничего не стоит, никаких проблем не создаёт, если вдруг мешается, можно удалить, никаких последствий. _>Про Оккама забываем? )))
В hg об Оккаме и не всмоминали: помимо "именованных веток" ввели сущность "анонимные ветки" и прочие закладки с головами.
Мне вообще интересно, опиши сценарий: откуда в git появится ревизия на которую нет ссылкок и что ты с ней хочешь делать, для чего она тебе может понадобится?
_>·>А если ты робот и тебе надо без ссылок, всегда есть id. _>Да, вот только робот и может пользоваться анонимными ветками в git (записывая на бумажку хеши и отключив при этом git-gc).
Человек тоже может, но только стоя в гамаке, надев противогаз.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, netch80, Вы писали:
N>В каком смысле "слился"?
В смысле что на первых порах они с гитхабом активно конкурировали и были примерно одного уровня популярности. Но потом гитхабовцы их переплюнули за счет активного добавления новых фич. Битбакет задергался, но поезд уже ушел, и сейчас сравнивать их популярность просто смешно.
Здравствуйте, alex_public, Вы писали:
N>>>Ситуацию, когда в пределах одной рабочей копии status показывает изменение, а hard reset его не сбрасывает, это не даст. CX>>Я подобное наблюдал, когда в репозиторий были добавлены файлы с разным содержимым, но именами, отличающимися только регистром. _>Какая милая система... )))
Рад, что ты начал понимать. Есть "core.ignoreCase". В отличие от этого убожества hg:
* Renaming colliding files *
...
To repair such revisions, you should give new names to one or both of the colliding files on a case-sensitive filesystem, and commit them to create new collision safe revision.
.. note:: If you want to (or need to) browse or repair such revisions on case-insensitive filesystems, please see 'Updating manually' section.
...
* Updating manually *
... This is NOT recommended for non expert Mercurial users.
_>Кстати, я помнится наблюдал ещё, что git (как и многий другой древний линуксовый софт) до сих пор ломается на каталога с пробелами в именах. ) Это вообще жесть и убогость. )))
Можно пример? Надеюсь ты знаешь, что имена с пробелами надо заключать в кавычки?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Cyberax, Вы писали:
C>Что значит "откатиться"? У нас не централизованная VCS, некуда откатываться.
Это значит иметь возможность сделать чекаут коммита HEAD-N и получить возможность осмотреться внутри репозитория годичной давности. Какие ветки были, кто куда коммитил и все такое.
Граф гита — то еще убожество в таких ситуациях.
C>У нас не централизованная VCS, некуда откатываться.
В 99% продакшн энвайраментах есть центральная репа. Ее и можно считать основной.
У меня лично не было ни разу нужды заводить больше 1 remote репозитория. Поэтому все эти фичи децентрализованные только мешают и усложняют повседневные задачи.
Линусу линусово, а красноглазым членов команды надо тряпками по щщам когда они в очередной раз заводят свои байки про убер систему git
Пользоваться же надо теми системами которые хорошо поддерживаются твоей IDE. В случае C++/C# под VS это не так.
C>Можно посмотреть какие в репозитории были названия голов в данное время.
Как? Только чтобы удобно, а не а-ля полистать reflog
Здравствуйте, alex_public, Вы писали:
_>>>Из существенных претензий тут только пункт с close-branch. Если бы он был правдивый (тут уже вроде всё показали на эту тему). N>>Не-а. Из существенных тут невозможность узнать в любой момент, что в staging. Вот это действительно очень серьёзный злобный фактор. А работа веток, которые не ветки, тут действительно мелкий фактор. _>Это ты про что (в Mercurial же нет понятия staging), про возможность показать что будет зафиксировано или про какие-то дополнения к работе расширения record? )
Вот я читаю `hg help record` и вижу описание того, что она "interactively select changes to commit". Где находятся эти изменения, когда hg record уже отработала, а hg commit ещё не запускалась? Это то, по чему я предположил существование staging area. Видишь ли, в отличие от предположений коллеги woah, я читаю документацию и верю ей.
А вот сейчас проверил — hg record сразу коммитит. Значит, враньё с самого начала в документации — фраза "interactively select changes to commit" должна звучать на самом деле примерно как "commit interactively selected changes". Да, ты прав, всё ещё хуже, чем я предположил — в Hg нет staging, а в документации ещё один кусок гнилого обмана.
(А ещё в таком случае интересно, зачем такую пустую банальность, не дающую никаких потенциально неожиданных свойств, как staging area, прятать в выключенные по умолчанию расширения. Конспирология, но у меня нет никаких идей, кроме как то, что авторы Hg считают своих пользователей за полных дебилов, которые всё протеряют.)
_>А почему это грязнокодинг? ) Разве нельзя добиться нужного результата не меняя историю (например та же команда hg backout демонстрирует пример подобного)? В итоге у тебя будет всё красиво и история сохранится. Или тебе надо скрыть из истории все следы косяков и т.п.? )))
Кроме эмоциональных оценок в терминах "скрыть" и "косяк", всё верно. Первичная история — до начала взаимодействия с другими людьми — не должна быть историей косяков, она должна быть историей правильно сформированных и сгруппированных изменений. Ты предлагаешь хоть и маленький и временный, но _продукт_. Своей работы. Никого не должно волновать, сколько промежуточных косяков ты допускаешь по дороге, пока это укладывается в ограничения по ресурсам — на суд коллег должны быть вынесены результаты.
А эти результаты в нормальном варианте строятся в цепочку изменений (в сложном — несколько цепочек, но каждая должна быть логически закончена), так, что каждое из них
* делает только одно из набора: стилевые правки, рефакторинг, функциональное изменение
* или сделано вручную, или автоматически (как автоформаттером), кроме случаев, когда за автоформаттером надо подчищать
* функциональное изменение по возможности максимально однородно по сути действий
и только такое заслуживает передачи в общее репо так, чтобы не было чего мучительно стыдиться.
И реально сложное изменение такого рода не сделать без возможности разделения, перестановки, слияния коммитов, выбора нужного из локальных изменений. А если какое-то современное средство прячет эту функциональность поглубже (отдельные команды, выключенные по умолчанию расширения), то его авторы целенаправленно воспитывают ламеров и говнокодеров.
N>>Она не базовая. Базовая это цепочки коммитов. А фиксация безымянных голов это уже расширение. И это ещё раз показывает следствия безумного бардака с терминологией. _>А как можно организовать цепочки без фиксации? )
Ключевое слово было "безымянных". Не делай вид, что не понял этого.
N>>Это называется наплевательством на качество результата. Я не могу принять ни такой стиль, ни следствия в виде "нефиг менять, раз однажды закоммитил" для *VCS.
_>А что ты называешь качественным результатом то? ) Мне казалось это должна быть идеально работающая последняя ревизия. Но у тебя это похоже что-то иное... )))
Здравствуйте, alex_public, Вы писали:
_>>>Т.е. чтобы сделать аналог простейшего режима работы в Mercurial вообще без именованных веток в Git надо завести в каждом репозитории минимум 2 ветки (одну общую для синхронизации и слияний и одну для локальной разработки), правильно? ) N>>Да. И это правильно. _>Ага, и в итоге у каждого репозиторий выглядит по своему. Весело. )))
Это _распределённая_ система. Если удивляет, что у разных людей разное содержание — хм, я боюсь, тут вообще не centralized VCS должна помочь, а вообще файловая шара.
Это не наезд, но попытка определить границы того, что тебе не нравится, что "у каждого репозиторий выглядит по своему", значит, для тебя он у всех должен быть одинаковым.
_>>>P.S. Кстати, тут что-то вспомнилось... А что у git с аналогами команд hg copy/rename/remove? ) Помнится он там что-то автоматическое пытался делать, но чаще всего криво... ))) N>>Не понимаю проблемы. _>Да тут вот народ рядом жалуется на то, что при рефакторинге git делает некую ересь. )
Он не делает никакой "ереси", это опять попытка втихую навесить эмоциональный ярлык (<sarcasm>branch, в терминах Hg</sarcasm>). А что именно он делает — уже обсудили и объяснили в деталях.
Здравствуйте, woah, Вы писали:
_>>Кстати, я помнится наблюдал ещё, что git (как и многий другой древний линуксовый софт) до сих пор ломается на каталога с пробелами в именах. ) Это вообще жесть и убогость. )))
W>Ну с учетом того что система писалась Линусом для личных нужд Линуса это нормально
У Git(*) нет проблем с пробелами в именах. Как и у подавляющего большинства юниксовых средств, где эта проблема давно отработана на всех уровнях.
Проблема пробелов в именах существует (нежданчик, да?) в Windows, которая эти самые имена с пробелами использует значительно шире (начиная с знаменитой PROGRA~1, ой, простите, "Program Files"). Вызвана она тем, что:
1. В программы передаётся цельная "командная строка", а не список аргументов. Корректный, стандартизованный, поддержанный в WinAPI парсинг этой строки появился ой не сразу (обратим внимание, что эта функция существует только в Unicode варианте, и я не помню её существование во времена Windows 95-98, хотя специально искал). Несмотря на существование этой функции, если верить (ха-ха) MSDN, с Windows 2000, до сих пор её существование замалчивается (я не видел пока ни одного руководства, где бы её упоминали — видимо, для кого-то это совсем фантастические уровни). Причём на SO говорится: "It's ultimately up to the individual programs how they tokenize the command-line into an argv array (and even CommandLineToArgv in theory (and perhaps in practice, if what one of the comments said is true) could behave differently than the CRT when it initializes argv to main()), so there isn't even a standard set of esoteric rules that you can follow."
Также, нет готовой проверенной обратной функции (для Unix присутствует в десятке открытых источников).
2. Стандарт эскейпинга аргументов командной строки значительно более кривой, чем в Unix, малопонятный, и, в отличие от Unix, где он описывается в любых книгах по администрированию, глубоко спрятан в недрах MSDN.
Например, различный парсинг бэкслешей argv[1] в примерах 2 и 3 по предыдущей ссылке, и правила 5-7 в тексте — диверсия, которая не была бы пропущена ни в одно приличное средство. Пример плача.
3. Посредники вроде cmd.exe ещё больше усложняют ситуацию.
Передать в sh аргумент в вызываемую команду без репарсинга тривиально — "$x" вместо $x. Передать исходный набор аргументов — "$@". Аналога для Windows не вижу, или он настолько прочно спрятан внутрь, что не гуглится.
Реально, я сталкивался со средствами, которые просто отказывались ставиться в Program Files и требовали для себя пути без пробелов. Видимо, их авторы задолбались.
(*) виндовые адаптации я не учитываю — вполне возможно, их авторы просто не осилили продраться сквозь вышеописанные грабли, и если это не целенаправленная разработка под Windows, не считаю возможным упрекать их в этом.
Здравствуйте, alex_public, Вы писали:
_>>>Ну формально то как раз можешь, но это бред. Для таких целей теги есть) _>·>Чем теги от букмарок отличаются? _>Закладки — это указатель, который автоматически скачет на следующую ревизию при фиксации. А тег никуда не скачет, но зато может просто редактироваться пользователем.
А tip это тег, который скачет как закладка? тегладка (tagmark)? Всё чудесатее и чудесатее.
_>>>Если ты имеешь в виду момент последней ревизии, то к нему останется только одна ветка, в которую сольются предыдущие. ) _>·>Какой ещё момент? Пусть тебе на read only CD дали hg репо, граф которого я изобразил и попросили посчитать и перечислить ветки. Это так сложно? _>Ну так я тебе уже ответил только что. )
Ты ответил, что их четыре. Теперь одна. И ты так и не объяснил по какому принципу ты выбрал эти четыре и как оно согласуется с определением в документации.
_>>>·>Да, когда шлёшь что-то другому репозиторию — надо создать имя. Иначе тому другому может пушить кто-то ещё и получится жуткий бардак. _>>>Ну т.е. чтобы создать отросток в одну ревизию с неким альтернативным вариантом кода, _>·>А если не отросток? Не diverged т.е.? _>Не понял, не отросток, а что тогда? )
"the middle of a development line, not necessarily at a diverging point"
_>>> мне надо будет придумывать по новому имени ветки каждый раз, правильно? ) _>·>uuid используй или хеш какой-нибудь, если думать лень. _>Да, очень удобно. ))) Как раз принцип Оккама в действие. )))
Если тебе и правда нужен такой сценарий, то напишешь альяс:
git config alias.craZyexPerIment "!git branch experimental/`git rev-parse HEAD`"
Всё. После этого
git craZyexPerIment
будет создавать бранчи со случайным именем.
Их потом можно всех вывести командой "git branch --list experimental/*" , тоже можно заальясить.
Т.е. при желании это реализуется в несколько строчек конфига. И нет этого в стандартной поставке гита потому что это нафиг никому не сдалось, слава Оккаму, что этот анонимный бред отрезали. Такой инструмент — не удобен. Он может быть удобен только в том случае, когда ничего более удобного нет. А в гите есть куча более адекватных инструментов.
_>>> И я не смогу например объединить все подобные отростки под одним именем (как можно в том же Mercurial)? _>·>Для чего под одним именем объединять-то? Чтобы всех запутать? _>Почему запутать? Как раз удобно все эксперименты держать под одним именем experimental)
Будет у тебя 20 экспериментов... и как их различать-то?
_>>>А он может показать разницу между stash и рабочим каталогом? ) _>·>git diff stash@{13} _>·>неожиданно, правда? _>Это разве покажет не разницу с последней ревизией? )
Нет, именно с working copy.
Можно и с любой ревизией сравнить. Могу даже подсказать синтаксис если ты скажешь, что ты понимаешь под последней ревизией. А вообще, читай доки, там всё написано: https://git-scm.com/docs/git-diff
Так как в hg сравнить стеш с рабочим каталогом? Какой extension для этого нужно включить?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, netch80, Вы писали:
N>У Git(*) нет проблем с пробелами в именах. Как и у подавляющего большинства юниксовых средств, где эта проблема давно отработана на всех уровнях.
N>Проблема пробелов в именах существует (нежданчик, да?) в Windows, которая эти самые имена с пробелами использует значительно шире (начиная с знаменитой PROGRA~1, ой, простите, "Program Files"). Вызвана она тем, что:
N>1. N>2. N>бла-бла-бла
Всегда поражался сколько у линуксоидов отмазок для их неработающего софта
Примерно как раньше с файрфоксом могли часами доказывать что браузер хороший, просто стандарты не те и сайты неправильные.
Здравствуйте, 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.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
_>>Т.е. нет состояния с тремя головами в каждом репозитории. А я может хочу просто сделать 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 никогда не появится в начальном репозитории (и естественно не будет видна в графе).
Вообще то это требование было указано прямо в изначальном условие задачи, что альтернативная реализация должна быть сохранена в репозитории и доступна всем в будущем.
Здравствуйте, Dziman, Вы писали:
D>·> W>Слегка не в тему вопрос. Допустим я пилил ветку и слил ее в ремот. Там она была смержена куда надо и удалена. Потом я тоже у себя ее удалил. D>·> W>Как понять в рамках какой ветки изначально был запилен тот или иной коммит? D>·> Никак. А зачем? D>В мире очень много девиаций Но я пока не натыкался на внятное описание такой.
Профессионализм это называется.
Не надо путать цель и средство. Человек не решает задачу "понять в рамках какой ветки изначально...". Задача звучит совсем по-другому, например, "узнать когда коммит X ушел в продакшн". Если человек привык решать эти задачи в hg, используя такое средство, как имя бранча внутри коммита, это не означет, что эта задача не решается в git, т.к. он не сохраняет имя бранча внутрь коммита. Задача вполне может решаться в git, но другими средствами.
Если человек расскажет свою задачу, мы форумом попробуем предложить её решение средствами git, а он потом может решить, удобнее ли или нет.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
как мне тут советуют в соседней ветке и на стеке Ведь это гит для нас, а не мы для гита
·>Если надо поместить какую-то информацию в коммит, скажем bug id — просто добавь это в сообщение коммита. И не ограничивай себя только именем ветки, а добавляй что надо — номер спринта, идентификатор истории, фамилию проджект-менеджера, уровень алкоголя в крови, и т.п.
Проще в экселе это записывать. А исходники архивировать и на дискету. Удобней гита всяко
Здравствуйте, netch80, Вы писали:
_>> Кстати, аналогичного можно добиться и проще (как раз более практичный вариант) — фиксация своих изменений несколькими разработчиками в одну и ту же ветку, с последующей синхронизацией.
N>Пофиг, как ветка называется у каждого конкретного разработчика,
Не пофиг. Ветки именуются по фичам\багам. Смотришь откуда пришел коммит — сразу видишь что хотел сказать автор.
N> важно, в какую в общем репо они вливают
Здравствуйте, vovkab, Вы писали:
V>Например: V>1. нарезал комит, добавляя файлы, строчки, куски, что угодно
Пока я не видел как можно удобно в гите нарезать строчки, куски что угодно.
Ругаемый гитовцами вариант "сохранить в файлик, потом вернуть" реально удобнее всех этих гитовских консольных симулякров а-ля vimdiff.
V>2. спрятал все остальное V>3. прогнал тесты, убедился что все работает V>4. вытащил свой wip и продолжил дальше пилить
И что, с этим есть проблемы где-то? Стешить wip даже в майкросовтовской тфс можно было еще сто лет назад.
V>Надо поменять что то в старом комите, сделал ребэйз или просто фиксап комит, что бы не тратить время сейчас, V>оно потом само автоматически вольется куда надо при ребэйзе.
Одна из немногих фич гита которая более-менее работает, да. Да и то не факт что в других системах нет аналогов + работает эта фича до первого синка с ремотом.
V>В общем на сколько я вижу, тут проблема не столько в гите, сколько в организации процесса разработки, которого нет.
Он есть и в случае использования не гита он вполне работает. Все эти промежуточные коммиты могут быть весьма полезны когда придется отлавливать странный баг или поведение. Далеко не все и далеко не всегда можно\нужно вылизывать до блеска и полировать тестами в своей песочнице.
Если все пихать в каноничные мега коммиты с рюшечками и сообщениями на пять строк, то хрена с два ты там найдешь тот самый момент когда что-то отвалилось
Здравствуйте, vovkab, Вы писали:
V>Такие комиты не пройдут код ревью, так что их по определению нет.
Тоже вопрос весьма спорный. Что плохого в промежуточном коммите, если у тебя есть нормальная история на более высоком уровне?
Зачем тратить время на причесывание истории к каноничным стандартам, если в 99% случаев ты эту историю даже не откроешь?
В Меркуриале достаточно глянуть какие ветки слились и тебе сразу понятно что было проделано. В гите с помощью сторонних приблуд можно сделать симулякр в виде пулл реквестов.
На ревью ты смотришь уже готовый результат. Было-стало. А промежуточный стейт нужнен только для случая разбора полетов. Много мелких коммитов это лучше чем пара развесистых на 100500 файлов каждый. Когда ты берешь, открываешь и просто не понимаешь откуда могут расти ноги проблемы.
Просто в гите не делают такие коммиты т.к. гит с историей и ветками нормально работать не позволяет
Здравствуйте, willie, Вы писали:
W>>>И что ? Покажет что смержились две ветки. Как посмотреть какие именно коммиты вошли в мою ветку из чужой? W>·>git log myBranch^..alienBranch W>Не сработает. Ведь бранчи-то удаляются.
Бранчи сами не удаляются. Если они тебе нужны — не удаляй. Если удалил по ошибке, добавь обратно.
Да и не нужны они по большому счёту, мержи-то вечные. А именно мержи нужны для "посмотреть".
W>Это тебе не меркуриал с его мегафичей вечных веток.
Это не мегафича, а тяжелое наследние cvcs.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, willie, Вы писали:
W>>>Например чтобы откатить все что наваял нерадивый юниор. Для начала надо все это как-то найти. Желательно удобнее чем с помощью команды W>·>Найти точку нерадивого мержа, заревертить её. Не вижу проблемы. W>Я вижу как минимум проблему найти удобно коммиты которые ревертить.
Это никак не зависит от наличия/отсутствия перманентных бранчей.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, willie, Вы писали:
W>·>Можно, для небольшого проекта с центральным репозиторием, как CVCS hg ещё ок, в качестве альтернативы svn. Хотя в случае централизованной разработки лучше взять gerrit. W>Не понимаю этого упора на централизованность-децентрализованность.
Больше возможностей.
W>В большинстве продуктовых компаний по факту вся разработка централизована. Нету там никаких "распределенных систем равноправных репозиториев". Нету равноправия между офисами Есть центральный, куда все остальные сливаются по спринтам и откуда они забирают код других команд. Даже аутсорсеры зачастую либо получают репу и отдают ее на сливание заказчику, либо тупо по vpn сидят подключившись к серверу заказчика. Все эти мульки гита с распределенностью просто не нужны.
Не нужны — не используй, эти мульки ничем не мешаются, зато когда понадобится — очень здорово помогают. Не приходится скатываться до идиотизма "сохранить в файлик, потом вернуть".
W>Весь этот тред сводится к спору пары человек которые видимо работают в распределенных командах.
Даже в централизованной команде можно распределяться между собой — офисный десктоп/домашний десктоп/лаптоп/виртуалки.
W>Я вот почитал и понял что все же выбор гита видимо был ошибкой предыдущей команды. Повелись на баззворды, послушались красноглазого тимлида и вот результат. Постоянно за кем=то разруливать косяки приходится из-за того что кто-то не осилил документацию гита в очередной раз
Какие косяки приходится разруливать? Тем более в случае вашей централизованной разработки.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Cyberax, Вы писали:
C>Это извращение, а не фантастика. Примерно на том же уровне, что и "checkout" файлов из SourceSafe.
Чушь несешь.
Не знаю как ты, а я живу в 21 веке и ревью делаю с помощью более удобных тулзов чем веб-просмотрщик текста. Про сорсейф не в курсе че ты там думаешь
Здравствуйте, willie, Вы писали:
W>·>Бранчи сами не удаляются. Если они тебе нужны — не удаляй. W>И потом не сможешь создать второй такой же.
Я смогу. А тебе что мешает?
W>>>Это тебе не меркуриал с его мегафичей вечных веток. W>·>Это не мегафича, а тяжелое наследние cvcs. W>Не вижу ничего тяжелого, одни плюсы.
Бессмысленная сложность с эфемерной выгодой.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, willie, Вы писали:
W>>>Бранчи удобнее. W>·>Дело привычки.
W>Ну ок. W>Покажи как ты будешь искать все коммиты из feature1 ветки. При том что ветка удалена была давным-давно. W>Консоль не предлагать.
Путаешь цель и средство. Цель-то какая преследуется?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, willie, Вы писали:
w> W>>Бранчи удобнее.
w> ·>Дело привычки.
w> Ну ок. w> Покажи как ты будешь искать все коммиты из feature1 ветки. При том что ветка удалена была давным-давно. w> Консоль не предлагать.
"Хочу забить гвоздь. Молотки не предлагать"
Имея сообщения в логе типа wip, wip, commit, fix (как у вас принято в команде судя по прошлым сообщениям) без веток конечно сложновато понять что к чему
Ближе к сути вопроса: что заставляет удалять ветки?
Здравствуйте, ·, Вы писали:
·> W>>>Бранчи удобнее.
·> W>·>Дело привычки.
·> W>Ну ок. ·> W>Покажи как ты будешь искать все коммиты из feature1 ветки. При том что ветка удалена была давным-давно. ·> W>Консоль не предлагать.
·> Путаешь цель и средство. Цель-то какая преследуется?
Это распространенная проблема судя по форумам задать вопрос типа "Как улучшить у микроскопа сопротивляемость ударным нагрузкам?" в то время как правильный вопрос "Как забить гвоздь?"
Здравствуйте, Dair, Вы писали:
D>Консольный Git, 2.6.0
D>Наменял файлов. D>git add ... D>git commit -a D>и так несколько раз.
D>git pull --rebase
D>почему-то появились изменённые и незакоммиченные файлы
То есть rebase pull прошёл молча, но "появились изменённые и незакоммиченные файлы"?
И больше ничего не делалось?
Что-то крайне слабо верится.
D>git rebase --continue
А это ещё зачем? Оно показало конфликт? Если нет, то какой к лешему continue?
Если да, то почему не разобрался с тем, что в конфликте?
D>git push D>и... моих изменений нет вообще. Ни одного. Пять коммитов. День работы насмарку. Отличный Git
И пользователь, который совершенно не хочет понимать инструмент и действует на уровне "тут вылезло красненькое, я нажала и всё пропало".
D>А я вот уже более года юзаю TortoiseGit в паре с TotalCmd и никогда не было проблем.
Неужили Черепахой стало наконец можно пользоваться. Непрошло и 6-7 лет...
D>Правда некоторые действия все же удобнее из консоли выполнять.
Некоторые из чуть большего кол-ва чем все.
D>Просто отображение списков это явно не для <виндовой> консоли. D>Тут нужен именно GUI.
Не нужен вообще. Хочеш полистать список — используй less. Хочеш его отсортировать — используй sort. Хочеш сделать это одновременно — используй sort | less.
А ведь можно его еще и грепнуть, например на предмет всех коммитов васи пупкина за 32-е января...
D>Просто я в качестве развлечения разрабатываю прошивки под андройд. И пишу весь код на винде (просто без TotalCmd я как без рук), а собираю все на убунте. На убунте я в git выполняю только простейшие операции.
Когда то смотрел код фаром или wincmd-шным листером, правил его ultraedit-ом на примонтированной в венду Самбовой шаре и запускал компиляцию батников через любезно предоставленный putty тунель ssh.
В то время я был слишком молод и продлилось к счастью это совсем недолго.
Здравствуйте, eskimo82, Вы писали:
D>>и... моих изменений нет вообще. Ни одного. Пять коммитов. День работы насмарку. Отличный Git E>Совет: Никогда, никогда не делай rebase пока не заучиш GitMagic наизусть на оригинальном языке. E>Впрочем когда заучиш, тоже делать rebase его не стоит.
Пользуюсь rebase почти каждый день. Что такое GitMagic, даже не помню.
Дело не в GitMagic или в чём-то подобном. Дело в том, чтобы 1) читать, что тебе вывела команда (именно поэтому предыдущее сравнение), 2) помнить банальность — что "внутри rebase" это состояние репо и в нём нельзя делать посторонних действий, а нужно делать только те, что выводят из этого состояния как можно быстрее.
Вспомнилось у Раскина определение понятия "режим" (mode), и как он настоятельно рекомендовал избегать этого в проектировании (в частности, он категорически отвергал modal dialogs, даже если кажется, что они нужны). У меня никогда не было серьёзных проблем с режимами, но есть люди, которые с ними принципиально "не дружат". Подозреваю, что проблема ТС из этой области.
Здравствуйте, Sinix, Вы писали:
S>Хотя не, вру. Если приспичило прокрутить всю историю на лет шесть назад — поседеешь, пока дождёшься. При этом реально нужное, например посмотреть изменения по конкретной папке/файлу, даже если менялось года три назад, работает нормально. Секунд 5 где-то. S>... S>P.S. Blame — 2-3 секунды на больших файлах с длинной историей. S>Это всё с учётом того, что сервер не в локальной сети.
С трудом верится, особенно вспоминая жёсткие roundtrip'ы при работе с SVN, даже на мелких репозиториях в пару сотен коммитов. Но хорошо если действительно так.
Я думал там тормоза принципиальные, из-за архитектуры.
S>ну и чекаут репо на несколько Гб может минут 20 занять.
Первоначальный checkout не сильно волнует (если рассматривать работу над парой проектов). Git'ом выкачивал тысячи коммитов из SVN несколько дней, и ничего
Но, это же переход на старую ревизию или ветку может быть очень долгим, так? Например в целях поиска коммита внёсшего баг, а-ля git bisect.
S>Кэп: гит не работает, если в команде есть хоть один человек, не изучивший мануал.
Это говорит о сомнительном удобстве инструмента, как мне кажется.
Но я до вчерашнего момента считал, что неплохо знаю Git
Ошибался, был не прав.
S>Или использовать ui-инструменты, они хоть предупреждают о возможных косяках, или страдать.
UI-инструменты, увы, безудержно тупят. Консоль работает на порядки быстрее. Ну и я учусь на своих ошибках.
Здравствуйте, netch80, Вы писали: D>>почему-то появились изменённые и незакоммиченные файлы N>То есть rebase pull прошёл молча, но "появились изменённые и незакоммиченные файлы"? N>И больше ничего не делалось?
Выводы команд я не писал. Вывод rebase вот:
лог
$ git pull --rebase
remote: Counting objects: 152, done
remote: Finding sources: 100% (114/114)
remote: Getting sizes: 100% (48/48)
remote: Compressing objects: 98% (23920/24271)
remote: Total 114 (delta 93), reused 111 (delta 92)
Получение объектов: 100% (114/114), 7.38 MiB | 4.41 MiB/s, готово.
Определение изменений: 100% (94/94), завершено с 27 локальными объектами.
Из https://git.блаблабла
d07b7af..aab25a5 develop -> origin/develop
Сначала перематываем указатель текущего коммита, чтобы применить ваши изменения поверх него…
Applying: My commit message
Использую индекс для реконструкции базового дерева…
M path/to/some/source.cpp
.git/rebase-apply/patch:675: trailing whitespace.
.git/rebase-apply/patch:757: trailing whitespace.
.git/rebase-apply/patch:934: trailing whitespace.
void SomeClass::someMethod(someParams)
.git/rebase-apply/patch:949: trailing whitespace.
{
.git/rebase-apply/patch:950: trailing whitespace.
another line of code
warning: пропущено 9 ошибок в пробельных символах
warning: 14 строк добавили ошибки в пробельных символах.
Откат к применению изменений к базовому коммиту с помощью трехходового слияния…
error: Your local changes to the following files would be overwritten by merge:
path/to/another/source.cpppath/to/another/source.h
Please, commit your changes or stash them before you can merge.
Aborting
Сразу после этого я сделал git status, который мне выдал
перемещение в процессе; над aab25a5
Вы сейчас перемещаете ветку «develop» над «aab25a5».
(все конфликты разрешены: запустите «git rebase --continue»)
Изменения, которые не в индексе для коммита:
(используйте «git add <файл>…», чтобы добавить файл в индекс)
(используйте «git checkout -- <файл>…», чтобы отменить изменения
в рабочем каталоге)
изменено: path/to/another/source.cpp
изменено: path/to/another/source.h
нет изменений добавленных для коммита
(используйте «git add» и/или «git commit -a»)
N>Что-то крайне слабо верится.
Сам удивлён D>>git rebase --continue N>А это ещё зачем? Оно показало конфликт? Если нет, то какой к лешему continue? N>Если да, то почему не разобрался с тем, что в конфликте?
Нет, конфликт не показало. D>>git push D>>и... моих изменений нет вообще. Ни одного. Пять коммитов. День работы насмарку. Отличный Git N>И пользователь, который совершенно не хочет понимать инструмент и действует на уровне "тут вылезло красненькое, я нажала и всё пропало".
Своей вины не отрицаю, но как-то довольно просто получилось выстрелить себе в ногу, не ожидал.
Здравствуйте, eskimo82, Вы писали:
D>>Консольный Git, 2.6.0 E>Неужели под виндой
Нет, OS X. Но под виндой было бы то же самое, наверно.
D>>и... моих изменений нет вообще. Ни одного. Пять коммитов. День работы насмарку. Отличный Git E>Совет: Никогда, никогда не делай rebase пока не заучишь GitMagic наизусть на оригинальном языке.
Здравствуйте, uncommon, Вы писали:
D>>и... моих изменений нет вообще. Ни одного. Пять коммитов. День работы насмарку. Отличный Git U>Вот что бывает, кода набиваешь команды, не имея никакого представления о том, что они делают.
Здравствуйте, Vladek, Вы писали:
V>Единственная причина популярности Git — социальная сеть для миллионов разработчиков Github. Всё, никаких других причин использовать сложную утилиту для поддержки разработки ядра Linux за пределами разработки ядра Linux — нет.
Субъективное недовольство. Я вижу как крупные компании целиком или отделами мигрируют с коммерческих тулов на Git имея на то множество объективных причин.
Здравствуйте, netch80, Вы писали:
_>>Mercurial лучше — абсолютно те же самые технические возможности, но при этом более удобно. N>Нет, в разы менее удобно, идиотская логика на каждом углу. И не надо возражать, этот холивар давно надоел и я всё равно не соглашусь, ничего лучшего за последние лет 5 в меркуриале не случилось.
Ну естественно если речь не о технических аргументах, а о вере, то попытки убедить бесполезны) Хотя это всё как раз по профилю данного форума. )))
Здравствуйте, alex_public, Вы писали:
_>>>Mercurial лучше — абсолютно те же самые технические возможности, но при этом более удобно. N>>Нет, в разы менее удобно, идиотская логика на каждом углу. И не надо возражать, этот холивар давно надоел и я всё равно не соглашусь, ничего лучшего за последние лет 5 в меркуриале не случилось.
_>Ну естественно если речь не о технических аргументах, а о вере, то попытки убедить бесполезны)
Нет, не о вере. А о лени пережёвывать по 10му разу
_>Хотя это всё как раз по профилю данного форума. )))
Я никогда не воспринимал его именно как место для померяться флеймом.
Здравствуйте, 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 и объединять новые изменения.
Дело в том, что эти файлы я не трогал. Вообще.
N>Вообще тут странно вот что — по умолчанию оно запрещает делать rebase при любых локальных изменениях файлов, то есть оно вообще не вошло бы в такой процесс, потребовав stash до запуска rebase pull. Это какие-то локальные настройки, что оно проигнорировало запрет? Что за версия git?
2.6.0
Последняя сейчас 2.7.0, в понедельник обновлюсь, но не думаю, что что-то изменится. Надо просто быть аккуратным.
Про stash не забывать, да. Спасибо.
D>> (все конфликты разрешены: запустите «git rebase --continue») N>Хм. Насколько я понимаю, вот это сообщение и дало идею запустить rebase+continue. Оно неверно, и вот это как раз тот момент, где git явно виноват. Всё-таки надо уточнить версию, насколько она старая.
Не сильно старая
N>>>А это ещё зачем? Оно показало конфликт? Если нет, то какой к лешему continue? N>>>Если да, то почему не разобрался с тем, что в конфликте? D>>Нет, конфликт не показало.
N>Конфликт не показало, но оставило в промежуточном состоянии — вот это непонятно.
А я про что?
N>Резюмирую. Надо попробовать повторить на свежей версии и максимально чистом конфиге. Если повторится и вина не в хитрых локальных опциях — это таки серьёзный повод написать problem report — на провокационное поведение. Если нет — значит, залечили и вопрос в том, почему старая версия. Личная недоработка в понимании инструмента есть, но за счёт провокации она не 100% причина. Коммиты, как я понимаю, успешно восстановлены по reflog.
Всё так. Я при всех современных автоапдейтах всего забываю, что надо делать sudo port upgrade outdated, да.
N>Ещё в будущем в случае потенциальных сложных слияниях сохранять локальное состояние как кратковременную ветку, не принципиально, но восстанавливать с неё удобнее, чем с reflog.
Тут есть предыстория. Я и был в ветке. Закончил, вливаюсь в develop.
тут я в ветке my_branch
commit
checkout develop
pull
merge my_branch
(разрешение конфликтов)
add
add
add
commit
Тут в develop другие парни влили ещё два файла из заведомо других каталогов, push не прошёл.
Решил, что уже тут надо делать rebase. Ну и вот.
Здравствуйте, DSblizzard, Вы писали:
DS>Гит от робота и для роботов. Способность "вернуть все взад" — принципиальная возможность систем контроля версий. Если это по каким-либо причинам не получается — на помойку.
И эта принципиальная возможность в Git есть. Все основные объекты — файлы, деревья (читай директории), коммиты, цепочки коммитов, аннотированные теги — иммутабельные by design. Они пропадут только в том случае, если ты потерял все ссылки на них И истёк срок годности.
Здравствуйте, 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>А как же скорость? Например 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.
А еще я умудрился сломать локальный репозиторий в гите буквально на второй день Причем что с ним до сих пор не понимаю. Гит говорил что вообще все файлы в репозитории модифицированны. При этом при побайтовом сравнении с предыдущим коммитом разницы не было.
Здравствуйте, Нахлобуч, Вы писали:
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 — это не всем интересно.
Здравствуйте, ·, Вы писали:
_>>Со временем уровень технологических возможностей этих конкурирующих систем (да и не только этих двух, просто они самые известные, а там на самом деле ещё несколько полноценный аналогов есть) только выравнивается (у 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".
Здравствуйте, alex_public, Вы писали:
_>·>Фундамент git — лучше. Вместо традиционного (тянущееся начиная с rcs?) append-only лога, да ещё и per-file используется принципиально другой подход, ассоциативное object-хранилище. _>Это смотря на каком уровне смотреть. Формально да, одно хранит дифы, а другое вроде как сами файлы. Но фокус в том, что если бы оно реально хранило сами файлы, то размер хранилища был бы нереальным. Так что в итоге и второе хранит дифы, просто они там для сжатия, а не для идеологии.
Причём эти дельты в Git необязательно линейные, необязательно между одними и теми же файлами, и необязательно вперёд по времени — будет выбран оптимальный вариант по эвристикам и нескольким попыткам.
Здравствуйте, alex_public, Вы писали:
_>Даже если забыть о "низкоуровневых" возможностях правки истории в git, то остаётся ещё главное — разное понимание термина ветка. Вот https://habrahabr.ru/post/123700/ известный пример на эту тему.
В этом примере не разное понимание, а одна мелочь — фиксация имени ветки в коммите hg. Да, я действительно не понимаю, зачем это настолько нужно, чтобы выдвигать на киллер-фичу, при том, что реально ни одна другая SCM это не ведёт.
Добавить принудительно имя ветки в сообщение тривиально за счёт локального хука, но накойхер? Там лучше держать, например, герритовский change-id.
Остальные обобщения автора статьи про "подделку истории", "исторический ревизионизм" оставим на совести постмарксистского ярлыковедения.
_>>>- возможность получить гигабайтный патч при слияние веток в git. N>>Любое слияние отражает дифф с исходными версиями. "Гигабайтный патч" означает сведение существенно несовместимых вариантов. Проблема общая для всех DVCS, но в случае Git имеем один из лучших, испытанный на практике, мержер. _>Нет, всё зависит от способа работы с данными. Тут как раз это и обсуждали выше, называя реализацию git'a более технически совершенной. Однако у всего есть обратная сторона...
Можно конкретнее? Не понимаю.
_>>>- проблема с кодировками в путях. Надеюсь хоть это уже исправили? ) N>>Этой проблемы никогда не было у Git. Имя объекта это NUL-terminated строка байт, даже понимание этого имени как пути уже является свойством внешнего слоя, а не ядра. N>>Если она есть у Windows, то это проблема кодировок Windows и конкретных реализаций Git клиента. Бардак с кодировками (ANSI/OEM/Unicode) в Windows такой, что я всегда забывал, что в них где, через 5 минут после того, как разобрался. _>Проблема не у windows (проблемы будут и в линухе), а именно у git'a при работе с ним из разных ОС. Да, возможно это правильно называть проблемой "конкретных реализаций git клиента"... Но собственно это же и есть сам git (у него нет никакой обязательной серверной части).
Если кодировка путей стандартизована на уровне политики репо (считаю utf-8 умолчанием для 99.9% случаев), проблемы нет. Если нужно разбираться с разными локальными кодировками, то что это вообще за системы такие, и почему клиент с этим не разбирается, несмотря на явные недвусмысленные рекомендации?
_>Самое забавное, что различные GUI-оболочки/IDE устраняют эту проблему, передавая в git данные в каком-то одном формате. Что мешало сделать это банальное исправление в самом git — непонятно.
Именно то, что это вопрос к оболочкам (и файловое дерево — стандартная оболочка).
_>>>- слабая работа с хуками и другими расширениями в git N>>Мне не с чем сравнивать, но вопрос в том, насколько реально нужна "сильная" в твоём понимании, и насколько она логична. _>Не понял про что ты спрашиваешь) Про нужность хуков и расширений вообще в dcvs или же про удобство их реализации в Mercurial? Если про второе, то достаточно сказать про возможность реализации на уровне внутреннего вызова кода на Питоне.
Про их состав. Есть где-то пример позарез нужного хука, который не сделали в Git?
_>>>- заковыристая система команд (субъективно конечно, дело вкуса, но такое мнение можно частенько услышать) в сравнение с другими dcvs. N>>Система команд очень удобна из логики "если действие с базовой концепцией X, команда будет называться X". _>Ну я уже сказал, что это дело вкуса, а не технический вопрос. ) Но мнение что система команд mercurial удобнее своего аналога из git'a я видел неоднократно. )
Если есть что сравнить в плане разделения идентичных фич по командам, покажи пример. Что я пока увидел — просто отсутствие возможностей, к которым я привык как к 100% доступной и необходимой базе, типа накопить изменения чанками из разных файлов перед коммитом.
Здравствуйте, alex_public, Вы писали:
_>- проблема с сохранением истории в git. В mercurial всегда можно найти источник проблемы, а в git'е далеко не всегда.
Эээ... А конкретно? История иммутабельная, какие могут быть проблемы? Может кто-то просто не слышал о reflog?
_>- возможность получить гигабайтный патч при слияние веток в git.
Каким образом? И зачем вообще получать патчи при слиянии?
_>- проблема с кодировками в путях. Надеюсь хоть это уже исправили? )
Не знаю, думаю да, это был результат unix-only.
_>- слабая работа с хуками и другими расширениями в git
Что это значит?
_>- заковыристая система команд (субъективно конечно, дело вкуса, но такое мнение можно частенько услышать) в сравнение с другими dcvs.
Верно, дело вкуса. Результат отказа от традиционной идеологии.
_>·>Фундамент git — лучше. Вместо традиционного (тянущееся начиная с rcs?) append-only лога, да ещё и per-file используется принципиально другой подход, ассоциативное object-хранилище. _>Это смотря на каком уровне смотреть. Формально да, одно хранит дифы, а другое вроде как сами файлы. Но фокус в том, что если бы оно реально хранило сами файлы, то размер хранилища был бы нереальным. Так что в итоге и второе хранит дифы, просто они там для сжатия, а не для идеологии.
Правильно, SRP применён — хранение абстрагировано от представления, что облегчает многие фичи. И, кстати, даёт больше возможностей для оптимизации сжатия.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Пусть у меня есть текущая разработка из, например, 20 коммитов. Я хочу от 15-го из них отцепить, скажем, "стабильную" ветку, потому что последними 5 я начал ломать что-то. То есть ветка должна стартовать с 15-го коммита.
Что надо было сказать гуглу, чтобы он объяснил, как это делается?
(Для сравнения: Git: тривиально ищется по checkout, дальше написано про ключик -b и commit id. Но если вы решите поискать в branch, там тоже есть эта возможность!)
Путём поисков вбок нашёл главу "Create a Branch From an Older Revision". OK, пробую. Требуется вызвать hg update + hg branch, причём про hg branch с именем сказано "set the current branch name", что любой нормальный человек понимает как переход на уже созданную ветку или смену формального названия, но не создание новой!
Текущая правка у меня номер 3. Пишу "hg update -r 2", пишет "1 files updated".
Как мне узнать теперь, где я стою? "hg status" вообще ничего не пишет. (Git'овый пишет в этом случае, какой опорный коммит, состояние совпадает с какой-то веткой или это detached.)
hg branch? Не то. hg heads? Не то.
Инструкции молчат. Как я могу быть уверен, что делаю копию именно с нужного состояния? Только по тому, что hg update промолчала? А если я схожу на перекур?
Если авторы не в состоянии отработать с точки зрения даже простейший сценарий использования, как можно предлагать использовать их творение?
Здравствуйте, netch80, Вы писали:
N>В этом примере не разное понимание, а одна мелочь — фиксация имени ветки в коммите hg. Да, я действительно не понимаю, зачем это настолько нужно, чтобы выдвигать на киллер-фичу, при том, что реально ни одна другая SCM это не ведёт. N>Добавить принудительно имя ветки в сообщение тривиально за счёт локального хука, но накойхер? Там лучше держать, например, герритовский change-id. N>Остальные обобщения автора статьи про "подделку истории", "исторический ревизионизм" оставим на совести постмарксистского ярлыковедения.
Разная идеология понятия "ветка". И на мой взгляд для нормальной контролируемой команды (а не стихийного опенсорса) подход Mercurial правильнее. Да, кстати, вариант веток в стиле git'a там тоже имеется (называется bookmarks), но вроде не пользуется особой популярностью. )))
_>>Проблема не у windows (проблемы будут и в линухе), а именно у git'a при работе с ним из разных ОС. Да, возможно это правильно называть проблемой "конкретных реализаций git клиента"... Но собственно это же и есть сам git (у него нет никакой обязательной серверной части). N>Если кодировка путей стандартизована на уровне политики репо (считаю utf-8 умолчанием для 99.9% случаев), проблемы нет. Если нужно разбираться с разными локальными кодировками, то что это вообще за системы такие, и почему клиент с этим не разбирается, несмотря на явные недвусмысленные рекомендации?
Ну ОК, договорились мы всё хранить в utf-8. Можно теперь узнать с помощью какой настройки я могу сообщить об этом git'у под виндой (т.к. там дефолтная другая будет)? Естественно мы про работу из консоли говорим. )
N>>>Мне не с чем сравнивать, но вопрос в том, насколько реально нужна "сильная" в твоём понимании, и насколько она логична. _>>Не понял про что ты спрашиваешь) Про нужность хуков и расширений вообще в dcvs или же про удобство их реализации в Mercurial? Если про второе, то достаточно сказать про возможность реализации на уровне внутреннего вызова кода на Питоне. N>Про их состав. Есть где-то пример позарез нужного хука, который не сделали в Git?
Ну вообще то я говорил не про набор хуков, а про удобство расширения. Но даже если говорить про набор, то помнится в git'е раньше не было многих. Например preoutgoing и т.п. Сейчас не знаю, не смотрел, может и добавили.
N>>>Система команд очень удобна из логики "если действие с базовой концепцией X, команда будет называться X". _>>Ну я уже сказал, что это дело вкуса, а не технический вопрос. ) Но мнение что система команд mercurial удобнее своего аналога из git'a я видел неоднократно. ) N>Если есть что сравнить в плане разделения идентичных фич по командам, покажи пример. Что я пока увидел — просто отсутствие возможностей, к которым я привык как к 100% доступной и необходимой базе, типа накопить изменения чанками из разных файлов перед коммитом.
По умолчанию фиксируются все модифицированные файлы и это намного удобнее (т.к. это самый частый вариант использования), чем каждый раз писать "-a". Если надо зафиксировать изменение не всех файлов, то точно так же как и в git передаётся список в команду commit. Лично я же в таком случае предпочитаю снимать галочки в TortoiseHg. )))
Да, что касается формального сравнения разных команд... Я никогда об этом специально не задумывался, просто интуитивно чувствуется удобство в определённых случаях (потому и говорю что дело вкуса). Но вот сейчас решил чуть задуматься. Как там в git'e скажем насчёт аналога команды hg incoming?
Здравствуйте, ·, Вы писали:
_>>- проблема с сохранением истории в git. В mercurial всегда можно найти источник проблемы, а в git'е далеко не всегда. ·>Эээ... А конкретно? История иммутабельная, какие могут быть проблемы? Может кто-то просто не слышал о reflog? _>>- возможность получить гигабайтный патч при слияние веток в git. ·>Каким образом? И зачем вообще получать патчи при слиянии? _>>- проблема с кодировками в путях. Надеюсь хоть это уже исправили? ) ·>Не знаю, думаю да, это был результат unix-only. _>>- слабая работа с хуками и другими расширениями в git ·>Что это значит?
Отвечал уже в сообщениях выше на всё перечисленное.
_>>- заковыристая система команд (субъективно конечно, дело вкуса, но такое мнение можно частенько услышать) в сравнение с другими dcvs. ·>Верно, дело вкуса. Результат отказа от традиционной идеологии.
Эмм, а что значит традиционная идеология в данном случае?
_>>·>Фундамент git — лучше. Вместо традиционного (тянущееся начиная с rcs?) append-only лога, да ещё и per-file используется принципиально другой подход, ассоциативное object-хранилище. _>>Это смотря на каком уровне смотреть. Формально да, одно хранит дифы, а другое вроде как сами файлы. Но фокус в том, что если бы оно реально хранило сами файлы, то размер хранилища был бы нереальным. Так что в итоге и второе хранит дифы, просто они там для сжатия, а не для идеологии. ·>Правильно, SRP применён — хранение абстрагировано от представления, что облегчает многие фичи. И, кстати, даёт больше возможностей для оптимизации сжатия.
Однако на практике получается наоборот. Попробуй сравнить размеры хранилищ и размеры пакетов (которые bundle — самый удобный способ сравнить необходимый объём данных для синхронизации по сети) git и mercurial для одинаковых репозиториев. ) Кстати, помнится видел разные вроде как тесты (почему-то публикуемые на kernel.org — какое совпадение ), в которых git сильно выигрывает в размере репозитория у своих конкурентов. Правда там мелким шрифтом приписано, что это тестируется после применения repack в git. ))) Ну т.е. если мы после каждого изменения будем делать repack, то тогда git действительно всех обойдёт (правда советую в начале глянуть сколько времени оно занимает). А вот если взглянуть на реальность, то... )))
Здравствуйте, netch80, Вы писали:
N>Как мне узнать теперь, где я стою? "hg status" вообще ничего не пишет. (Git'овый пишет в этом случае, какой опорный коммит, состояние совпадает с какой-то веткой или это detached.) N>hg branch? Не то. hg heads? Не то. N>Инструкции молчат. Как я могу быть уверен, что делаю копию именно с нужного состояния? Только по тому, что hg update промолчала? А если я схожу на перекур? N>Если авторы не в состоянии отработать с точки зрения даже простейший сценарий использования, как можно предлагать использовать их творение?
Достаточно почитать документацию (или ты git тоже изучал методом тыка?): status — это про файлы, а про хранилище это summary. Хотя на самом деле такие очевидные вещи можно было и без документации увидеть, достаточно было ввести просто команду hg и почитать на экране список базовых команд. )))
насколько помню, раньше была проблема у гита с одновременным переименованием и изменением файла. это уже починили или все так же? вроде как история "терялась"
я почему интересуюсь, для меня, как C# программера — это базовая операция — переименование класса (class per file).
Здравствуйте, alex_public, Вы писали:
N>>Как мне узнать теперь, где я стою? "hg status" вообще ничего не пишет. (Git'овый пишет в этом случае, какой опорный коммит, состояние совпадает с какой-то веткой или это detached.) N>>hg branch? Не то. hg heads? Не то. N>>Инструкции молчат. Как я могу быть уверен, что делаю копию именно с нужного состояния? Только по тому, что hg update промолчала? А если я схожу на перекур? N>>Если авторы не в состоянии отработать с точки зрения даже простейший сценарий использования, как можно предлагать использовать их творение? _>Достаточно почитать документацию (или ты git тоже изучал методом тыка?): status — это про файлы, а про хранилище это summary.
WTF? Я как раз спрашиваю про то, к чему относится рабочая копия, значит, это про файлы, а не про хранилище.
_> Хотя на самом деле такие очевидные вещи можно было и без документации увидеть, достаточно было ввести просто команду hg и почитать на экране список базовых команд. )))
И перебирать их всех? Когда их больше 5, этот совет заведомо деструктивен.
Здравствуйте, alex_public, Вы писали:
N>>В этом примере не разное понимание, а одна мелочь — фиксация имени ветки в коммите hg. Да, я действительно не понимаю, зачем это настолько нужно, чтобы выдвигать на киллер-фичу, при том, что реально ни одна другая SCM это не ведёт. N>>Добавить принудительно имя ветки в сообщение тривиально за счёт локального хука, но накойхер? Там лучше держать, например, герритовский change-id. N>>Остальные обобщения автора статьи про "подделку истории", "исторический ревизионизм" оставим на совести постмарксистского ярлыковедения.
_>Разная идеология понятия "ветка".
Вот я _обожаю_ такие высказывания. Как только возникают вопросы про конкретные особенности веток — начинаются рассказы про "идеологию". "У нас тут своя атмосфера", видите ли. При этом ничего конкретного по сути вопроса не говорится, ссылка на идеологию всё спишет.
_> И на мой взгляд для нормальной контролируемой команды (а не стихийного опенсорса) подход Mercurial правильнее. Да, кстати, вариант веток в стиле git'a там тоже имеется (называется bookmarks), но вроде не пользуется особой популярностью. )))
Отлично. Вот у меня сейчас получилась вот такая вот картинка:
Хорошо видно, что "branch: x1" написано на двух коммитах из разных веток (цепочек из коммитов, a.k.a. changeset'ов)? Простите, это из какой такой идеологии "бранчем" именуется нечто, что может перескочить между реальными ветками разработки? Теперь ветки — это не те ветки, а не те ветки — это ветки?
Можно сколько угодно фантазировать на тему "своей атмосферы", но если появляется какая-то сущность, которая называется "ветка", а при этом становится каким-то переходящим красным знаменем между коммитами разных веток —
Ирка оббивала сигарету и шустренько цапала следующую страницу, и лицо у нее вытягивалось. „Он думал, — упавшим голосом читала она, — что трава, колышущаяся по ветру за пригорком, одна трава — это трава целиком, а трава целиком — это одна трава. Если не так, думал он, то ему, имеющему только имя, нет причины умирать…“ — „Е!..“ — икал Малянов. „Ну я не понимаю! — рыдающе восклицала Ирка. — Я вообще не понимаю, что хотел сказать автор! — Она вчитывалась еще раз. — …Одна трава — это трава целиком… а целиком — это одна трава… Слушай, может, это связано с восточными философиями? Дзэн, синто… что там у них еще… дао… Может, Глухову позвонить? Как ты думаешь?“ — „Я думаю одно, — отвечал Малянов, от обилия травы тоже несколько стервенея. — В пятницу мы должны сдать чистовой текст. Полностью. Иначе следующего заказа может вообще не быть.
это должно было называться тегом, флагом, шестиногим крокодилом или ящиком красной икры, но это не ветка. dixi, блин.
_>Ну ОК, договорились мы всё хранить в utf-8. Можно теперь узнать с помощью какой настройки я могу сообщить об этом git'у под виндой (т.к. там дефолтная другая будет)? Естественно мы про работу из консоли говорим. )
Вот честно: я винду не знаю, не умею, что там творится в её консоли — не знаю, и лечится ли это там вообще, и как именно — тоже я non rubrum legionem. Пусть мёртвые хоронят своих мертвецов, то есть те, кто мучают винду, разбираются с тем, как мучить винду. Меня эти 100500 оттенков серого не волнуют.
_>Ну вообще то я говорил не про набор хуков, а про удобство расширения. Но даже если говорить про набор, то помнится в git'е раньше не было многих. Например preoutgoing и т.п. Сейчас не знаю, не смотрел, может и добавили.
Почитал про preoutgoing. Смысла не понял. Заодно прочёл, что в нём ничего не известно и что он не зовётся при push, хотя зовётся при передаче в другое репо. Какая-то совсем вещь в себе, или опять та трава, которая не та трава.
_>По умолчанию фиксируются все модифицированные файлы и это намного удобнее (т.к. это самый частый вариант использования), чем каждый раз писать "-a". Если надо зафиксировать изменение не всех файлов, то точно так же как и в git передаётся список в команду commit. Лично я же в таком случае предпочитаю снимать галочки в TortoiseHg. )))
А часть одного файла?
Под Git я лучше алиас напишу типа "aa = add -A", если мне такое потребуется. Пока что не требовалось, я категорически считаю, что если это не какой-нибудь скрипт типа etckeeper, то добавлять все безусловно — диверсия, а если такой скрипт, то он сам сможет вызвать даже с длинной опцией. Считаю это умолчание "не сказано — значит все" грубейшей диверсией.
_>Да, что касается формального сравнения разных команд... Я никогда об этом специально не задумывался, просто интуитивно чувствуется удобство в определённых случаях (потому и говорю что дело вкуса). Но вот сейчас решил чуть задуматься. Как там в git'e скажем насчёт аналога команды hg incoming?
Делается через fetch+diff. А какой смысл в команде в таком виде, как в hg? На каждый вызов выкачивать список изменений, показывать их, но не сохранять локально? А если два вызова, оно в состоянии это закэшировать? Юзкейс совершенно непонятен.
И пока что я вижу в hg в основном такие хохмы. "Ветки", которые не ветки. "Закладки", которые тем не менее держат на себе состояние репо, хотя по смыслу названия они должны быть просто тегами. Команды с непонятным юзкейсом и заведомо неэффективным стилем исполнения. Зачем всё это?
Здравствуйте, netch80, Вы писали:
_>>Достаточно почитать документацию (или ты git тоже изучал методом тыка?): status — это про файлы, а про хранилище это summary. N>WTF? Я как раз спрашиваю про то, к чему относится рабочая копия, значит, это про файлы, а не про хранилище.
Текущая ревизия — это понятие глобальное на все файлы, т.е. относится к хранилищу.
_>> Хотя на самом деле такие очевидные вещи можно было и без документации увидеть, достаточно было ввести просто команду hg и почитать на экране список базовых команд. ))) N>И перебирать их всех? Когда их больше 5, этот совет заведомо деструктивен.
Их больше 5, но при этом около каждой из них чётко указано предназначение, так что ничего перебирать не требуется.
P.S. Что-то ты в этой темке прямо разошёлся (хотя ничего по делу я так и не увидел, правда и не рассчитывал: выбор между git и mercurial — это реально дело вкуса), а вот про эту http://rsdn.ru/forum/flame.comp/6332704
Здравствуйте, AK107, Вы писали:
AK>можно с вопросом влезть? AK>насколько помню, раньше была проблема у гита с одновременным переименованием и изменением файла. это уже починили или все так же? вроде как история "терялась"
Не терялась. Но и не сохранялась. История подобного рода может только создаваться в процессе чтения истории изменений. На уровне коммита есть только новое состояние двух объектов — исходных файлов. Само понимание того, что произошёл перенос кода, возникает на основании сравнения объектов — источников и объектов — приёмников и определяется долей неизменённого кода при этом переносе (точной границы не помню, навскидку это около 70%).
Да, я тоже хотел бы, как в darcs, алгебру изменений с возможностью логически определять каждое из них в стиле "переименование", "перенос", "форматирование" и т.п. — это очень облегчает мержинг. Но реально это не выжило ни в одной из современных массово используемых DVCS.
AK>я почему интересуюсь, для меня, как C# программера — это базовая операция — переименование класса (class per file).
Сколько при этом меняется внутри того файла? Если, например, в среднем одна строчка из 10, в истории будет факт переименования с указанием типа "91% similarity".
Здравствуйте, alex_public, Вы писали:
_>>>Достаточно почитать документацию (или ты git тоже изучал методом тыка?): status — это про файлы, а про хранилище это summary. N>>WTF? Я как раз спрашиваю про то, к чему относится рабочая копия, значит, это про файлы, а не про хранилище. _>Текущая ревизия — это понятие глобальное на все файлы, т.е. относится к хранилищу.
Оно не относится к хранилищу. Оно относится к состоянию рабочей копии. Хранилище при этом не меняется, как бы я ни двигал, какой именно коммит текущий выбранный.
_>P.S. Что-то ты в этой темке прямо разошёлся (хотя ничего по делу я так и не увидел, правда и не рассчитывал: выбор между git и mercurial — это реально дело вкуса),
Когда (см. соседнее сообщение) меня какая-то тулза заставляет переопределить давно устоявшиеся, стандартные по отрасли понятия — это уже не обычное дело вкуса, это bdsm.
_> а вот про эту http://rsdn.ru/forum/flame.comp/6332704
совсем забыл — нечего там сказать, как я понимаю? )))
Прошу запомнить раз и навсегда: отсутствие ответа не означает _ничего_. Ни "нечего сказать", ни согласия, ни чего-то подобного в принципе. Оно может означать, что участник занят другим, что собирает информацию, что намеренно решил отложить, вообще что угодно. У нас тут не платная техподдержка, у нас свободное самовыражение в рамках правил. В следующий раз я на подобный наезд на грани хамства просто пошлю куда подальше в ответ и поставлю в игнор.
Во-вторых, раз уж я тут написал предыдущие 5 строк: когда я разберусь, что там и почему, и будет, что ответить по сути — отвечу, с вероятностью процентов 90. Когда именно — не знаю. Иногда я на RSDN месяцами не хожу. Иногда поднимаю темы годовой давности. Для меня в таких темах время между репликами не играет вообще никакой роли. Если это не устраивает — никому не навязываюсь.
Здравствуйте, Cyberax, Вы писали:
C>Я не понимаю сторонников hg. Они массово не понимают как вообще работают DVCS. Git вообще тупой как пробка, там сложного нет ничего. Банально достаточно запомнить, что коммиты образуют цепочку хэшей и всё.
Вообще то все dcvs работают по этому принципу, включая и hg. Только вот поверх этого можно много чего разного накрутить. ) Хотя базовая функциональность действительно одинакова везде, особенно если использовать dcvs только из какой-нибудь IDE.
C>Достаточно уметь это понимать, и всё в git становится понятным.
А кто сказал, что он непонятный? ) Говорят только что неудобный. )
Здравствуйте, alex_public, Вы писали:
_>>>- проблема с сохранением истории в git. В mercurial всегда можно найти источник проблемы, а в git'е далеко не всегда. N>>Совершенно непонятно. Что есть "проблема" в данном случае? Источник конкретного изменения? Ищется по истории без проблем, на каждую версию строчки или бинаря есть id коммита, из которого она возникла. Развилки? Они существуют во всех DVCS. _>Даже если забыть о "низкоуровневых" возможностях правки истории в git
Правку истории можно откатить — сами объекты/коммиты не правятся, а создаются новые, так как иммутабельные by-design. Даже если потерять все ссылки на старые коммиты — они всё равно будут ещё жить некоторое время.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, D.Lans, Вы писали:
DL>>Хайпа вокруг гита не понимаю. Ладно самое красноглазное подмножество линуксоидов-ядерщиков в своём мирке юзают что им удобнее (белоглазые же линуксоиды, я слышал, почётно восседают на bazaar), но гит с хрустом начинают жевать маководы и виндузятники (к коим отношусь и я), с улыбкой гарольда-скрывающего-боль нахваливая и зазывая всех присоединиться к их клёвым проектам, худо-бедно выложенным на модный нынче гитхаб (но которые почему-то так и не получают должной популярности), я в недоумении развожу руками. C>ЩИТО? Откуда вы такую траву взяли?
C>Я не понимаю сторонников hg. Они массово не понимают как вообще работают DVCS. Git вообще тупой как пробка, там сложного нет ничего. Банально достаточно запомнить, что коммиты образуют цепочку хэшей и всё.
C>Достаточно уметь это понимать, и всё в git становится понятным.
Надо еще понимать, что есть локальный репозиторий, а не только удаленный.
Здравствуйте, alex_public, Вы писали:
_>>>Текущая ревизия — это понятие глобальное на все файлы, т.е. относится к хранилищу. N>>Оно не относится к хранилищу. Оно относится к состоянию рабочей копии. Хранилище при этом не меняется, как бы я ни двигал, какой именно коммит текущий выбранный. _>И где в рабочей копии по твоему тогда хранится информация о том, к какой ревизии она относится? )
Вот именно что ты в принципе думаешь о том, "где хранится". А пользователю это пофиг, он думает о том, с чем он работает, и концепции должны быть связаны именно этим. Если исходить из текущего построения, 1) оно может меняться, 2) каждое такое несоответствие означает один дополнительный ненужный факт для запоминания.
Иногда эти странности прилипают, и мы имеем "compiler" для конвертера в машинный код (вместо редактора связей), "virtual" ровно противоположное бытовому пониманию, и т.п. Но незачем порождать новые такие диверсии.
_>>>P.S. Что-то ты в этой темке прямо разошёлся (хотя ничего по делу я так и не увидел, правда и не рассчитывал: выбор между git и mercurial — это реально дело вкуса), N>>Когда (см. соседнее сообщение) меня какая-то тулза заставляет переопределить давно устоявшиеся, стандартные по отрасли понятия — это уже не обычное дело вкуса, это bdsm.
_>С чего ты взял, что давно устоявшиеся? ) Git/Mercurial/Bazaar родились в принципе одновременно и все три могут претендовать на основоположников терминологии.
То есть, по-твоему, до этих трёх ничего не было и никаких традиций не было? Родились на пустом месте?
Даже если ограничиться DVCS:
* BitKeeper (2000) — первая шумно известная DVCS, заложившая основы всего подхода.
* Tom Lord's Arch (позднее GNU Arch) (2001), первая opensource — дико громоздкая, неудобная, но доступная и показавшая возможность в принципе.
* Darcs (2002) — не взлетевшая толком, но знаменитая математическим подходом к "алгебре патчей" и давшая идеи для построения всех последующих.
* Monotone (2003) — второй после BitKeeper предшественник Git и источник его идей, место отработки подходов.
Git не был ничем новым — это был идейный гибрид BitKeeper и Monotone по уже отработанным сценариям.
Правильно пел когда-то Макаревич, что помнят не первых, а вторых, но в этом случае оказывается даже не вторых, а третьих.
Но что-то я ни у одной из этих систем не помню такого извращённого подхода к понятию "ветка". А учитывая, что большинство в это время только переходили с CVS и аналогов, считать надо по их опыту и соответствию общим концепциям мышления, а не "мы тут выстебнулись — а ну все подвинулись".
_> Если же говорить о реально устоявшихся, то это будет скорее SVN и более старые системы — как думаешь, к какой из DVCS их терминология будет ближе? )
К Git, если брать CVS. Вообще ни к чему из них, если брать SVN и учитывать варианты "скопировали в /release/foo весь /trunk, но в /release/foo/zuka скопировали /releng/bar/zuka". Но если не учитывать их — то SVN ближе к CVS и Git, чем к Hg, потому что нет действия типа "сегодня веткой X будет называться каталог Y". Вот если бы они ввели симлинки и назвали их ветками — было бы хоть как-то похоже.
Здравствуйте, Sharov, Вы писали:
C>>Я не понимаю сторонников hg. Они массово не понимают как вообще работают DVCS. Git вообще тупой как пробка, там сложного нет ничего. Банально достаточно запомнить, что коммиты образуют цепочку хэшей и всё. C>>Достаточно уметь это понимать, и всё в git становится понятным. S>Надо еще понимать, что есть локальный репозиторий, а не только удаленный.
Ну это как раз пишется в руководствах первым же пунктом (и это то, что меня от DVCS воротило некоторое начальное время — держать репо там же, где рабочая копия, казалось дико неестественным).
Здравствуйте, alex_public, Вы писали:
_>>>- заковыристая система команд (субъективно конечно, дело вкуса, но такое мнение можно частенько услышать) в сравнение с другими dcvs. _>·>Верно, дело вкуса. Результат отказа от традиционной идеологии. _>Эмм, а что значит традиционная идеология в данном случае?
hg многое унаследовал от svn, svn от cvs, а git делался без особой оглядки на существующие системы, а полагался на собственную архитектуру. Поэтому всё так непривычно.
_>>>Это смотря на каком уровне смотреть. Формально да, одно хранит дифы, а другое вроде как сами файлы. Но фокус в том, что если бы оно реально хранило сами файлы, то размер хранилища был бы нереальным. Так что в итоге и второе хранит дифы, просто они там для сжатия, а не для идеологии. _>·>Правильно, SRP применён — хранение абстрагировано от представления, что облегчает многие фичи. И, кстати, даёт больше возможностей для оптимизации сжатия. _>Однако на практике получается наоборот. Попробуй сравнить размеры хранилищ и размеры пакетов (которые bundle — самый удобный способ сравнить необходимый объём данных для синхронизации по сети) git и mercurial для одинаковых репозиториев. )
Не очень понял, как именно сравнить? Да и собственно даже если есть и отличие (кстати, сильно не уверен, что в пользу hg), вряд ли оно будет заметно. Даже передача тысяч ревизий занимает секунды...
_>Кстати, помнится видел разные вроде как тесты (почему-то публикуемые на kernel.org — какое совпадение ), в которых git сильно выигрывает в размере репозитория у своих конкурентов. Правда там мелким шрифтом приписано, что это тестируется после применения repack в git. ))) Ну т.е. если мы после каждого изменения будем делать repack, то тогда git действительно всех обойдёт (правда советую в начале глянуть сколько времени оно занимает). А вот если взглянуть на реальность, то... )))
...то в реальности делать repack после каждого изменения — глупость.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Dair, Вы писали:
D>Консольный Git, 2.6.0
Уже проапгрейдился, гит теперь последний, 2.7.0.
Опять круто.
Диспозиция: я в своей ветке, наменял разного, делаю коммит (не push) и готовлюсь взять последюю версию от коллег из develop, чтобы не сильно отставать. Для этого надо мне тут сделать commit, переключиться на общий develop, сделать pull, переключиться обратно, сделать merge. Делаю:
$ git commit -a
...
$ git status
нечего коммитить, нет изменений в рабочем каталоге
$ git checkout develop
Распаковка файлов: 100% (2618/2618), готово.
Переключено на ветку «develop»
Ваша ветка обновлена в соответствии с «origin/develop».
$ git pull
...
Обновление 0990c58..b4a4250
...
(в общем, success)
$ git checkout feature/my_cool_branch
error: Your local changes to the following files would be overwritten by checkout:
some/path/file1.cpp
some/path/file2.cpp
some/path/file3.cpp
some/path/file4.cpp
some/path/file5.cpp
...
Здравствуйте, netch80, Вы писали:
_>>С чего ты взял, что давно устоявшиеся? ) Git/Mercurial/Bazaar родились в принципе одновременно и все три могут претендовать на основоположников терминологии. N>То есть, по-твоему, до этих трёх ничего не было и никаких традиций не было? Родились на пустом месте? N>Даже если ограничиться DVCS: N>* BitKeeper (2000) — первая шумно известная DVCS, заложившая основы всего подхода. N>* Tom Lord's Arch (позднее GNU Arch) (2001), первая opensource — дико громоздкая, неудобная, но доступная и показавшая возможность в принципе. N>* Darcs (2002) — не взлетевшая толком, но знаменитая математическим подходом к "алгебре патчей" и давшая идеи для построения всех последующих. N>* Monotone (2003) — второй после BitKeeper предшественник Git и источник его идей, место отработки подходов. N>Git не был ничем новым — это был идейный гибрид BitKeeper и Monotone по уже отработанным сценариям. N>Правильно пел когда-то Макаревич, что помнят не первых, а вторых, но в этом случае оказывается даже не вторых, а третьих.
Вообще то если уж брать реальную историю, то первой такой системой был не BitKeeper (кстати 1998 год, а не 2000), а некий Code Co-op. Однако это всё не имеет никакого значения, т.к. все эти системы были мало известны и соответственно не могли задавать никаких традиции в индустрии.
N>Но что-то я ни у одной из этих систем не помню такого извращённого подхода к понятию "ветка". А учитывая, что большинство в это время только переходили с CVS и аналогов, считать надо по их опыту и соответствию общим концепциям мышления, а не "мы тут выстебнулись — а ну все подвинулись".
Вообще то понятие ветка в Mercurial точно такое же, как и везде. Если ты не сумел разобраться, то это не значит что там что-то не так. Для начала не плохо бы почитать документацию.
_>> Если же говорить о реально устоявшихся, то это будет скорее SVN и более старые системы — как думаешь, к какой из DVCS их терминология будет ближе? ) N>К Git, если брать CVS. Вообще ни к чему из них, если брать SVN и учитывать варианты "скопировали в /release/foo весь /trunk, но в /release/foo/zuka скопировали /releng/bar/zuka". Но если не учитывать их — то SVN ближе к CVS и Git, чем к Hg, потому что нет действия типа "сегодня веткой X будет называться каталог Y". Вот если бы они ввели симлинки и назвали их ветками — было бы хоть как-то похоже.
Здравствуйте, netch80, Вы писали:
_>>Покажи к чему приведут аналогичные действия в git'e и мы вместе посмеёмся. ))) N>Такой ситуации просто не возникнет. А если ты решишь вписать неадекватное имя ветки вручную в коммит — что ж, это было твоё решение.
Т.е. я правильно понимаю, что при работе с Git рекомендуется не нарушать некие правила, а при работе с Mercurial наоборот? )))
_>>О, кстати, ещё один практический нюанс вспомнился... Работа с автоматическими анонимными ветками намного удобнее в Mercurial. Собственно не помню как вообще в Git с ними работать (скажем аналог команды heads?). N>Опиши желаемое подробнее, не понимаю.
Ну очевидно же) Фиксируем некие изменения, потом откатываемся назад на одну ревизию, снова что-то меняем и снова фиксируем (не создавая новых веток вообще). Кстати, аналогичного можно добиться и проще (как раз более практичный вариант) — фиксация своих изменений несколькими разработчиками в одну и ту же ветку, с последующей синхронизацией.
Что будет в таком случае в git и как с этим удобно работать? )
В Mercurial всё будет крайне удобно и это собственно один из нормальных сценариев работы.
_>>Полезно для создания нестандартных каналов передачи (скажем с шифрованием и т.п.). N>В Git банально переопределяется команда связи.
Ой, вот как раз насчёт удобства расширения в Git я бы вообще помолчал))) Там с API всё настолько печально... )
N>>>А часть одного файла? _>>Эээ, что что? ) N>Я занимаюсь лечением бага. Для его диагностики вставлено 6 мест отладочной печати. Затем вписано 4 исправления собственно этого бага, причём 2 из них на рефакторинг "выделить код в отдельный метод" и 2 на исправление ошибки. Всё это в одном файле. N>Мне нужно создать 2 коммита — рефакторинг и исправление — и оставить отладочную печать на несколько дней, пока не завершится, грубо говоря, весь деплоймент. N>Git даёт сразу несколько методов набирать только те патчи из всех изменений, которые нужны для текущего коммита. N>Ни в одной другой VCS я такого не видел. Врапперы во всяких IDE не учитывать.
Ужасы какие) Как раз для таких дел и создают отдельные ветки (отладочная, релизная и т.п.).
Здравствуйте, Dair, Вы писали:
D>Диспозиция: я в своей ветке, наменял разного, делаю коммит (не push) и готовлюсь взять последюю версию от коллег из develop, чтобы не сильно отставать. Для этого надо мне тут сделать commit, переключиться на общий develop, сделать pull, переключиться обратно, сделать merge. Делаю:
Что-то странные пляски. Зачем переключаться-то? Просто делаешь "git fetch", потом "git merge origin/develop", мержить можно и удалённые ветки.
D>
А что diff показывает?
Чую какая-то беда с line endings
D>Проверил сторонние процессы — никого нет, никто к файлам не доступается.
IDE может нахулиганить
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
_>>·>Верно, дело вкуса. Результат отказа от традиционной идеологии. _>>Эмм, а что значит традиционная идеология в данном случае? ·>hg многое унаследовал от svn, svn от cvs, а git делался без особой оглядки на существующие системы, а полагался на собственную архитектуру. Поэтому всё так непривычно.
противоположное мнение высказывается. )
_>>Однако на практике получается наоборот. Попробуй сравнить размеры хранилищ и размеры пакетов (которые bundle — самый удобный способ сравнить необходимый объём данных для синхронизации по сети) git и mercurial для одинаковых репозиториев. ) ·>Не очень понял, как именно сравнить? Да и собственно даже если есть и отличие (кстати, сильно не уверен, что в пользу hg), вряд ли оно будет заметно. Даже передача тысяч ревизий занимает секунды...
Ну возьми просто один большой (скажем на мегабайт, для простоты эксперимента) и кинь его пустой репозиторий. Ну поменяй пару строк и зафиксируй. И посмотри размер хранилища. Для hg и для git.
Ну а что касается обмена изменениями, то для последних ревизий (где пара строк менялась) разница действительно не принципиальна (типа 100 байт или 200), а вот если взять все ревизии (тогда оно будет включать файлы целиком), то опять же будет весьма интересный результат...
_>>Кстати, помнится видел разные вроде как тесты (почему-то публикуемые на kernel.org — какое совпадение ), в которых git сильно выигрывает в размере репозитория у своих конкурентов. Правда там мелким шрифтом приписано, что это тестируется после применения repack в git. ))) Ну т.е. если мы после каждого изменения будем делать repack, то тогда git действительно всех обойдёт (правда советую в начале глянуть сколько времени оно занимает). А вот если взглянуть на реальность, то... ))) ·>...то в реальности делать repack после каждого изменения — глупость.
Согласен. ) И в таком случае выигрывать по размеру хранилища будет скорее Mercurial.
Здравствуйте, AK107, Вы писали:
AK>Здравствуйте, netch80, Вы писали:
AK>можно с вопросом влезть?
AK>насколько помню, раньше была проблема у гита с одновременным переименованием и изменением файла. это уже починили или все так же? вроде как история "терялась"
AK>я почему интересуюсь, для меня, как C# программера — это базовая операция — переименование класса (class per file).
Здравствуйте, alex_public, Вы писали:
_>·>hg многое унаследовал от svn, svn от cvs, а git делался без особой оглядки на существующие системы, а полагался на собственную архитектуру. Поэтому всё так непривычно. _>Согласен) Хотя вот тут http://rsdn.ru/forum/flame.comp/6335165.1
противоположное мнение высказывается. )
Ну, если более старые DVCS рассматривать, то да. Но накой DVCS hg начала что-то тянуть из centralised VCS типа svn... это не совсем разумное решение. Может в короткой перспективе, перетянуть юзеров, это и хорошо, но лучше в этом болоте не засиживаться.
_>·>Не очень понял, как именно сравнить? Да и собственно даже если есть и отличие (кстати, сильно не уверен, что в пользу hg), вряд ли оно будет заметно. Даже передача тысяч ревизий занимает секунды... _>Ну возьми просто один большой (скажем на мегабайт, для простоты эксперимента) и кинь его пустой репозиторий. Ну поменяй пару строк и зафиксируй. И посмотри размер хранилища. Для hg и для git.
Игрушечных экспериментов, которые плохо сработают для hg я могу тоже насочинять. Например, добавить тот же файл дважды в разные каталоги.
_>Ну а что касается обмена изменениями, то для последних ревизий (где пара строк менялась) разница действительно не принципиальна (типа 100 байт или 200), а вот если взять все ревизии (тогда оно будет включать файлы целиком), то опять же будет весьма интересный результат...
Эээ.. А как ещё? Если хочется патчи, бери патчи.
_>·>...то в реальности делать repack после каждого изменения — глупость. _>Согласен. ) И в таком случае выигрывать по размеру хранилища будет скорее Mercurial.
Будет, но не долго, до первого же repack.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, alex_public, Вы писали:
_>Вообще то если уж брать реальную историю, то первой такой системой был не BitKeeper (кстати 1998 год, а не 2000), а некий Code Co-op. Однако это всё не имеет никакого значения, т.к. все эти системы были мало известны и соответственно не могли задавать никаких традиции в индустрии.
Во-первых: я тоже далеко не первых назвал, я назвал хорошо известных предыдущих.
Во-вторых, я не знаю, где ты был в этой индустрии в те времена, если ты не заметил, например, шума про то, что Линус, после того, как много лет "по матушке" посылал хотя бы за идею вести разработку или даже публичное репо нумерованных версий в доступных тогда средствах вроде CVS — вдруг разразился "все на BitKeeper!" — шок был весьма существенный.
Я был тогда (как и сейчас) среди активных юниксоедов, подо мной была существенная часть ответственности интернет-провайдера, у нас были линуксы, и за всем этим я пристально следил (находясь на позиции "лучше CVS, чем ничего" — с чем регулярно спорил с активными линуксоманами).
N>>Но что-то я ни у одной из этих систем не помню такого извращённого подхода к понятию "ветка". А учитывая, что большинство в это время только переходили с CVS и аналогов, считать надо по их опыту и соответствию общим концепциям мышления, а не "мы тут выстебнулись — а ну все подвинулись". _>Вообще то понятие ветка в Mercurial точно такое же, как и везде. Если ты не сумел разобраться, то это не значит что там что-то не так. Для начала не плохо бы почитать документацию.
Я почитал, и попробовал, и уже дважды объяснил, что не так в этих ветках. Более того, ты сам говоришь "привычные мне ветки зовутся bookmarks". Разберись сначала, как самому себе не противоречить.
_>>> Если же говорить о реально устоявшихся, то это будет скорее SVN и более старые системы — как думаешь, к какой из DVCS их терминология будет ближе? ) N>>К Git, если брать CVS. Вообще ни к чему из них, если брать SVN и учитывать варианты "скопировали в /release/foo весь /trunk, но в /release/foo/zuka скопировали /releng/bar/zuka". Но если не учитывать их — то SVN ближе к CVS и Git, чем к Hg, потому что нет действия типа "сегодня веткой X будет называться каталог Y". Вот если бы они ввели симлинки и назвали их ветками — было бы хоть как-то похоже.
_>А вот тут http://rsdn.ru/forum/flame.comp/6335381.1
Здравствуйте, alex_public, Вы писали:
_>>>Покажи к чему приведут аналогичные действия в git'e и мы вместе посмеёмся. ))) N>>Такой ситуации просто не возникнет. А если ты решишь вписать неадекватное имя ветки вручную в коммит — что ж, это было твоё решение. _>Т.е. я правильно понимаю, что при работе с Git рекомендуется не нарушать некие правила, а при работе с Mercurial наоборот? )))
Разница в том, что в Git при ветках, которые ветки, правила просты и логичны. В Hg разрыв между нормальным пониманием ветки и тем, что там называется этим словом, приводит к бардаку. Если переименуете на другой термин, который не конфликтует с языком, часть жалоб уйдёт.
_>>>О, кстати, ещё один практический нюанс вспомнился... Работа с автоматическими анонимными ветками намного удобнее в Mercurial. Собственно не помню как вообще в Git с ними работать (скажем аналог команды heads?). N>>Опиши желаемое подробнее, не понимаю. _>Ну очевидно же) Фиксируем некие изменения, потом откатываемся назад на одну ревизию,
Как именно откатываемся? Вообще удаляем последнюю ревизию или сохраняем?
_> снова что-то меняем и снова фиксируем (не создавая новых веток вообще).
Ну. Будет новый последний коммит в текущей ветке.
_> Кстати, аналогичного можно добиться и проще (как раз более практичный вариант) — фиксация своих изменений несколькими разработчиками в одну и ту же ветку, с последующей синхронизацией.
Пофиг, как ветка называется у каждого конкретного разработчика, важно, в какую в общем репо они вливают (и с какой мержатся).
_>Что будет в таком случае в git и как с этим удобно работать? )
Я продолжаю не понимать вопроса. Первый встречный вопрос: то изменение, которое было последним вначале, оно должно быть сохранено или нет?
_>В Mercurial всё будет крайне удобно и это собственно один из нормальных сценариев работы.
В Git всё будет "крайне удобно", но после того, как ты наконец объяснишь, чего ты именно хочешь и зачем.
N>>>>А часть одного файла? _>>>Эээ, что что? ) N>>Я занимаюсь лечением бага. Для его диагностики вставлено 6 мест отладочной печати. Затем вписано 4 исправления собственно этого бага, причём 2 из них на рефакторинг "выделить код в отдельный метод" и 2 на исправление ошибки. Всё это в одном файле. N>>Мне нужно создать 2 коммита — рефакторинг и исправление — и оставить отладочную печать на несколько дней, пока не завершится, грубо говоря, весь деплоймент. N>>Git даёт сразу несколько методов набирать только те патчи из всех изменений, которые нужны для текущего коммита. N>>Ни в одной другой VCS я такого не видел. Врапперы во всяких IDE не учитывать.
_>Ужасы какие) Как раз для таких дел и создают отдельные ветки (отладочная, релизная и т.п.).
При чём тут вообще какие-то отдельные ветки? Описанные проблемы и методы решения не зависят от того, это develop, old stable или что-то ещё.
противоположное мнение высказывается. ) ·>Ну, если более старые DVCS рассматривать, то да. Но накой DVCS hg начала что-то тянуть из centralised VCS типа svn... это не совсем разумное решение. Может в короткой перспективе, перетянуть юзеров, это и хорошо, но лучше в этом болоте не засиживаться.
Не, я не про старые DVCS. Там ниже было высказывание, что к CVS и SVN ближе Git, а не Mercurial. )
_>>Ну возьми просто один большой (скажем на мегабайт, для простоты эксперимента) и кинь его пустой репозиторий. Ну поменяй пару строк и зафиксируй. И посмотри размер хранилища. Для hg и для git. ·>Игрушечных экспериментов, которые плохо сработают для hg я могу тоже насочинять. Например, добавить тот же файл дважды в разные каталоги.
ОК, давай возьмём просто любой большой проект и кинем его в чистый репозиторий) Причём это ещё будет максимально лояльным для Git тестом, т.к. у него размер существенно растёт именно с числом изменений.
_>>Ну а что касается обмена изменениями, то для последних ревизий (где пара строк менялась) разница действительно не принципиальна (типа 100 байт или 200), а вот если взять все ревизии (тогда оно будет включать файлы целиком), то опять же будет весьма интересный результат... ·>Эээ.. А как ещё? Если хочется патчи, бери патчи.
Не, я не про это. Я про размер получаемого файла (в котором по сути содержится весь репозиторий). Какой он будет у Mercurial, а какой у Git. Тут же утверждали, что низкоуровневая архитектура у Git более продумана и позволяет большее сжатие и т.п. А на практике...
_>>·>...то в реальности делать repack после каждого изменения — глупость. _>>Согласен. ) И в таком случае выигрывать по размеру хранилища будет скорее Mercurial. ·>Будет, но не долго, до первого же repack.
Угу и потом ещё пару изменений продержится на минимуме, а потом снова... )))
Здравствуйте, netch80, Вы писали:
_>>Вообще то если уж брать реальную историю, то первой такой системой был не BitKeeper (кстати 1998 год, а не 2000), а некий Code Co-op. Однако это всё не имеет никакого значения, т.к. все эти системы были мало известны и соответственно не могли задавать никаких традиции в индустрии. N>Во-первых: я тоже далеко не первых назвал, я назвал хорошо известных предыдущих. N>Во-вторых, я не знаю, где ты был в этой индустрии в те времена, если ты не заметил, например, шума про то, что Линус, после того, как много лет "по матушке" посылал хотя бы за идею вести разработку или даже публичное репо нумерованных версий в доступных тогда средствах вроде CVS — вдруг разразился "все на BitKeeper!" — шок был весьма существенный. N>Я был тогда (как и сейчас) среди активных юниксоедов, подо мной была существенная часть ответственности интернет-провайдера, у нас были линуксы, и за всем этим я пристально следил (находясь на позиции "лучше CVS, чем ничего" — с чем регулярно спорил с активными линуксоманами).
Хы, в 1997 самый громкий шум в мире линуха был неслышным шорохом на уровне остальной IT индустрии. ))) Кстати, это и сейчас не так чтобы радикально изменилось, но хотя бы в мире сервером и встроенных систем люди прислушаются. ) А тогда это вообще были какие-то игры маргиналов. )
_>>Вообще то понятие ветка в Mercurial точно такое же, как и везде. Если ты не сумел разобраться, то это не значит что там что-то не так. Для начала не плохо бы почитать документацию. N>Я почитал, и попробовал, и уже дважды объяснил, что не так в этих ветках. Более того, ты сам говоришь "привычные мне ветки зовутся bookmarks". Разберись сначала, как самому себе не противоречить.
Не, ветки из git'a, которые не сохраняются, а просто являются указателями на последние ревизии — они похожи на bookmarks. А как раз в самом Mercurial нормальные ветки. Просто ты не понял что сам сделал в системе и решил из этого какие-то выводы извлечь. )))
_>>А вот тут http://rsdn.ru/forum/flame.comp/6335381.1
высказывается (и не мною) прямо противоположное мнение. ))) N>Я не вижу там никакого противоречия тому, что я говорю. Разъясни подробнее, если видишь.
Вроде как там ясно написано, что старым системам (cvs, svn и т.п.) ближе mercurial, а git наоборот отбросил все традиции и поэтому непривычен. Это полностью противоречит твой фразе о том, что к старым системам ближе git, а mercurial забил на традиции.
Здравствуйте, ·, Вы писали:
_>>Не, я не про старые DVCS. Там ниже было высказывание, что к CVS и SVN ближе Git, а не Mercurial. ) ·>Там вроде про ветки. Ветки — да, в hg это нечто уникальное, неповторимое понимание, попытка натянуть сову на глобус. Где ещё есть многоголовые ветки?
Хы, они не многоголовые) Надо просто понимать, что в mercurial есть как именованные ветки, так и анонимные (такого в git насколько я помню вообще нет?). ) Но при этом это всё полноценные ветки со всеми механизмами работы с ними. )
И кстати говоря это один из самых удобных инструментов работы.
_>>ОК, давай возьмём просто любой большой проект и кинем его в чистый репозиторий) Причём это ещё будет максимально лояльным для Git тестом, т.к. у него размер существенно растёт именно с числом изменений. ·>Дело было вечером, делать было нечего. Я взял openssl-1.0.1r.tar.gz, 4.4мб, распаковал 44мб исходников, 2183 файлов, 130 каталогов... Что-то плохо всё с hg: ·>... ·>Время в секундах, размер в мегабайтах. hg 3.4, git 2.0.3, ubuntu, linux 4.2.0-23. ·>Очень интересно — размер repacked git репо сравним с tar.gz тех же данных. ·>Проведи такой же эксперимент — интересно будут такие же результаты или я что-то не так померил...
Нормально всё померил) Только вот где "плохо всё с hg"? Всё в точности, как я и говорил. Даже при наличие всего одного набора данных в хранилище mercurial занял 30 мегов, а git 32, как я собственно и говорил. Причём при дальнейшей работе эта разница ещё увеличится.
Если же ты намекаешь на размер после repack (5,8 мегов), который ты забавно назвал "size final", то мы вроде как уже обсудили, что к реальности оно никакого отношения не имеет.
_>>Не, я не про это. Я про размер получаемого файла (в котором по сути содержится весь репозиторий). Какой он будет у Mercurial, а какой у Git. Тут же утверждали, что низкоуровневая архитектура у Git более продумана и позволяет большее сжатие и т.п. А на практике... ·>... так и получается. ·>А вообще, какого файла?.. Если у тебя полная ревизия, то да, будет полный снапшот, если это diff, будет diff.
Не важно что) Главное чтобы одинаковое было (по смыслу) и в mercurial и в git.
·>Как это зависит от vcs?
Разные форматы этих файлов и разные алгоритмы сжатия. Собственно так же как и в самом хранилище. Легко увидеть где оптимальнее... )))
_>>·>Будет, но не долго, до первого же repack. _>>Угу и потом ещё пару изменений продержится на минимуме, а потом снова... ))) ·>Может в каких-то ситуациях так и может быть, но обычно с точностью до наоборот.
Как же это наоборот, если твои же собственные измерения подтвердили мои слова? ) Или ты всё же настаиваешь на том, что стоит учитывать в оценке размер после repack? )))
Кстати, интересно было бы сделать опрос на форуме, среди активных пользователей git. Сколько раз они делали repack для своих проектов? Что-то я подозреваю, что многие даже не в курсе про подобную функцию. )))
Здравствуйте, ·, Вы писали:
·>Здравствуйте, Mazenrab, Вы писали:
AK>>>я почему интересуюсь, для меня, как C# программера — это базовая операция — переименование класса (class per file). M>>На днях натыкался — есть такая проблема. ·>Да нет такой проблемы, открой для себя "git log -M" или ещё круче — "git blame -C", который может найти, например, перемещённый метод из одного файла в другой (такого в hg вроде нет).
Спасибо, попробую при случае. Но я вообще стараюсь пользоваться встроенным в студию инструментарием полагая что так сложнее выстрелить себе в ногу.
Здравствуйте, alex_public, Вы писали:
_>>>Не, я не про старые DVCS. Там ниже было высказывание, что к CVS и SVN ближе Git, а не Mercurial. ) _>·>Там вроде про ветки. Ветки — да, в hg это нечто уникальное, неповторимое понимание, попытка натянуть сову на глобус. Где ещё есть многоголовые ветки? _>Хы, они не многоголовые)
А это о чём тогда? http://stackoverflow.com/questions/6927733/mercurial-how-to-deal-with-one-branch-that-has-two-heads
_>Надо просто понимать, что в mercurial есть как именованные ветки, так и анонимные (такого в git насколько я помню вообще нет?). )
Деструктивного влияния централизованных VCS на DVCS? Нет, конечно.
_> Но при этом это всё полноценные ветки со всеми механизмами работы с ними. ) _>И кстати говоря это один из самых удобных инструментов работы.
Ага, чуть что — создавайте клоны.
_>·>Очень интересно — размер repacked git репо сравним с tar.gz тех же данных. _>·>Проведи такой же эксперимент — интересно будут такие же результаты или я что-то не так померил... _>Нормально всё померил) Только вот где "плохо всё с hg"? Всё в точности, как я и говорил. Даже при наличие всего одного набора данных в хранилище mercurial занял 30 мегов, а git 32, как я собственно и говорил.
За почти вдвое большее время работы hg мог бы постараться сжать получше, чем на 10%, которые в пределах погрешности измерения.
_>Причём при дальнейшей работе эта разница ещё увеличится.
Враньё. Или факты в студию.
_>Если же ты намекаешь на размер после repack (5,8 мегов), который ты забавно назвал "size final", то мы вроде как уже обсудили, что к реальности оно никакого отношения не имеет.
Именно это и будет реальный размер в любом долгоживущем или свежесклонированном репозитории.
_>·>... так и получается. _>·>А вообще, какого файла?.. Если у тебя полная ревизия, то да, будет полный снапшот, если это diff, будет diff. _>Не важно что) Главное чтобы одинаковое было (по смыслу) и в mercurial и в git.
За счёт чего ты ожидаешь какую-то существенную разницу? Я ожидаю разницу в пользу git, т.к. он имеет более подходящие структуры данных.
_>·>Как это зависит от vcs? _>Разные форматы этих файлов и разные алгоритмы сжатия. Собственно так же как и в самом хранилище. Легко увидеть где оптимальнее... )))
Ну? В git лучше форматы и алгоритмы. Я не понимаю зачем ты доказываешь преимущества git, я и не спорю с этим.
_>>>Угу и потом ещё пару изменений продержится на минимуме, а потом снова... ))) _>·>Может в каких-то ситуациях так и может быть, но обычно с точностью до наоборот. _>Как же это наоборот, если твои же собственные измерения подтвердили мои слова? ) Или ты всё же настаиваешь на том, что стоит учитывать в оценке размер после repack? )))
Конечно, я же учитываю стандартный реальный юзкейс, а не мысленные эксперименты, основанные на священной вере.
_>Кстати, интересно было бы сделать опрос на форуме, среди активных пользователей git. Сколько раз они делали repack для своих проектов? Что-то я подозреваю, что многие даже не в курсе про подобную функцию. )))
Да никто его вручную обычно не делает, он сам выполняется периодически, когда становится слишком много loose objects.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, alex_public, Вы писали:
_>>>Хы, они не многоголовые) _>·>А это о чём тогда? http://stackoverflow.com/questions/6927733/mercurial-how-to-deal-with-one-branch-that-has-two-heads _>Да просто очередной не читавший документацию и не смогший понять, что у него теперь просто две ветки.
Покажи документацию, которую читаешь ты.
_>>>Надо просто понимать, что в mercurial есть как именованные ветки, так и анонимные (такого в git насколько я помню вообще нет?). ) _>·>Деструктивного влияния централизованных VCS на DVCS? Нет, конечно. _>А причём тут централизованные системы? ) Там как раз ничего подобного нет. )
hg пытается сидеть на двух стульях, вроде как dvcs, а имена веток — глобальные, как в cvcs. А ещё эти приколы с номерами ревизий...
_>Эм, какие клоны? ) Ты вообще о чём? ) Я говорил об удобстве работы на базе использования анонимных веток в mercurial (которые автоматически создаются, когда обнаруживается двое или более ревизий потомком у одной базовой). Причём это удобно даже если говорить не о синхронизации нескольких разработчиков (там это вообще идеально полезно), а о просто одиночной работе — неудобно придумывать название и создавать руками отдельную ветку ради маленького одиночного эксперимента с кодом (довольно распространённый сценарий).
Скажи... Ты читал документацию на "hg heads"? Что показывает эта команда в формате "hg heads <branchname>"? В каком словаре слово "head" означает "анонимная ветка"?
_>>>Нормально всё померил) Только вот где "плохо всё с hg"? Всё в точности, как я и говорил. Даже при наличие всего одного набора данных в хранилище mercurial занял 30 мегов, а git 32, как я собственно и говорил. _>·>За почти вдвое большее время работы hg мог бы постараться сжать получше, чем на 10%, которые в пределах погрешности измерения. _>Ну так про время собственно никто ничего и не говорил. ) Но если уж и говорить, то ты же понимаешь, что такие изменения на практике никогда не встречаются (это только для теста было), так что и подобных задержек тоже.
Так и незапакованные гит-репозитории на практике никогда не встречаются.
А если не учитывать время, то hg тупо слил по размеру в 6 раз!
_>>>Причём при дальнейшей работе эта разница ещё увеличится. _>·>Враньё. Или факты в студию. _>Это общеизвестный факт (если конечно же не делать периодических ручных repack'ов).
Нет, типичное враньё.
_>>>Если же ты намекаешь на размер после repack (5,8 мегов), который ты забавно назвал "size final", то мы вроде как уже обсудили, что к реальности оно никакого отношения не имеет. _>·>Именно это и будет реальный размер в любом долгоживущем или свежесклонированном репозитории. _>Уууу) _>У себя на диске (у тебя же есть свои проекты в git не так ли?) проверь для начала. )))
Проверял, неоднократно. Все мои репозитории запакованы.
_>>>·>А вообще, какого файла?.. Если у тебя полная ревизия, то да, будет полный снапшот, если это diff, будет diff. _>>>Не важно что) Главное чтобы одинаковое было (по смыслу) и в mercurial и в git. _>·>За счёт чего ты ожидаешь какую-то существенную разницу? Я ожидаю разницу в пользу git, т.к. он имеет более подходящие структуры данных. _>Мне не важно за счёт чего.
Пока это похоже на священную веру — фактов нет, тестов нет, почему — не важно, но свято веришь.
_>Я просто проверял и знаю ответ. Но предлагаю тебе убедиться самому. )
Я давно уже убедился.
_>>>·>Как это зависит от vcs? _>>>Разные форматы этих файлов и разные алгоритмы сжатия. Собственно так же как и в самом хранилище. Легко увидеть где оптимальнее... ))) _>·>Ну? В git лучше форматы и алгоритмы. Я не понимаю зачем ты доказываешь преимущества git, я и не спорю с этим. _>Ну так практика то говорит что хуже. ))) Проверь сам. ) Только по честному, без предварительных ручных repack'ов репозитория. )))
Опиши эксперимент, а лучше проведи сам. Разницу в 10-20% не учитывать, ибо не принципиальна.
_>>>Как же это наоборот, если твои же собственные измерения подтвердили мои слова? ) Или ты всё же настаиваешь на том, что стоит учитывать в оценке размер после repack? ))) _>·>Конечно, я же учитываю стандартный реальный юзкейс, а не мысленные эксперименты, основанные на священной вере. _>С чего ты взял, что он стандартный? ) Насколько часто лично ты делаешь repack своих личных проектов? )
Никогда не делаю. Ещё раз повторяю — git сам repack делает, если ему явно не запретить.
_>>>Кстати, интересно было бы сделать опрос на форуме, среди активных пользователей git. Сколько раз они делали repack для своих проектов? Что-то я подозреваю, что многие даже не в курсе про подобную функцию. ))) _>·>Да никто его вручную обычно не делает, он сам выполняется периодически, когда становится слишком много loose objects. _>Ага, вот и реальность проявляется...
_>Давай всё же подведём какой-то итог данному подразделу нашей дискуссий. Моё утверждение было такое: хранилище mercurial занимает меньше места чем хранилище git без постоянных ручных repack'ов последнего, а этим никто в реальности не занимается. Поясни с какой его частью (первой или второй) ты всё же не согласен.
"постоянных ручных repack'ов последнего, а этим никто в реальности не занимается" — с этим согласен, никто вручную repack не делает в реальности.
"хранилище mercurial занимает меньше места" — не согласен, т.к. надо рассматривать пакованный репо, ибо в реальности репы пакованные.
_>P.S. На самом деле лично мне вообще то совсем не принципиален размер хранилища, просто этот вопрос всплыл в контексте сравнения эффективности внутренней архитектуры этих двух систем.
"Меньше места" не единственный эффект более продуманной архитектуры. Это так же даёт перформанс, простоту алгоритмов.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
_>>Да просто очередной не читавший документацию и не смогший понять, что у него теперь просто две ветки. ·>Покажи документацию, которую читаешь ты.
Здесь https://www.mercurial-scm.org/wiki/Branch всё подробно рассказано. Почему-то пользователи git путают "branch name" (всего лишь атрибут ревизии) и реальные ветки (а вот их в упор не видят, хотя они и являются основным инструментом). И в результате получают глупости типа описанных в последнем предложение по моей ссылке. )))
_>>А причём тут централизованные системы? ) Там как раз ничего подобного нет. ) ·>hg пытается сидеть на двух стульях, вроде как dvcs, а имена веток — глобальные, как в cvcs. А ещё эти приколы с номерами ревизий...
А расскажи, чем по твоему неудобны глобальные имена веток? ) Про номера ревизий не понял в чём проблема, это всего лишь локальные хоткеи для удобства (если не хочешь, можешь вообще не обращать на них внимание) адресации.
_>>Эм, какие клоны? ) Ты вообще о чём? ) Я говорил об удобстве работы на базе использования анонимных веток в mercurial (которые автоматически создаются, когда обнаруживается двое или более ревизий потомком у одной базовой). Причём это удобно даже если говорить не о синхронизации нескольких разработчиков (там это вообще идеально полезно), а о просто одиночной работе — неудобно придумывать название и создавать руками отдельную ветку ради маленького одиночного эксперимента с кодом (довольно распространённый сценарий). ·>Скажи... Ты читал документацию на "hg heads"? Что показывает эта команда в формате "hg heads <branchname>"? В каком словаре слово "head" означает "анонимная ветка"?
Ну так правильно, heads то показывает не все существующие ветки в репозитории, а только некое подмножество — не слитые. А heads <branchname> показывает ещё более мелкое подмножество — помеченные определённым именем.
Так а может ты пояснишь, какой аналог анонимных веток у нас в git? ) Т.е. что делать при нескольких параллельных изменения относительно одной родительской ревизии, обязательно заводить отдельную именованную ветку? )
_>>Ну так про время собственно никто ничего и не говорил. ) Но если уж и говорить, то ты же понимаешь, что такие изменения на практике никогда не встречаются (это только для теста было), так что и подобных задержек тоже. ·>Так и незапакованные гит-репозитории на практике никогда не встречаются. ·>А если не учитывать время, то hg тупо слил по размеру в 6 раз!
Ну давай объясни мне в какой момент произойдёт на практике это чудесная автоматическая перепаковка. Вот завёл я чистый репозиторий. Кинул в него несколько больших (для удобства теста) текстовых файлов — ничего нет. Добавил несколько ревизий — всё равно ничего нет (а размер хранилища уже за мегабайт вылезает, в то время как у mercurial намного меньше). Так когда же? )
_>>>>Причём при дальнейшей работе эта разница ещё увеличится. _>>·>Враньё. Или факты в студию. _>>Это общеизвестный факт (если конечно же не делать периодических ручных repack'ов). ·>Нет, типичное враньё.
Враньё. ) Ну или же ты с ними просто не работаешь (склонировал с каких-то серверов и всё).
_>>Ну так практика то говорит что хуже. ))) Проверь сам. ) Только по честному, без предварительных ручных repack'ов репозитория. ))) ·>Опиши эксперимент, а лучше проведи сам. Разницу в 10-20% не учитывать, ибо не принципиальна.
Берём текстовый файл на мегабайт (чтобы ясно была разница, а то там всякие накладные расходы и т.п.). Кидаем в чистый репозиторий. Фиксируем ревизию. Меняем одну строчку в файле, снова фиксируем. Делаем пакет (bundle) из одной последней ревизии и смотрим размер файла (число1, должно быть очень маленькое), делаем пакет из двух последних ревизий (по сути будет весь репозиторий) и смотрим размер файла (число2, должно быть большое). Выполняем эту последовательность и для mercurial и для git, а потом сравниваем в начале две версии числа1, а потом две версии числа 2.
_>>Давай всё же подведём какой-то итог данному подразделу нашей дискуссий. Моё утверждение было такое: хранилище mercurial занимает меньше места чем хранилище git без постоянных ручных repack'ов последнего, а этим никто в реальности не занимается. Поясни с какой его частью (первой или второй) ты всё же не согласен. ·>"постоянных ручных repack'ов последнего, а этим никто в реальности не занимается" — с этим согласен, никто вручную repack не делает в реальности. ·>"хранилище mercurial занимает меньше места" — не согласен, т.к. надо рассматривать пакованный репо, ибо в реальности репы пакованные.
Пакованным они будут до добавления новых ревизий, т.е. очень не долго. )
_>>P.S. На самом деле лично мне вообще то совсем не принципиален размер хранилища, просто этот вопрос всплыл в контексте сравнения эффективности внутренней архитектуры этих двух систем. ·>"Меньше места" не единственный эффект более продуманной архитектуры. Это так же даёт перформанс, простоту алгоритмов.
Ну для начала с "много места" мы ещё и не разобрались. И кстати говоря у всех подходов есть свои недостатки. Даже если взять за основу идею с repack'ом, то помимо проблем с расписанием данной работы, данная техника к примеру блокирует возможность инкрементальных бэкапов хранилища.
"The term branch is sometimes used for slightly different concepts. This may be confusing for new users of Mercurial." Золотые слова. Вот пока оно будет использоваться, и не под "slightly" разные концепции, а под существенно разные, будет постоянный бардак между ветками, которые специализированные теги коммитов, ветками, которые пучки веток, ветки, которые ещё не слитые ветки (как в твоём ниже про heads) и так далее.
Если этот бардак убрать и нормализовать терминологию, уровень проблем с Hg резко уменьшится, а пользователей таки добавится. Может, и я попробую его в работе хотя нет, для этого нужен ещё и аналог гитового index с полноценной поддержкой, и interactive rebase с его возможностями по расщеплению, слиянию и перестановке коммитов, модификации батчем. Вот после этого для меня они будут близки к эквивалентам.
_>Почему-то пользователи git путают "branch name" (всего лишь атрибут ревизии) и реальные ветки (а вот их в упор не видят, хотя они и являются основным инструментом). И в результате получают глупости типа описанных в последнем предложение по моей ссылке. )))
Не "пользователи git", не надо натяжек, а все, кто не пришёл к этому "дети, это невозможно понять, но это надо запомнить". Я пытался разобраться с Hg, ещё не зная Git, запутался в этом бардаке, плюнул и забыл. Зато потом с Git было всё просто и понятно.
_>Ну так правильно, heads то показывает не все существующие ветки в репозитории, а только некое подмножество — не слитые. А heads <branchname> показывает ещё более мелкое подмножество — помеченные определённым именем.
Во-во. Тут не ходи, тут рыбу заворачивали...
_>Так а может ты пояснишь, какой аналог анонимных веток у нас в git? ) Т.е. что делать при нескольких параллельных изменения относительно одной родительской ревизии, обязательно заводить отдельную именованную ветку? )
Да. Это чуть больше работы, но это небольшая цена за внятность концепции.
_>Ну давай объясни мне в какой момент произойдёт на практике это чудесная автоматическая перепаковка. Вот завёл я чистый репозиторий. Кинул в него несколько больших (для удобства теста) текстовых файлов — ничего нет. Добавил несколько ревизий — всё равно ничего нет (а размер хранилища уже за мегабайт вылезает, в то время как у mercurial намного меньше). Так когда же? )
`git help gc` рассказывает это. Мегабайт не тот размер, о котором считается осмысленным заботиться (хотя оно считает не по объёму, а по количеству объектов и паков).
С другой стороны, ряд источников говорит "выполняйте gc регулярно в на другой подходящий момент, например, при уходе на обеденный перерыв".
_>Ага, ага http://draketo.de/proj/hg-vs-git-server/test-results.html. Или это слишком сложно и детально? )
Это люди фатально не умеют рисовать графики — за такие рисунки отправлять в третий класс на пересдачу основ. Разбираться в однопиксельных пометках не стал, пошёл сразу к выводам. Пишут, что репо Git в среднем больше, если не начинается много веток, тогда оно меньше. Учитывая типичный стиль работы над действительно большим и серьёзным проектом, где обычно веток много (подготовки релизов, конкретные релизы, трейны апдейтов, параллельные трейны с перетеканием отлаженных фич), это важнее, чем на просто линейной истории.
_> Тогда рекомендую глянуть на такие http://stackoverflow.com/questions/6969385/why-is-my-git-repository-so-much-larger-than-mercurial-version вопросы, периодически возникающие на SO и т.п. местах.
А тут проскакивает, что преимущество Hg в сжатии диффов бинарников. Опять же сомнительное удовольствие (я в рамках благостных пожеланий "а хорошо бы такое увидеть", конечно, хочу, но в реальной жизни как-то не сталкивался — это что ж за бинарники такие, что между версиями можно получить компактный diff?)
_>Берём текстовый файл на мегабайт (чтобы ясно была разница, а то там всякие накладные расходы и т.п.). Кидаем в чистый репозиторий. Фиксируем ревизию. Меняем одну строчку в файле, снова фиксируем. Делаем пакет (bundle) из одной последней ревизии
Что такое bundle?
_>·>"хранилище mercurial занимает меньше места" — не согласен, т.к. надо рассматривать пакованный репо, ибо в реальности репы пакованные. _>Пакованным они будут до добавления новых ревизий, т.е. очень не долго. )
Они останутся до перепаковки. Новые ревизии добавят новые непакованные объекты, факт. Но старые трогать никто не будет, пока не придёт gc, repack или аналог.
_>Ну для начала с "много места" мы ещё и не разобрались. И кстати говоря у всех подходов есть свои недостатки. Даже если взять за основу идею с repack'ом, то помимо проблем с расписанием данной работы, данная техника к примеру блокирует возможность инкрементальных бэкапов хранилища.
Именно в виде пофайловой копии .git/ — да. Но смысл такого копирования возникает только на репо, которое не может бэкапиться через банальный pull с запретом форсирований операций. А такие, как правило, отражают какие-то спецвиды возни вроде состояний, которые регулярно проходят через upstream rebase — это, например, ветки фида новых коммитов на рассмотрение в корневые репо Linux kernel. Формально проблема есть, практически же её важность крошечна.
Здравствуйте, alex_public, Вы писали:
N>>Разница в том, что в Git при ветках, которые ветки, правила просты и логичны. В Hg разрыв между нормальным пониманием ветки и тем, что там называется этим словом, приводит к бардаку. Если переименуете на другой термин, который не конфликтует с языком, часть жалоб уйдёт. _>Ещё раз поясняю: в mercurial как раз самые нормальные ветки, просто ты не разобрался.
Что "не разобрался" — согласен в варианте "в этом проще запутаться, чем разобраться".
Что "самые нормальные" — ты этого не докажешь.
Skip дальше кусок — я понял, что у тебя в пределах ветки-1 (именованной базы роста) несколько веток-2 (просто направлений роста истории), которые ты потом сводишь, называя их своими идентификаторами. На самом деле в Git такое возможно, но если ты не дал имя такой голове, будешь знать только её id и её может удалить GC. Если ты гарантированно не допустишь GC, то можно так работать (rebase внутри себя так и делают). Только нафиг надо так корёжиться.
_>>> Кстати, аналогичного можно добиться и проще (как раз более практичный вариант) — фиксация своих изменений несколькими разработчиками в одну и ту же ветку, с последующей синхронизацией. N>>Пофиг, как ветка называется у каждого конкретного разработчика, важно, в какую в общем репо они вливают (и с какой мержатся). _>Зачем нам лишняя сущность типа третьего репозитория? )
Он может быть и вторым, и первым. Я нигде не утверждал, что общее репо может быть отдельным, это ты уже домыслил по непониманию.
_>Кстати, в режиме по умолчанию Mercurial синхронизирует сразу все ветки в репозиторию. Это так, к сведению. )
У Git такое умолчание _намеренно_ устранили в районе 2.2, теперь умолчание — одна ветка к одной ветке. Это так, к сведению
_>>>В Mercurial всё будет крайне удобно и это собственно один из нормальных сценариев работы. N>>В Git всё будет "крайне удобно", но после того, как ты наконец объяснишь, чего ты именно хочешь и зачем. _>Ну сейчас увидим как удобно будет. )
Удобства не увидел. Чтобы оно появилось, нужно, чтобы был смысл в параллельном развитии голов от одного разработчика и при этом переключаться между ними по идентификаторам, намеренно отказываясь от имён. Это уже религиозные заморочки, мне такое сложно понять.
_>>>Ужасы какие) Как раз для таких дел и создают отдельные ветки (отладочная, релизная и т.п.). N>>При чём тут вообще какие-то отдельные ветки? Описанные проблемы и методы решения не зависят от того, это develop, old stable или что-то ещё. _>Ну если тебе требуется наличие в репозитории двух версий одного кода, одну с отладочной печатью, а другую без, то это как раз удобнее делать через ветки. )
Вот даже в пределах этой темы можно уже собирать коллекцию того, какие интересные вещи ты домысливаешь за меня, не имея для этого никаких данных. Откуда вдруг идея про версии кода _в репозитории_? Отладочная печать вставлена только в рабочей копии. Если бы она была в репозитории (например, для отправки на CI и получения лога в условиях, близких к целевой машине), она была бы создана целевым коммитом (а затем выпилена revert'ом, или перенесено в общую ветку всё, кроме неё).
Здравствуйте, alex_public, Вы писали:
_>Хы, в 1997 самый громкий шум в мире линуха был неслышным шорохом на уровне остальной IT индустрии. )))
Менее массовые DVCS отрабатывались именно там, и концепции формировались именно там. И я не про 1997, а про 2000-2004.
В IT чаще всего так и получается — что-то возникшее в очень узкой нише вдруг получает развитие со всей его спецификой (вспомним x86 для PC).
_>Не, ветки из git'a, которые не сохраняются, а просто являются указателями на последние ревизии — они похожи на bookmarks. А как раз в самом Mercurial нормальные ветки. Просто ты не понял что сам сделал в системе и решил из этого какие-то выводы извлечь. )))
Я как раз всё понял. Что я простыми не специально извратными движениями породил "ветку", разорванную между ветками. И что первое, чему нужно учить пользователя Hg — это трём (минимум) смыслам слова "ветка" и как их не надо путать.
_>>>А вот тут http://rsdn.ru/forum/flame.comp/6335381.1
высказывается (и не мною) прямо противоположное мнение. ))) N>>Я не вижу там никакого противоречия тому, что я говорю. Разъясни подробнее, если видишь. _>Вроде как там ясно написано, что старым системам (cvs, svn и т.п.) ближе mercurial, а git наоборот отбросил все традиции и поэтому непривычен. Это полностью противоречит твой фразе о том, что к старым системам ближе git, а mercurial забил на традиции.
Ну, там сказано немного иначе. Но если ты делаешь такие выводы, то тут я с коллегой "·" не согласен; и я не принимаю никакого упрёка просто из того, что кто-то ещё говорит иначе. Если ты хотел припугнуть меня чужим мнением, то это просто смешно в своей наивности.
Здравствуйте, netch80, Вы писали:
_>>Здесь https://www.mercurial-scm.org/wiki/Branch всё подробно рассказано. N>"The term branch is sometimes used for slightly different concepts. This may be confusing for new users of Mercurial." Золотые слова. Вот пока оно будет использоваться, и не под "slightly" разные концепции, а под существенно разные, будет постоянный бардак между ветками, которые специализированные теги коммитов, ветками, которые пучки веток, ветки, которые ещё не слитые ветки (как в твоём ниже про heads) и так далее. N>Если этот бардак убрать и нормализовать терминологию, уровень проблем с Hg резко уменьшится, а пользователей таки добавится. Может, и я попробую его в работе хотя нет, для этого нужен ещё и аналог гитового index с полноценной поддержкой, и interactive rebase с его возможностями по расщеплению, слиянию и перестановке коммитов, модификации батчем. Вот после этого для меня они будут близки к эквивалентам.
Давай я сформулирую кратко всё что касается веток в Mercurial. И так, ветка в Mercurial — это последовательность ревизий связанных родительскими отношениями. Соответственно если в системе каким-то образом (есть разные варианты) появляется развилка (несколько ревизий с одной родительской ревизией), то это означает создание (автоматическое!) новой ветки. Это всё, что касается веток! Больше ничего в базовой архитектуре нет. И это настолько просто, что я не понимаю где тут можно в чём-то запутаться. И оно намного удобнее всяких git'ов, в которых без дополнительного набора команд работы с именованными ветками нельзя сделать ничего полезного.
Отдельно в Mercurial существует ещё несколько понятий, которые ты возможно путаешь:
1. Имена веток — это просто неизменяемый атрибут ревизий с особым свойством, он автоматически передаётся всем наследникам данной ревизии (если руками не указано иного).
2. Закладки — просто символические указатели (опциональные) на последнюю (автоматически перескакивают при фиксации) ревизию в ветках. По сути является аналогом веток в Git. Были введены не сразу (видимо как раз для удобства людей переходящих с Git).
3. Теги — символические указатели на произвольную ревизию. В отличие от закладок никуда не перескакивают и в отличие от имён веток не наследуются и могут изменяться.
Так вот нормальная работа с Mercurial вполне возможна (и вполне себе встречается) без всех этих трёх пунктов. Они существуют только для дополнительного удобства. Теперь понятно? )
_>>Почему-то пользователи git путают "branch name" (всего лишь атрибут ревизии) и реальные ветки (а вот их в упор не видят, хотя они и являются основным инструментом). И в результате получают глупости типа описанных в последнем предложение по моей ссылке. ))) N>Не "пользователи git", не надо натяжек, а все, кто не пришёл к этому "дети, это невозможно понять, но это надо запомнить". Я пытался разобраться с Hg, ещё не зная Git, запутался в этом бардаке, плюнул и забыл. Зато потом с Git было всё просто и понятно.
Не, это как раз пользователи Git привыкли к одной концепции и им приходится рассказывать что бывают другие варианты. Вот даже такие http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/ статейки выпускают (обрати внимание, что там везде объяснение через сравнение с git). Хотя на мой взгляд они только запутывают, потому как не соответствуют даже официальной документации. )))
_>>Так а может ты пояснишь, какой аналог анонимных веток у нас в git? ) Т.е. что делать при нескольких параллельных изменения относительно одной родительской ревизии, обязательно заводить отдельную именованную ветку? ) N>Да. Это чуть больше работы, но это небольшая цена за внятность концепции.
Это как раз в Git всё сложнее, т.к. требует обязательных команд по ручном созданию веток. Вместо очевидного понимания того факта, что любая родительская связь между двумя ревизиями автоматически является веткой. )
_>>Ну давай объясни мне в какой момент произойдёт на практике это чудесная автоматическая перепаковка. Вот завёл я чистый репозиторий. Кинул в него несколько больших (для удобства теста) текстовых файлов — ничего нет. Добавил несколько ревизий — всё равно ничего нет (а размер хранилища уже за мегабайт вылезает, в то время как у mercurial намного меньше). Так когда же? ) N>`git help gc` рассказывает это. Мегабайт не тот размер, о котором считается осмысленным заботиться (хотя оно считает не по объёму, а по количеству объектов и паков). N>С другой стороны, ряд источников говорит "выполняйте gc регулярно в на другой подходящий момент, например, при уходе на обеденный перерыв".
Ну в общем как я и говорил) Или мы делаем это руками или же преимущество в размере остаётся только в теории. )
_>>Ага, ага http://draketo.de/proj/hg-vs-git-server/test-results.html. Или это слишком сложно и детально? ) N>Это люди фатально не умеют рисовать графики — за такие рисунки отправлять в третий класс на пересдачу основ. Разбираться в однопиксельных пометках не стал, пошёл сразу к выводам. Пишут, что репо Git в среднем больше, если не начинается много веток, тогда оно меньше. Учитывая типичный стиль работы над действительно большим и серьёзным проектом, где обычно веток много (подготовки релизов, конкретные релизы, трейны апдейтов, параллельные трейны с перетеканием отлаженных фич), это важнее, чем на просто линейной истории.
Что-то ты какие-то странные выводы нашёл там. ) Я прочитал совсем другое. Люди там тестируют эти две системы в контексте организации сервера (на много пользователей). Т.е. для них и время работы и размер хранилища принципиальны. Соответственно в результатах у них показано, что git дико отжирает пространство на диске (собственно ради этого факта я и показал эту ссылку), а потом ещё и переодически загружает на время весь компьютер (если включено git gc --auto). В случае же настройки git gc через каждые несколько фиксаций с размером всё в порядке, но скорость работы получается существенно меньше Mercurial. Так что в итоге авторы тестирования рекомендуют использовать Mercurial.
Понятно, что для обычного (не серверного) применения это всё вообще не принципиально и обе системы подходят нормально. Однако в контексте нашей дискуссии о принципиальных преимуществах разных архитектурных подходов этот тест выявляет очень интересные результаты.
_>>Берём текстовый файл на мегабайт (чтобы ясно была разница, а то там всякие накладные расходы и т.п.). Кидаем в чистый репозиторий. Фиксируем ревизию. Меняем одну строчку в файле, снова фиксируем. Делаем пакет (bundle) из одной последней ревизии N>Что такое bundle?
git bundle create test1 -1 master
git bundle create test2 -2 master
_>>·>"хранилище mercurial занимает меньше места" — не согласен, т.к. надо рассматривать пакованный репо, ибо в реальности репы пакованные. _>>Пакованным они будут до добавления новых ревизий, т.е. очень не долго. ) N>Они останутся до перепаковки. Новые ревизии добавят новые непакованные объекты, факт. Но старые трогать никто не будет, пока не придёт gc, repack или аналог.
Достаточно поменять большую часть файлов проекта, чтобы хранилище снова дико выросло.
_>>Ну для начала с "много места" мы ещё и не разобрались. И кстати говоря у всех подходов есть свои недостатки. Даже если взять за основу идею с repack'ом, то помимо проблем с расписанием данной работы, данная техника к примеру блокирует возможность инкрементальных бэкапов хранилища. N>Именно в виде пофайловой копии .git/ — да. Но смысл такого копирования возникает только на репо, которое не может бэкапиться через банальный pull с запретом форсирований операций. А такие, как правило, отражают какие-то спецвиды возни вроде состояний, которые регулярно проходят через upstream rebase — это, например, ветки фида новых коммитов на рассмотрение в корневые репо Linux kernel. Формально проблема есть, практически же её важность крошечна.
Это ты говоришь про бэкап средствами самого git'а что ли?) Я имел в виду нормальный инкрементальный бэкап скажем всего диска или каталога с проектами соответствующими проф. инструментами.
Здравствуйте, netch80, Вы писали:
N>Skip дальше кусок — я понял, что у тебя в пределах ветки-1 (именованной базы роста) несколько веток-2 (просто направлений роста истории), которые ты потом сводишь, называя их своими идентификаторами. На самом деле в Git такое возможно, но если ты не дал имя такой голове, будешь знать только её id и её может удалить GC. Если ты гарантированно не допустишь GC, то можно так работать (rebase внутри себя так и делают). Только нафиг надо так корёжиться.
Ну так это только в git надо корёжится (не допускать gc, непонятным образом искать id и т.п.), а в mercurial это всё идеально удобно. Вот последовательность команд в Mercurial:
hg init
hg ci -A -m "init"
hg ci -m "change"
hg up 0
hg ci -m "alt change"
Создающая такой результат:
@ changeset: 2:c29317587b32
| tag: tip
| parent: 0:8fcdba93e475
| user: Alex
| date: Sat Feb 06 19:21:54 2016 +0300
| summary: alt change
|
| o changeset: 1:13d95e83fe25
|/ user: Alex
| date: Sat Feb 06 19:20:49 2016 +0300
| summary: change
|
o changeset: 0:8fcdba93e475
user: Alex
date: Sat Feb 06 19:19:45 2016 +0300
summary: init
Можно посмотреть для сравнения на набор команд git приводящий к аналогичному результату? )
И да, на это всё можно ещё сверху навесить и имена и закладки и теги, но зачем это всё в данном случае? )))
_>>Ну сейчас увидим как удобно будет. ) N>Удобства не увидел. Чтобы оно появилось, нужно, чтобы был смысл в параллельном развитии голов от одного разработчика и при этом переключаться между ними по идентификаторам, намеренно отказываясь от имён. Это уже религиозные заморочки, мне такое сложно понять.
Почему обязательно одного разработчика? )
Ну а насчёт удобства... Про принцип Оккама не забываем! )
Здравствуйте, netch80, Вы писали:
_>>Вроде как там ясно написано, что старым системам (cvs, svn и т.п.) ближе mercurial, а git наоборот отбросил все традиции и поэтому непривычен. Это полностью противоречит твой фразе о том, что к старым системам ближе git, а mercurial забил на традиции. N>Ну, там сказано немного иначе. Но если ты делаешь такие выводы, то тут я с коллегой "·" не согласен; и я не принимаю никакого упрёка просто из того, что кто-то ещё говорит иначе. Если ты хотел припугнуть меня чужим мнением, то это просто смешно в своей наивности.
Ну вообще то я просто надеялся что вы там между собой поспорите на эту тему и всё. ))) А так, по данному вопросу на самом деле вроде как общепринятое мнение, что система команд mercurial как раз ближе к классикe (типа cvs, svn). Что впрочем некоторые ставят как недостаток mercurial (типа ненужное наследие, в отличие от git). На мой взгляд это всё непринципиальные мелочи и если надо я легко могу пользоваться обеими системами без напряга. Но при свободе выбора очевидно выберу Mercurial из-за большего удобства.
Здравствуйте, alex_public, Вы писали:
_>Давай я сформулирую кратко всё что касается веток в Mercurial.
[...] _>Отдельно в Mercurial существует ещё несколько понятий, которые ты возможно путаешь: _>1. Имена веток — это просто неизменяемый атрибут ревизий с особым свойством, он автоматически передаётся всем наследникам данной ревизии (если руками не указано иного).
О. Вот тут твоя идеальная картина вдруг резко прекращается и начинается тысяча голодных дьяволов в мелочах. Начиная с того, что команда branch работает почему-то с вот этими "неизменяемыми атрибутами ревизий с особым свойством", что во всех найденных howto и объяснениях именно это называется веткой, что ты в начале дискуссии упорно доказывал, что именно это и есть ветки, а не то, что ты вдруг начал писать в этом постинге, и прочая, и прочая, и прочая.
И ни одно описание до сих пор это не описывало так, как ты сейчас описал. И то от тебя я этого добился только неоднократными упоминаниями разрыва между понятиями в стиле "ветка-1, ветка-2, ветка-3". И то — ты сейчас фактически ровно это же и описываешь.
_>2. Закладки — просто символические указатели (опциональные) на последнюю (автоматически перескакивают при фиксации) ревизию в ветках. По сути является аналогом веток в Git. Были введены не сразу (видимо как раз для удобства людей переходящих с Git).
Аналогом веток почти _везде_ кроме Hg. Начиная с того же CVS. Частично — и для SVN, если считать веткой базовый каталог и учитывать возможность прыжка между такими базами.
_>Так вот нормальная работа с Mercurial вполне возможна (и вполне себе встречается) без всех этих трёх пунктов. Они существуют только для дополнительного удобства. Теперь понятно? )
Понятно. В смысле, что в таком описании готов поверить — и даже счесть, что Hg нормально реализует ветки, при необходимом условии — для того, что у тебя под номером 1, будет введено другое название, соответственно обновлено всё начиная с имени команды и всех упоминаний в документации. Правда, это не единственное условие — надо ещё как минимум потестировать работу между разными репо. Тут уже посмотрим.
_>Не, это как раз пользователи Git привыкли к одной концепции и им приходится рассказывать что бывают другие варианты.
Я до Git работал с CVS и SVN. Нигде не было такого мозгоклюйства.
_>Вот даже такие http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/ статейки выпускают (обрати внимание, что там везде объяснение через сравнение с git). Хотя на мой взгляд они только запутывают, потому как не соответствуют даже официальной документации. )))
Вот именно. Во-первых, не соответствуют (тут верю тебе на слово). Во-вторых, авторы Hg явно зациклились на конкуренции с Git и не хотят смотреть в любом другом ключе. Хотя, если они ставят задачу забирать пользователей других систем, то им надо писать такие инструкции для SVN, CVS, VSS и тому подобного, а не Git, с которым соревноваться бессмысленно. А в данной инструкции как только читаешь "пролог" с "The default branch name in Mercurial is “default”.", сразу понятно, что этот автор только может ещё больше всё запутать.
_>Это как раз в Git всё сложнее, т.к. требует обязательных команд по ручном созданию веток.
Как раз то, что требуется обязательная команда, ничуть не говорит, что это сложнее. Необходимость явного действия — да. Сложнее — нет. Может быть, даже проще, потому что в Git ты уверен, что существуют головы DAG для того, что названо, и в нём нет ничего типа "забытая боковая ветка с данными, которые нельзя показывать другим, но которые тут таки прилепились".
К тому же, сам по себе сценарий типа "тут переехали назад по истории и начали рост от нового места" без внятной формулировки причины, зачем нужен этот самый рост, для меня выглядит банально нелепым. Если есть причина, надо её назвать хотя бы для себя и хотя бы для того, чтобы в истории не болталась забытая цепочка. А если она названа — она и будет названием ветки в общепринятом стиле.
_>Ну в общем как я и говорил) Или мы делаем это руками или же преимущество в размере остаётся только в теории. )
Я никогда не сталкивался с проблемами размера репо в Git. Возможно, это специфика каких-то особых условий. В любом случае, я не участвую тут в дискуссии по сравнению размеров и выборе на этой основе, я только сделал пару замечаний вскользь.
_>Понятно, что для обычного (не серверного) применения это всё вообще не принципиально и обе системы подходят нормально. Однако в контексте нашей дискуссии о принципиальных преимуществах разных архитектурных подходов этот тест выявляет очень интересные результаты.
А формат хранения истории вообще никак не относится к обсуждаемым нами ранее факторам — что такое ветка, где patch add, interactive rebase и тому подобное. Git приводится к варианту Hg в плане веток простейшим образом — хранить неназванные дополнительные головы. Я уже объяснил, почему считаю это не только бессмысленным, но и вредным. Но, если Git'овцы вдруг решат, что надо сменить методы упаковки для того, чтобы догнать Hg, это не повлияет не только на пользовательские средства верхнего уровня, но и на бо́льшую часть низкоуровневых средств (то, что в нём называется plumbing).
_>>>Берём текстовый файл на мегабайт (чтобы ясно была разница, а то там всякие накладные расходы и т.п.). Кидаем в чистый репозиторий. Фиксируем ревизию. Меняем одну строчку в файле, снова фиксируем. Делаем пакет (bundle) из одной последней ревизии N>>Что такое bundle?
_>git bundle create test1 -1 master _>git bundle create test2 -2 master
Ну, если ты знаешь, как провести эти тесты — покажи скрипты и результаты. Не думаю, что они покажут что-то принципиально важное (я лучше бы для сравнения взял результат перегонки чего-то открытого активно разрабатываемого), но просто покрасоваться цифрами — сгодится.
N>>Они останутся до перепаковки. Новые ревизии добавят новые непакованные объекты, факт. Но старые трогать никто не будет, пока не придёт gc, repack или аналог. _>Достаточно поменять большую часть файлов проекта, чтобы хранилище снова дико выросло.
Да. До упаковки.
_>Это ты говоришь про бэкап средствами самого git'а что ли?) Я имел в виду нормальный инкрементальный бэкап скажем всего диска или каталога с проектами соответствующими проф. инструментами.
При частых бэкапах перепаковка будет только на малой части от всех проектов, а при редкой изменение будет крупным для любой из обсуждаемых систем. Не думаю, что будет серьёзная разница.
Здравствуйте, ·, Вы писали:
_>>Здесь https://www.mercurial-scm.org/wiki/Branch всё подробно рассказано. Почему-то пользователи git путают "branch name" (всего лишь атрибут ревизии) и реальные ветки (а вот их в упор не видят, хотя они и являются основным инструментом). ·>Может я буквы читать разучился, но покажи в какой позиции в строке "you must first pull the head of that development line " находится слово "branch"? ·>В документации branch — это такой монстр, имя которого хранится в атрибуте, у которого есть множество heads. А ещё есть development line, related repositories. А ещё, оказывается, hg мержит не branches, а lines of development. ·>Столько ненужной и лишней терминологии просто из-за кривого дизайна системы.
Рекомендую читать с начала:
The term branch is sometimes used for slightly different concepts. This may be confusing for new users of Mercurial.
Branches occur if lines of development diverge. The term "branch" may thus refer to a "diverged line of development". For Mercurial, a "line of development" is a linear sequence of consecutive changesets.
_>>И в результате получают глупости типа описанных в последнем предложение по моей ссылке. ))) ·>Которой ссылке? Я правильно понял, ты имеешь в виду что в официальной документации hg написана глупость?
Нет, там корректно написано каким путём можно привести систему в глупое состояние. )
_>>А расскажи, чем по твоему неудобны глобальные имена веток? ) ·>Тем что это противоречит распределённости. Лишняя сущность, которая нужна далеко не всегда. Что плохого в том, если два разработчика создадут ветки "experiment", а потом захотят обменяться?
И в чём будет проблема с этим в Mercurial? )
_>>Про номера ревизий не понял в чём проблема, это всего лишь локальные хоткеи для удобства (если не хочешь, можешь вообще не обращать на них внимание) адресации. ·>Ещё одна ненужная нашлёпка сбоку, унаследованная от cvcs.
А людям удобно. ) Тем же кому не надо, ничем не мешает. Непонятно что плохого.
_>>Ну так правильно, heads то показывает не все существующие ветки в репозитории, а только некое подмножество — не слитые. А heads <branchname> показывает ещё более мелкое подмножество — помеченные определённым именем. ·>Объясни, каким словарём ты пользуешься, что словосочетание "branch heads" ты переводишь как "ветки"? Или в документаци, как всегда, глупость написана?
Ну естественно что branch heads — это не ветки, а соответствующие ревизии. Но т.к. их число будет в точности равно числу не слитых веток, то думаю что моя фраза была вполне понятна.
_>>Так а может ты пояснишь, какой аналог анонимных веток у нас в git? ) Т.е. что делать при нескольких параллельных изменения относительно одной родительской ревизии, обязательно заводить отдельную именованную ветку? ) ·>А если не обязательно параллельных? ·>В общем да, можно и ветку завести — ибо это ничего не стоит и никаких сложностей не создаёт. Это же не hg, где если заведёшь ветку, то это "навсегда". Собственно эта "фича" hg продиктована необходимостью — ветку завести не всегда возможно, вот и пришлось придумать новую сущность — головы.
Никакой сущности "головы" в mercurial нет. ))) А команда heads просто показывает список ревизий без потомков (соответственно это получается список конечных ревизий, по одной для каждой ветки).
·>Ещё можно просто по sha1 обращаться. Можно reflog полистать, можно в stash закинуть. Вариантов куча.
Ага, очень удобно. ) Да, и не забудь заблокировать git gc при этом. )))
_>>Ну давай объясни мне в какой момент произойдёт на практике это чудесная автоматическая перепаковка. Вот завёл я чистый репозиторий. Кинул в него несколько больших (для удобства теста) текстовых файлов — ничего нет. Добавил несколько ревизий — всё равно ничего нет (а размер хранилища уже за мегабайт вылезает, в то время как у mercurial намного меньше). Так когда же? ) ·>Если хочешь разобраться досконально, читай хелп на "git gc", флажок --auto. Там точно указаны правила. Используются несколько имперически подобранных параметров, чтобы в более менее стандартных ситуациях давать хороший результат, если что — можно подкрутить для особых случаев. Вроде очевидно, что "несколько мегабайт" это не то, о чём стоит волноваться.
Я согласен, что для обычного пользователя это всё не принципиально. Но мы то рассуждаем об архитектурных принципах. И пока что выходит что на практике (а не в теории, где все тесты производятся после repack) подход mercurial лучше.
_>>Ага, ага http://draketo.de/proj/hg-vs-git-server/test-results.html. Или это слишком сложно и детально? ) ·>Графики каие-то нечитабельные. И я не понял — а что именно там коммитилось-то? Что-то какие-то случайные модификации каких-то случайных данных...
написал про эту ссылку. Если же кратко, то главное для нашей дискуссии там показано, что в обычном режиме (не с настройкой git-gc через каждый несколько фиксаций) хранилище git начинает отжирать неадекватно много места.
·>Так новые ревизии не заставляют репозиторий распаковываться. То что запаковалось — так и остаётся запакованным.
А я этого и не утверждал. Я говорил что размер снова вырастет через несколько новых ревизий. )
_>>Берём текстовый файл на мегабайт (чтобы ясно была разница, а то там всякие накладные расходы и т.п.). Кидаем в чистый репозиторий. Фиксируем ревизию. Меняем одну строчку в файле, снова фиксируем. Делаем пакет (bundle) из одной последней ревизии и смотрим размер файла (число1, должно быть очень маленькое), делаем пакет из двух последних ревизий (по сути будет весь репозиторий) и смотрим размер файла (число2, должно быть большое). Выполняем эту последовательность и для mercurial и для git, а потом сравниваем в начале две версии числа1, а потом две версии числа 2. ·>
·>kan@altegol:~/tmp/experiment/bundle/git$ ls -l
·>total 1424
·>-rw-rw-r-- 1 kan kan 228253 Feb 6 13:25 1.bundle
·>-rw-rw-r-- 1 kan kan 419 Feb 6 13:26 2.bundle
·>-rw-rw-r-- 1 kan kan 1198368 Feb 6 13:18 file
·>kan@altegol:~/tmp/experiment/bundle/hg$ ls -l
·>total 1356
·>-rw-rw-r-- 1 kan kan 157286 Feb 6 13:41 1.bundle
·>-rw-rw-r-- 1 kan kan 399 Feb 6 13:42 2.bundle
·>-rw-rw-r-- 1 kan kan 1198368 Feb 6 13:39 file
·>
·>Разница есть, конечно, но не принципиальна... Вообще не понимаю причём тут бандлы, они от структуры репозитория не зависят.
Потому что они идеально характеризуют тот объём данных, который необходимо переслать по сети для соответствующей синхронизации репозиториев. Можно конечно и честно по сети замерять, но это намного сложнее. Ну а соответственно размер этих файлов даёт представление о качестве алгоритмов эти двух систем... )
_>>Ну для начала с "много места" мы ещё и не разобрались. И кстати говоря у всех подходов есть свои недостатки. Даже если взять за основу идею с repack'ом, то помимо проблем с расписанием данной работы, данная техника к примеру блокирует возможность инкрементальных бэкапов хранилища. ·>Не блокирует. Просто иногда после repack придётся новые паки бэкапить, старые удалять, вот и всё. А вообще не проще ли --mirror использовать или тупо rsync?
Ну о пользе и недостатках инкрементального бэкапа можно отдельно говорить. Но факт в том, что операция repack в git сильно вредит данной технике.
Здравствуйте, alex_public, Вы писали:
_>Ну так это только в git надо корёжится (не допускать gc, непонятным образом искать id и т.п.), а в mercurial это всё идеально удобно.
Если хочешь дальше общаться, прекращай это НЛП в виде регулярной мантры "идеально удобно", или я просто прекращу обсуждение и буду считать тебе техническое поражение. Надоело. Или мы говорим проверяемыми аргументами без вкусовщины (во что входит соответствие общепринятым терминам и распространённым практикам), или мне такое не подходит.
_> Вот последовательность команд в Mercurial:
Тему веток я прокомментировал ровно один свой комментарий назад в этой ветке.
_>И да, на это всё можно ещё сверху навесить и имена и закладки и теги, но зачем это всё в данном случае? )))
Там же был и ответ, зачем.
_>>>Ну сейчас увидим как удобно будет. ) N>>Удобства не увидел. Чтобы оно появилось, нужно, чтобы был смысл в параллельном развитии голов от одного разработчика и при этом переключаться между ними по идентификаторам, намеренно отказываясь от имён. Это уже религиозные заморочки, мне такое сложно понять. _>Почему обязательно одного разработчика? )
Ну ok. От нескольких. И опять же всё без имён, только по идентификаторам коммитов. А потом за них же цепляться и сводить воедино.
_>Ну а насчёт удобства... Про принцип Оккама не забываем! )
И что он тут даёт в твою пользу? В мою вижу — появилась излишняя сущность "безымянные цепочки" с диверсионными последствиями.
Здравствуйте, alex_public, Вы писали:
a> 1. Имена веток — это просто неизменяемый атрибут ревизий с особым свойством, он автоматически передаётся всем наследникам данной ревизии (если руками не указано иного).
А чем это полезно? На пальцах.
Ну и чтобы 2 раза не вставать: если я когда-то создал ветку с именем branch1, то я больше никогда не смогу создать другую ветку с таким же именем? И более того имена глобальны для всех репо?
Здравствуйте, netch80, Вы писали:
_>>Отдельно в Mercurial существует ещё несколько понятий, которые ты возможно путаешь: _>>1. Имена веток — это просто неизменяемый атрибут ревизий с особым свойством, он автоматически передаётся всем наследникам данной ревизии (если руками не указано иного). N>О. Вот тут твоя идеальная картина вдруг резко прекращается и начинается тысяча голодных дьяволов в мелочах. Начиная с того, что команда branch работает почему-то с вот этими "неизменяемыми атрибутами ревизий с особым свойством", что во всех найденных howto и объяснениях именно это называется веткой, что ты в начале дискуссии упорно доказывал, что именно это и есть ветки, а не то, что ты вдруг начал писать в этом постинге, и прочая, и прочая, и прочая.
Так где оно называется то так? Скажем при описание какой-нибудь команды с возможным параметром в виде этого самого атрибута (введённого специально для идентификации неанонимных веток). Ты думаешь кто-то будет писать "передаём команде специальный атрибут branch1, идентифицирующий нашу ветку"? Естественно все пишут "передаём команде ветку branch1".
_>>2. Закладки — просто символические указатели (опциональные) на последнюю (автоматически перескакивают при фиксации) ревизию в ветках. По сути является аналогом веток в Git. Были введены не сразу (видимо как раз для удобства людей переходящих с Git). N>Аналогом веток почти _везде_ кроме Hg. Начиная с того же CVS. Частично — и для SVN, если считать веткой базовый каталог и учитывать возможность прыжка между такими базами.
Неизменность истории мне нравится больше)
_>>Вот даже такие http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/ статейки выпускают (обрати внимание, что там везде объяснение через сравнение с git). Хотя на мой взгляд они только запутывают, потому как не соответствуют даже официальной документации. ))) N>Вот именно. Во-первых, не соответствуют (тут верю тебе на слово). Во-вторых, авторы Hg явно зациклились на конкуренции с Git и не хотят смотреть в любом другом ключе. Хотя, если они ставят задачу забирать пользователей других систем, то им надо писать такие инструкции для SVN, CVS, VSS и тому подобного, а не Git, с которым соревноваться бессмысленно. А в данной инструкции как только читаешь "пролог" с "The default branch name in Mercurial is “default”.", сразу понятно, что этот автор только может ещё больше всё запутать.
Ну вообще то раньше (до популярности гитхаба) со старых систем как раз чаще переходили на Mercurial в силу более привычной системы команд. Сейчас же из-за распиаренности гитхаба чаще переходят на git и страдают потом с ним. ) Ну это естественно если руками в консоли работают. При классической работе через плагин в IDE разницы между этими двумя DVCS почти не будет.
N>К тому же, сам по себе сценарий типа "тут переехали назад по истории и начали рост от нового места" без внятной формулировки причины, зачем нужен этот самый рост, для меня выглядит банально нелепым. Если есть причина, надо её назвать хотя бы для себя и хотя бы для того, чтобы в истории не болталась забытая цепочка. А если она названа — она и будет названием ветки в общепринятом стиле.
А если причиной развилки будет всего лишь синхронизация изменений с двух разных машин? )
_>>>>Берём текстовый файл на мегабайт (чтобы ясно была разница, а то там всякие накладные расходы и т.п.). Кидаем в чистый репозиторий. Фиксируем ревизию. Меняем одну строчку в файле, снова фиксируем. Делаем пакет (bundle) из одной последней ревизии N>>>Что такое bundle? _>>git bundle create test1 -1 master _>>git bundle create test2 -2 master N>Ну, если ты знаешь, как провести эти тесты — покажи скрипты и результаты. Не думаю, что они покажут что-то принципиально важное (я лучше бы для сравнения взял результат перегонки чего-то открытого активно разрабатываемого), но просто покрасоваться цифрами — сгодится.
Ну тут уже кидали результаты. У меня в принципе похожие — у Mercurial раза в 1,5 меньше получаются пакеты изменений. ) Т.е. где-то так же и сеть загружается при синхронизации.
Здравствуйте, netch80, Вы писали:
_>>Ну так это только в git надо корёжится (не допускать gc, непонятным образом искать id и т.п.), а в mercurial это всё идеально удобно. N>Если хочешь дальше общаться, прекращай это НЛП в виде регулярной мантры "идеально удобно", или я просто прекращу обсуждение и буду считать тебе техническое поражение. Надоело. Или мы говорим проверяемыми аргументами без вкусовщины (во что входит соответствие общепринятым терминам и распространённым практикам), или мне такое не подходит.
Вообще то как раз только что я и сделал попытку количественного анализа данного субъективного вопроса — предложил сравнить необходимые команды в разных системах для реализации одной и той же задачи. Однако ты её проигнорировал, без внятного объяснения.
_>> Вот последовательность команд в Mercurial: N>Тему веток я прокомментировал ровно один свой комментарий назад в этой ветке.
Я понял твои мысли там. Но непонятно какое они имеют отношение к вопросу сравнения числа команд для решения конкретной задачки. У тебя какие-то претензии к такому подходу? )
N>>>Удобства не увидел. Чтобы оно появилось, нужно, чтобы был смысл в параллельном развитии голов от одного разработчика и при этом переключаться между ними по идентификаторам, намеренно отказываясь от имён. Это уже религиозные заморочки, мне такое сложно понять. _>>Почему обязательно одного разработчика? ) N>Ну ok. От нескольких. И опять же всё без имён, только по идентификаторам коммитов. А потом за них же цепляться и сводить воедино.
Ну лично я делаю это правым кликом по соответствующей ревизии в визуальном дереве и выбором пункта "слить с локальной копией". ))) Однако и из консоли это всё делается тривиально, как раз благодаря командам типа heads.
_>>Ну а насчёт удобства... Про принцип Оккама не забываем! ) N>И что он тут даёт в твою пользу? В мою вижу — появилась излишняя сущность "безымянные цепочки" с диверсионными последствиями.
Как раз придумывание имени ветки, которая существует например только ради синхронизации — это и есть очевидно лишнее.
Здравствуйте, Dziman, Вы писали:
a>> 1. Имена веток — это просто неизменяемый атрибут ревизий с особым свойством, он автоматически передаётся всем наследникам данной ревизии (если руками не указано иного). D>А чем это полезно? На пальцах.
Ну то что это неизменяемый атрибут (а не указатель, как bookmark, или изменяемый tag), даёт нам возможность гарантированного сохранения всей истории, в отличие от того же git'a. Вот тут https://habrahabr.ru/post/123700/ можно глянуть картинки, демонстрирующие эту разницу на примере.
Ну а возможность наследования значения в сочетание с автоматическим ветвлением даёт возможность легко делать такие расклады:
| |
o 5 |
|\ |
| \ |
| \|
| o 4
| /\
| / \
| o 2 o 3
| \ /
| \/
| o 1
| |
relese develop
в которой ревизии 1, 2, 3, 4 носят имя ветки develop, а ревизия 5 имя ветки release..
D>Ну и чтобы 2 раза не вставать: если я когда-то создал ветку с именем branch1, то я больше никогда не смогу создать другую ветку с таким же именем? И более того имена глобальны для всех репо?
Реальная ветка создаётся не командой branch, а соответствующей командой commit. ) И да, имена глобальные. )
Здравствуйте, alex_public, Вы писали:
_>в которой ревизии 1, 2, 3, 4 носят имя ветки develop, а ревизия 5 имя ветки release..
Собственно в этом от git и отличается. Понятие "ветка" в hg не имеет никакого отношения к структуре истории, как в других vcs, а просто некая метка, наляпываемая на каждую ревизию.
Какое знание несёт информация, что ревизия 2 была создана именно в ветке develop, если эта же ревизия существует и в release?
Этого же эффекта можно добиться помещая имя текущей ветки в коммент коммита (можно хук сделать). Но зачем из буханки делать троллейбус?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
·>т.е. простая линейная история, никакой diverged line нет, но ветка release чуть старее чем development. Сколько тут веток? И как это следует из приведённой тобой цитаты?
Как это нет? ) А разве release и development не ответвляются от некой неназванной ветки?) Или я неправильно понял картинку (вообще непривычно читать историю слева направо)? Если правильно, то тогда имеем 3 ветки.
·>Или вот такая история ·>
·>Вроде это не linear sequence, сколько тут веток?
А тут одна ветка отделяется от другой (в которой было разветвление)? И что? )
_>>Нет, там корректно написано каким путём можно привести систему в глупое состояние. ) ·>Ничего не понял. Давай конкретно. Приведи цитату, что такое глупое состояние системы и бывают ли в hg какие-то другие состояния?
Глупое состояние было в репозитории с которым игрался netch80. А в данном куске документации подробно объяснялось как он его добился.
_>>И в чём будет проблема с этим в Mercurial? ) ·>Да, интересно как. У меня есть репо, у тебя есть репо. Мы оба делали какие-то свои эксперименты, у нас обоих есть ветки с именем "experiment", но совершенно разные по содержимому. Как мне взять твой experiment в свой репозиторий, чтобы не смешивать с моим experiment? В git можно например так: ·>git fetch <your_repo_url> experiment:alex_public_experiment
У тебя будет просто две ветки с именем experiment после синхронизации. )
_>>Ну естественно что branch heads — это не ветки, а соответствующие ревизии. Но т.к. их число будет в точности равно числу не слитых веток, то думаю что моя фраза была вполне понятна. ·>Не будет. Пусть у тебя есть две ветки-в-официальном-понимании b1 и b2, каждая из них будет иметь по две головы. Количество веток-в-официальном-понимании будет всё равно две, а веток-alex_public-вида будет четыре. Команда "hg heads b1" выведет две головы. ·>Твоя фраза не понятна, ибо ты не используешься терминологией, принятой в документации hg.
Судя по твоему следующему сообщению ты уже сам всё понял, но всё же отвечу: будет 4 ветки, каждая пара из которых будет с одним именем. И команда heads покажет все 4. )
_>>Никакой сущности "головы" в mercurial нет. ))) А команда heads просто показывает список ревизий без потомков (соответственно это получается список конечных ревизий, по одной для каждой ветки). ·>А о чём рассказывает статья https://www.mercurial-scm.org/wiki/Head ? Статья говорит, что голова — это ревизия без потомков. А ещё я забыл что есть понятие tip. А ещё этот зоопарк понятий: ·>... ·>Жуууть!
Ну а я что сказал? ) Список ревизий без потомков. ) А tip — это всего лишь автоматический Tag, опять же для удобства. )
_>>Я согласен, что для обычного пользователя это всё не принципиально. Но мы то рассуждаем об архитектурных принципах. И пока что выходит что на практике (а не в теории, где все тесты производятся после repack) подход mercurial лучше. ·>Ты не понял что-ли ещё? На практике repack происходит сам. На практике непакованный репозиторий найти — проблема.
К тому моменты, когда он происходит (при дефолтных настройках) размер репозитория уходит далеко в небеса. Именно об этом и говорило то тестирование по моей ссылке (с графиками и т.п.). Они пытались исправить это настройкой вида "делать git-gc через каждые несколько фиксаций". Тогда всё было нормально с размером, но скорость резко проседала даже по сравнению с Mercurial.
_>>Потому что они идеально характеризуют тот объём данных, который необходимо переслать по сети для соответствующей синхронизации репозиториев. Можно конечно и честно по сети замерять, но это намного сложнее. Ну а соответственно размер этих файлов даёт представление о качестве алгоритмов эти двух систем... ) ·>И что? 399 и 419 байт — и какие выводы из этой разницы ты сделаешь? Что неожиданного оказалось в этих цифрах для тебя?
При мелком апдейте основной размер идёт на накладные расходы. Я как раз потому и сказал большой файл засунуть, чтобы было видно. )
·>Ещё раз — то что передаётся по сети никак не зависит от формата хранилища.
Зато зависит от архитектуры системы.
_>>Ну о пользе и недостатках инкрементального бэкапа можно отдельно говорить. Но факт в том, что операция repack в git сильно вредит данной технике. ·>А вообще любопытно... Зачем вообще в dvcs нужен инкрементальный бэкап? ·>Но если так надо, то проще git bundle для этого использовать. ·>А вот инкрементально бэкапить (особенно hot repo) файлы hg я бы не стал... Вообще — погугли. Принципы бэкапов hg и git ничем не отличаются.
Здравствуйте, ·, Вы писали:
·>Этого же эффекта можно добиться помещая имя текущей ветки в коммент коммита (можно хук сделать). Но зачем из буханки делать троллейбус?
Можно и так))) Но тогда с этим не смогут работать различные команды (типа heads, pull/push и т.п.).
_>·>т.е. простая линейная история, никакой diverged line нет, но ветка release чуть старее чем development. Сколько тут веток? И как это следует из приведённой тобой цитаты? _>Как это нет? ) А разве release и development не ответвляются от некой неназванной ветки?) Или я неправильно понял картинку (вообще непривычно читать историю слева направо)? Если правильно, то тогда имеем 3 ветки.
Нет, не ответвляются. Точнее, если переводить дословно "diverged" — не расходятся. Тривиальная линейная история. Звёздочки это ревизии. А линии — ну просто линии, чтобы было понятно что куда относится. Т.е. этот рисунок отображает тот факт, что release был сделан 4 ревизии назад от development. Или, иначе говоря, с тех пор как мы зарелизились, было надевелопено ещё четыре новые ревизии. Это самый простой рисунок для этой ситуации, именно он такой и будет в git. В hg он будет сложнее, с лишними наворотами.
_>·>Или вот такая история _>·>
_>·>Вроде это не linear sequence, сколько тут веток? _>А тут одна ветка отделяется от другой (в которой было разветвление)? И что? )
Это не linear sequence, как это согласуется приведённой тобой цитате?
_>>>Нет, там корректно написано каким путём можно привести систему в глупое состояние. ) _>·>Ничего не понял. Давай конкретно. Приведи цитату, что такое глупое состояние системы и бывают ли в hg какие-то другие состояния? _>Глупое состояние было в репозитории с которым игрался netch80. А в данном куске документации подробно объяснялось как он его добился.
А толком можно объяснить? Где игрался, как игрался, почему глупое? Как ещё можно играться? Если у тебя есть какая-то мысль, сформулируй её чётко.
_>·>Да, интересно как. У меня есть репо, у тебя есть репо. Мы оба делали какие-то свои эксперименты, у нас обоих есть ветки с именем "experiment", но совершенно разные по содержимому. Как мне взять твой experiment в свой репозиторий, чтобы не смешивать с моим experiment? В git можно например так: _>·>git fetch <your_repo_url> experiment:alex_public_experiment _>У тебя будет просто две ветки с именем experiment после синхронизации. )
Нет, rtfm. В моём репо будет моя ветка "experiment", и твоя "alex_public_experiment".
А в hg что будет?
_>·>Не будет. Пусть у тебя есть две ветки-в-официальном-понимании b1 и b2, каждая из них будет иметь по две головы. Количество веток-в-официальном-понимании будет всё равно две, а веток-alex_public-вида будет четыре. Команда "hg heads b1" выведет две головы. _>·>Твоя фраза не понятна, ибо ты не используешься терминологией, принятой в документации hg. _>Судя по твоему следующему сообщению ты уже сам всё понял, но всё же отвечу: будет 4 ветки, каждая пара из которых будет с одним именем. И команда heads покажет все 4. )
Если ты читал документацию, тебя не должно затруднить привести цитату, что ветки-alex_public-вида называются именно словом "ветка". Я читал документацию, это называется не ветки, а головы.
_>·>А о чём рассказывает статья https://www.mercurial-scm.org/wiki/Head ? Статья говорит, что голова — это ревизия без потомков. А ещё я забыл что есть понятие tip. А ещё этот зоопарк понятий: _>·>... _>·>Жуууть! _>Ну а я что сказал? ) Список ревизий без потомков. )
Ты говорил: «Никакой сущности "головы" в mercurial нет». В оф.документации есть, однако. Даже команда есть такая. Я не понимаю зачем ты вводишь в заблуждение.
_> А tip — это всего лишь автоматический Tag, опять же для удобства. )
tag вообще-то неизменяемая сущность во всех других мне известных vcs. Так что и таги в hg оказывается какие-то особенные.
А tip значит не просто некий таг как и все, а особенный, "автоматический", ещё одна сущность. Бардак.
_>·>Ты не понял что-ли ещё? На практике repack происходит сам. На практике непакованный репозиторий найти — проблема. _>К тому моменты, когда он происходит (при дефолтных настройках) размер репозитория уходит далеко в небеса. Именно об этом и говорило то тестирование по моей ссылке (с графиками и т.п.). Они пытались исправить это настройкой вида "делать git-gc через каждые несколько фиксаций". Тогда всё было нормально с размером, но скорость резко проседала даже по сравнению с Mercurial.
Не знаю, странная ссылка была. Я мало что понял что и как тестировалось, да ещё и 5 лет назад. Хочется более-менее реальные тесты увидеть. Гигахостинги типа github говорят о том, что это значительной проблемой не является.
И вообще, если просто почитать выводы: "If you need the fastest system and don’t mind occassional performance glitches and volatile repository sizes, git is the way to go", ибо я, как юзер, предпочитаю работать с быстрой системой. "If you need reliable performance and space requirements, Mercurial is the better choice" — это проблема серверов и железа, которое сейчас дешевое.
_>>>Потому что они идеально характеризуют тот объём данных, который необходимо переслать по сети для соответствующей синхронизации репозиториев. Можно конечно и честно по сети замерять, но это намного сложнее. Ну а соответственно размер этих файлов даёт представление о качестве алгоритмов эти двух систем... ) _>·>И что? 399 и 419 байт — и какие выводы из этой разницы ты сделаешь? Что неожиданного оказалось в этих цифрах для тебя? _>При мелком апдейте основной размер идёт на накладные расходы. Я как раз потому и сказал большой файл засунуть, чтобы было видно. )
Так я засунул ~1мб текстовый файл. Изменение я делал добавлением новой строчки в конец "echo boo >> file", как ты и просил в описании эксперимента.
_>·>Ещё раз — то что передаётся по сети никак не зависит от формата хранилища. _>Зато зависит от архитектуры системы.
Каким образом? К чему эта тупая упёртость? Я ж привёл тебе результат эксперимента — 399 и 419 байт. Проведи эксперимент сам, если не веришь.
_>>>Ну о пользе и недостатках инкрементального бэкапа можно отдельно говорить. Но факт в том, что операция repack в git сильно вредит данной технике. _>·>А вообще любопытно... Зачем вообще в dvcs нужен инкрементальный бэкап? _>·>Но если так надо, то проще git bundle для этого использовать. _>·>А вот инкрементально бэкапить (особенно hot repo) файлы hg я бы не стал... Вообще — погугли. Принципы бэкапов hg и git ничем не отличаются. _>Речь про бэкап сервера, а не про работу с git. )
Что за "бэкап сервера"? И чем он будет принципиально отличаться в случае git и hg?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, alex_public, Вы писали:
_>·>Этого же эффекта можно добиться помещая имя текущей ветки в коммент коммита (можно хук сделать). Но зачем из буханки делать троллейбус? _>Можно и так))) Но тогда с этим не смогут работать различные команды (типа heads, pull/push и т.п.).
Команда heads, конечно работать не будет, ибо такой команды в git нет, так как этого бреда с многоголовыми ветками нет. Неслитые ветки в git можно посмотреть, как ни странно, командой branch с ключиком "--no-merged".
А с push/pull что случится-то?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Нет, не ответвляются. Точнее, если переводить дословно "diverged" — не расходятся. Тривиальная линейная история. Звёздочки это ревизии. А линии — ну просто линии, чтобы было понятно что куда относится. Т.е. этот рисунок отображает тот факт, что release был сделан 4 ревизии назад от development. Или, иначе говоря, с тех пор как мы зарелизились, было надевелопено ещё четыре новые ревизии. Это самый простой рисунок для этой ситуации, именно он такой и будет в git. В hg он будет сложнее, с лишними наворотами.
А, всё, я понял что ты нарисовал. Правда не знаю зачем применять для такого именованные ветки (когда нет реальных разветвлений), но если очень хочется, то в mercurial можно без проблем и оно прямо так и будет выглядеть. ) И даже меньше команд чем в git понадобится. )))
_>>·>Вроде это не linear sequence, сколько тут веток? _>>А тут одна ветка отделяется от другой (в которой было разветвление)? И что? ) ·>Это не linear sequence, как это согласуется приведённой тобой цитате?
Я просто не понял твой формат рисования) Теперь понял)
Но кстати вопрос "сколько веток" некорректен для некого отрезка истории, т.к. на его протяжение это число может меняться. Например тут в начале одна ветка, потом она разветвляется на две, а потом снова сливается в одну. Данный вопрос корректен только для фиксированного момента времени.
_>>Глупое состояние было в репозитории с которым игрался netch80. А в данном куске документации подробно объяснялось как он его добился. ·>А толком можно объяснить? Где игрался, как игрался, почему глупое? Как ещё можно играться? Если у тебя есть какая-то мысль, сформулируй её чётко.
Это всё было в сообщениях выше) Он спрашивал каким образом получилась некая ересь, так вот данная фраза из документации была объяснением. )
_>>У тебя будет просто две ветки с именем experiment после синхронизации. ) ·>Нет, rtfm. В моём репо будет моя ветка "experiment", и твоя "alex_public_experiment". ·>А в hg что будет?
Я вообще то про Mercurial и говорил. )))
_>>Судя по твоему следующему сообщению ты уже сам всё понял, но всё же отвечу: будет 4 ветки, каждая пара из которых будет с одним именем. И команда heads покажет все 4. ) ·>Если ты читал документацию, тебя не должно затруднить привести цитату, что ветки-alex_public-вида называются именно словом "ветка". Я читал документацию, это называется не ветки, а головы.
Голова — это одна ревизия, не путай с ветками (они состоят из набора ревизий). ) Ну а что касается цитаты... Я тебе уже в который раз говорю прочитать внимательно эту https://www.mercurial-scm.org/wiki/Branch ссылку. Там же всего лишь пара страниц, а ты уже в который раз не можешь осилить. ))) Например:
Strictly speaking, a branch is created when a user creates a new changeset C2 in a repository R0, if its parent changeset P already has a child C1, thus adding a second child changeset C2 to that parent P. This adds a new head to R0.
или
As such, each changeset in Mercurial forms an element of a branch. A changeset thus can be said to "belong to a branch". Per that definition, a branch is simply a linear sequence of changesets.
Ещё требуются пояснения? ) Думаю вполне видно, что никаких намёков на именованные ветки тут нет.
_>>Ну а я что сказал? ) Список ревизий без потомков. ) ·>Ты говорил: «Никакой сущности "головы" в mercurial нет». В оф.документации есть, однако. Даже команда есть такая. Я не понимаю зачем ты вводишь в заблуждение.
Это не отдельная сущность, а просто название ревизии без потомков. Т.е. этот "термин" можно спокойно и в git применять. )))
_>> А tip — это всего лишь автоматический Tag, опять же для удобства. ) ·>tag вообще-то неизменяемая сущность во всех других мне известных vcs. Так что и таги в hg оказывается какие-то особенные. ·>А tip значит не просто некий таг как и все, а особенный, "автоматический", ещё одна сущность. Бардак.
Кошмар, кошмар. ))) Нельзя ничего добавлять в систему для удобства пользоваться. Пускай он лучше побольше сам работает, не развалится, да? )))
·>Не знаю, странная ссылка была. Я мало что понял что и как тестировалось, да ещё и 5 лет назад. Хочется более-менее реальные тесты увидеть. Гигахостинги типа github говорят о том, что это значительной проблемой не является. ·>И вообще, если просто почитать выводы: "If you need the fastest system and don’t mind occassional performance glitches and volatile repository sizes, git is the way to go", ибо я, как юзер, предпочитаю работать с быстрой системой. "If you need reliable performance and space requirements, Mercurial is the better choice" — это проблема серверов и железа, которое сейчас дешевое.
Ну так я же это тестирование привёл не в качестве аргумента за использование одной или другой системы (в этом смысле я уже давно сказал, что подобные вопросы у них одинаково удовлетворительно для пользователя решены и есть смысл выбирать только по вкусу удобства работы с системой команд), а в контексте нашего обсуждения преимуществ разных архитектур. Это не я начал первым утверждать, что у Git архитектура более совершенная. Я лишь указал, что на практике эта вроде как совершенная архитектура проигрывает. )))
_>>При мелком апдейте основной размер идёт на накладные расходы. Я как раз потому и сказал большой файл засунуть, чтобы было видно. ) ·>Так я засунул ~1мб текстовый файл. Изменение я делал добавлением новой строчки в конец "echo boo >> file", как ты и просил в описании эксперимента.
Так я и говорю, что смысл имеет сравнение только цифр для пакета с двумя ревизиями (т.к. там мегабайтный файл), а в пакете с одной ревизией большую часть места занимают накладные расходы на формат пакета. Поэтому там и разницы особой нет. А вот при наличие большого объёма данных сразу видна разница в 1,5 раза.
_>>Зато зависит от архитектуры системы. ·>Каким образом? К чему эта тупая упёртость? Я ж привёл тебе результат эксперимента — 399 и 419 байт. Проведи эксперимент сам, если не веришь.
У тебя всё верно, но я говорю об измерение пакетов с двумя ревизиями. ) И от чего по твоему оно зависит, если нет архитектуры системы? )
_>>Речь про бэкап сервера, а не про работу с git. ) ·>Что за "бэкап сервера"? И чем он будет принципиально отличаться в случае git и hg?
Эмм, тебе не знакомо понятие бэкапа сервера? Не важно инкрементального или нет...
Отличие у git и hg будет в том, что в случае инкрементального бэкапа хранилище git'a после repack'а придётся копировать всё заново (хотя там может добавилась всего пара ревизий), а в случае hg будет скопировано только реальное изменение (новые ревизии). В случае большой истории в репозитории это может быть очень существенная разница.
Здравствуйте, ·, Вы писали:
_>>·>Этого же эффекта можно добиться помещая имя текущей ветки в коммент коммита (можно хук сделать). Но зачем из буханки делать троллейбус? _>>Можно и так))) Но тогда с этим не смогут работать различные команды (типа heads, pull/push и т.п.). ·>Команда heads, конечно работать не будет, ибо такой команды в git нет, так как этого бреда с многоголовыми ветками нет. Неслитые ветки в git можно посмотреть, как ни странно, командой branch с ключиком "--no-merged". ·>А с push/pull что случится-то?
А причём тут git? ) Я отвечал на твой как бы юмор, что можно было бы сделать реализацию имён веток в Mercurial через добавления этого имени в комментарий ревизии через хук. Так вот я и ответил, что да, теоретически это было бы похоже, но тогда перестали бы работать возможности многих команд Mercurial, умеющих принимать имя ветки в качестве параметра.
Что касается git'a, то его вообще смешно обсуждать в данном контексте, т.к. он банально не умеет создавать ветки без имён. )
Здравствуйте, alex_public, Вы писали:
_>>>Отдельно в Mercurial существует ещё несколько понятий, которые ты возможно путаешь: _>>>1. Имена веток — это просто неизменяемый атрибут ревизий с особым свойством, он автоматически передаётся всем наследникам данной ревизии (если руками не указано иного). N>>О. Вот тут твоя идеальная картина вдруг резко прекращается и начинается тысяча голодных дьяволов в мелочах. Начиная с того, что команда branch работает почему-то с вот этими "неизменяемыми атрибутами ревизий с особым свойством", что во всех найденных howto и объяснениях именно это называется веткой, что ты в начале дискуссии упорно доказывал, что именно это и есть ветки, а не то, что ты вдруг начал писать в этом постинге, и прочая, и прочая, и прочая. _>Так где оно называется то так? Скажем при описание какой-нибудь команды с возможным параметром в виде этого самого атрибута (введённого специально для идентификации неанонимных веток). Ты думаешь кто-то будет писать "передаём команде специальный атрибут branch1, идентифицирующий нашу ветку"? Естественно все пишут "передаём команде ветку branch1".
А должно быть "передаём команде ярлык branch1", например. Но не ветку. Но этот твой пример ещё интереснее. Я приводил диаграмму, где этим тегом пометил два коммита в разных ветках. Что команда сделает? Если отфильтрует из всего репо или от указанной точки роста все такие коммиты, то ещё понятно, но какой смысл, если они могут не входить в DAG с общей головой? А если что-то сделать с потенциальной головой, то если их две, какое будет принято решение?
_>>>2. Закладки — просто символические указатели (опциональные) на последнюю (автоматически перескакивают при фиксации) ревизию в ветках. По сути является аналогом веток в Git. Были введены не сразу (видимо как раз для удобства людей переходящих с Git). N>>Аналогом веток почти _везде_ кроме Hg. Начиная с того же CVS. Частично — и для SVN, если считать веткой базовый каталог и учитывать возможность прыжка между такими базами. _>Неизменность истории мне нравится больше)
А при чём тут вообще неизменность истории?
_>Ну вообще то раньше (до популярности гитхаба) со старых систем как раз чаще переходили на Mercurial в силу более привычной системы команд. Сейчас же из-за распиаренности гитхаба чаще переходят на git и страдают потом с ним. )
Я уже предупреждал на тему эмоциональных крючков. Если ты не можешь обойтись без этих "идеально", "страдают" и т.п., говоря о чём-то кроме собственного опыта и опыта тех (явно названных), кто тебе явно доверил такое право, то прекращай дискуссию со мной.
И у меня впечатление о процессах в период бурного роста популярности этих систем — заметно противоположное. Возможно, в Windows среде происходит именно так. В моих краях если что-то и влияло на популярность Git, то это авторитет Линуса. Но он проектировал Git с точки зрения требуемых ему сценариев, в которые входит — основные принципиальные особенности:
* категорическая ориентированность на содержание коммита, независимо от конкретного места его размещения в истории, в конкретном репо и т.п. (делает любые id локальными)
* возможность редактирования уже сформированных предложений, даже длинных цепочек (чаще всего через дискуссию в LKML и родственные рассылки)
* эффективное слияние многих источников за раз (многих — это до сотен)
* подчинённые деревья, выживающие после upstream rebase
и мне все полученные от этого плюшки оказались выгодными, а сопутствующие недостатки — несущественными.
_>Ну это естественно если руками в консоли работают. При классической работе через плагин в IDE разницы между этими двумя DVCS почти не будет. N>>К тому же, сам по себе сценарий типа "тут переехали назад по истории и начали рост от нового места" без внятной формулировки причины, зачем нужен этот самый рост, для меня выглядит банально нелепым. Если есть причина, надо её назвать хотя бы для себя и хотя бы для того, чтобы в истории не болталась забытая цепочка. А если она названа — она и будет названием ветки в общепринятом стиле. _>А если причиной развилки будет всего лишь синхронизация изменений с двух разных машин? )
Притянул состояние с другой машины — да, явно назвав, иначе несекьюрно — и начал играться.
А при многих таких нескольких — даже в пределах одного отдела — название ветки начинает играть роль собственно принципиального указания, от кого взято конкретное изменение, потому что понять это по содержанию уже невозможно.
Безымянная ветка для этого становится случаем ничтожной экономии усилий на частный случай, когда таких источников считанные единицы, они не конфликтуют (до неразличения) по смыслу с любыми локальными изменениями (а программист ещё не устал и способен отличать источники по их виду), используемые средства явно показывают все эти головы и их не настолько много, чтобы не вмещались в интерфейс... возможно, ты и твоя команда способны всё это осиливать, но я предпочту тратить мысленные усилия на что-то более для меня полезное.
N>>Ну, если ты знаешь, как провести эти тесты — покажи скрипты и результаты. Не думаю, что они покажут что-то принципиально важное (я лучше бы для сравнения взял результат перегонки чего-то открытого активно разрабатываемого), но просто покрасоваться цифрами — сгодится. _>Ну тут уже кидали результаты. У меня в принципе похожие — у Mercurial раза в 1,5 меньше получаются пакеты изменений. ) Т.е. где-то так же и сеть загружается при синхронизации.
При остальных плюшках Git разница не принципиальна, но имеет смысл попинать авторов.
Здравствуйте, alex_public, Вы писали:
_>А причём тут git? ) Я отвечал на твой как бы юмор, что можно было бы сделать реализацию имён веток в Mercurial через добавления этого имени в комментарий ревизии через хук. Так вот я и ответил, что да, теоретически это было бы похоже, но тогда перестали бы работать возможности многих команд Mercurial, умеющих принимать имя ветки в качестве параметра.
С чего бы это они перестали? Сейчас они анализируют отдельный атрибут, некорректно названный "branch". А могли грепать текст комментария (чуть менее эффективно на больших комментариях в стиле linux kernel, где к 2-строчному изменению может прилагаться oops, стартовый dmesg, разъяснение на пальцах на две страницы и два десятка acked-by) или сделать универсальный механизм атрибутов ревизии (полезен не только ради ярлыка системы "ветка", но и для кучи других применений).
Здравствуйте, alex_public, Вы писали:
D>>А чем это полезно? На пальцах. _>Ну то что это неизменяемый атрибут (а не указатель, как bookmark, или изменяемый tag), даёт нам возможность гарантированного сохранения всей истории, в отличие от того же git'a.
"Гарантированное сохранение всей истории" обеспечивается не этим атрибутом, а тем, что откат невозможен (даже на одну ревизию назад это "roll back the last transaction (DANGEROUS) (DEPRECATED)") (не хватает ещё ®™ после этих Caps ), правка более чем на одну ревизию вообще ничем не делается, даже если ты понял, что сотворил дикую чушь (если верить докам) Это убойное отличие от Git, который действует по принципу "вы локально можете изменять что угодно, ваши проблемы, но попробуйте теперь заставить других это принять".
(Положительным следствием этого для Git является то, что можно делать несколько подходов к одной задаче, уточняя реализацию в виде цепочки коммитов, каждый из которых сам по себе ясен, прямолинеен и решает только одну задачу. Мне неоднократно приходилось (в смысле, для такой понятности и своего удобства) вставлять в эту цепочку в начало какие-то изменения, чаще всего рефакторинг для более полного охвата задачи одного коммита. С тем, что в Hg после команды commit уже ничего не изменить, разве что породить новую ветку, это различие фатально. Но и порождение новой ветки даёт интересный эффект — а почему бы не изменить имя старой? Ан нет, нельзя, если по канонам.)
А сам по себе дополнительный атрибут "branch" у ревизии никак не влияет на её присутствие в финальной истории — ни в плюс, ни в минус.
_>Вот тут https://habrahabr.ru/post/123700/ можно глянуть картинки, демонстрирующие эту разницу на примере.
Сами по себе вопросы, которые там ставят — "на какую ветку было зафиксировано изменение ab3e2afd?" — показывают концентрацию на понятии "ветка" вместо цели самого изменения (которое обычно в корпоративной среде реализуется в виде имени тикета, под который делается изменение). При том, что в сообщении коммита можно записать что угодно, это становится подгонкой под заранее известный результат.
Здравствуйте, netch80, Вы писали:
N>Что ты называешь этой задачей? Проведение развития пучка веток без явной маркировки голов названиями веток? Я объяснил уже, почему считаю это не просто бесполезным, но и вредным. Поэтому решение этой задачи я в принципе не рассматриваю.
Ну и зря. Если лично тебе оно не нужно, то это не значит что и другим тоже. Я знаю многих использующих Mercurial вообще без named branches/bookmarks и при этом очень довольных удобством работы.
N>А вот та задача, на которую должна быть оптимизирована любая DVCS, в основе формулируется следующим образом. Имея некоторый проект (неважно, public/private, opensource/закрытый), выполнить задачу (добавить фичу, полечить баг, whatever), для чего N>а) сделать копию репо, если ещё нет N>б) отделить в явном виде конкретную работу (что означает её таки назвать, потому что при >=2 таких начинаешь путаться, что где делаешь, а от 4 средний программист совсем потеряет понимание) N>в) в процессе работы, войдя в контекст, генерировать последовательность коммитов для её решения (причём, если это совместная работа, каждый коммит сам по себе должен быть, как класс в SOLID, прост, понятен и решает ровно одну цель) N>в2) при необходимости, порождать подзадачи и вести их решение отдельно, потом возвращаясь вверх; N>г) иметь удобную (что бы это ни значило) возможность в процессе объединения решения с другими производить адаптации уже сделанного N>д) в процессе code review иметь возможность обрабатывать замечания, причём к не-последним коммитам N>е) иметь удобную (опять же, не уточняем пока детали) возможность иметь локальные изменения, которые остаются только локальными N>ж) в следствие экспорта изменений другим, они не должны выглядеть для них принципиально "чужеродными", приходить предельно лёгким путём (любым из) и естественно ложиться в локальные репозитории
В принципе логично написано.
N>А теперь смотрим на Hg, имея в виду сравнение одновременно с CVCS (CVS, SVN) и Git (согласно моему опыту работы больше, чем на сделать пару мелких тестов):
Ох, ну я же ещё в самом начале этой дискуссии писал, что за годы параллельного развития все современные dcvs обрели приблизительно одинаковые технические возможности (ну вот разве что git так и не научился по нормальному анонимным веткам) и выбор должен делаться только по удобству (достаточно субъективная вещь) их использования. Ну если хочешь, можем разобрать по пунктам. )
N>(а) — проблем нет; для CVS, SVN меняется на checkout рабочей копии без репо; N>(б) — для DVCS, требует какого-то вида бранчевания (если не решается в один чих), но именованного под растущую ветку => для Hg это bookmarks; для CVCS — всё в рабочей копии, если нет центрального решения выделить под это ветку;
Для hg это или bookmarks или named branch, в зависимости от предпочтений в поведение.
N>(в) — не проблема, если реализация изначально идеальна для момента коммита; если нет, упираемся в проблемы (г) и (д); N>(в2) — решается в любой DVCS суббранчеванием, в CVCS клонированием рабочих копий; N>(г),(д) — требует interactive rebase; считаем, работает только в Git;
В Mercurial это тоже реализовано, через команду hg histedit. Однако я крайне не рекомендую использовать этот подход, т.к. правильным методом review в DCVS должно быть создание новой ревизии.
N>(е) — требует stash и interactive-add (patch-add как вариант), или даже edit-add; везде, кроме Git, приходилось временно делать копию рабочих файлов, вырезать не запланированное на данный коммит, и потом возвращать;
В Mercurial соответственно hg shelve и hg record ("hg commit -i" начиная с версии 3.4). Лично я возможность "hg commit -i" никогда не использую, но если кому-то надо, то оно имеется...
N>(ж) — "дискардит" смысл в Hg'шных номерах коммитов в цепочке (как 0: в 0:32f5bb09 и тому подобных знаках), между репо работают только хэши как идентификаторы; в CVS и SVN работает, пока нет конфликтов; конфликты в SVN решаются легче, чем в CVS, но всё равно хуже, чем в Git; про качество решения конфликтов в Hg не в курсе.
Кстати, решение конфликтов — это должен был бы быть ещё отдельный пункт (ж — это же у тебя про экспорт/импорт). Но думаю там особых отличий нет, хотя алгоритмы и совсем разные. А вот что касается экспорт/импорта, то как раз тут у Mercurial всё намного проще и удобнее. Тут и наличие анонимных веток и их поведение при синхронизации (они просто все возникают у всех) и ещё много мелких нюансов. Т.е. те же цели достигаются тут гораздо меньшими усилиями.
N>Для меня самым ограничительным в плане выбора средств оказывается (е) — и он привязывает только к Git. Причём, были ситуации, что у конторы центральным средством был CVS, но локальное удобство заставляло использовать Git; даже лёгкий гимор на операции "после cvs update пришли обновления, их надо влить локально" оказывался терпимым. Также для того, чтобы было не стыдно смотреть на результат, почти всегда нужен (г).
Ну как видишь никаких ограничений нет на самом деле (и я кстати об этом говорил изначально). Есть только разница в удобстве (причём в пользу Mercurial). Люди даже подобные https://www.mercurial-scm.org/wiki/GitConcepts#Command_equivalence_table таблички соответствия команд делают. ))) Но опять же там есть не все команды (например нет heads) из-за отсутствия в конкуренте соответствующей концепции (типа анонимных веток).
N>Часть пунктов не ограничивает, но приводит к тому, что в Hg заморочка локальными фичами типа номеров ревизий (ж) и безымянными головами (б) тратит мозговые ресурсы.
Это от непривычки. ) А потом оказывается, что это ещё и намного удобнее старых подходов.
_>>Как раз придумывание имени ветки, которая существует например только ради синхронизации — это и есть очевидно лишнее. N>Если общая схема с изменениями от кого-то другого, то представь себе ситуацию, что он что-то меняет от точки истории, которая на 200 коммитов назад — ты в любом интерфейсе вначале будешь долго мотать, чтобы её найти, или он будет показывать растянутые линии. А если таких несколько, то уже начнётся постоянная путаница, где чьи изменения и что из них надо принимать. Идею оптимизации на набор двух символов я понимаю, но принять её как-то сложно.
Здравствуйте, alex_public, Вы писали:
_>·>Нет, не ответвляются. Точнее, если переводить дословно "diverged" — не расходятся. Тривиальная линейная история. Звёздочки это ревизии. А линии — ну просто линии, чтобы было понятно что куда относится. Т.е. этот рисунок отображает тот факт, что release был сделан 4 ревизии назад от development. Или, иначе говоря, с тех пор как мы зарелизились, было надевелопено ещё четыре новые ревизии. Это самый простой рисунок для этой ситуации, именно он такой и будет в git. В hg он будет сложнее, с лишними наворотами. _>А, всё, я понял что ты нарисовал. Правда не знаю зачем применять для такого именованные ветки (когда нет реальных разветвлений), но если очень хочется, то в mercurial можно без проблем и оно прямо так и будет выглядеть. )
Потому что ветки обычно имеют некий смысл, связанный с процессом разработки, а не с текущей структурой истории. Нужны же ветки для того, чтобы понимать что у нас сейчас release, а что development. А разветвление расхождение веток это текущее состояние истории.
_> И даже меньше команд чем в git понадобится. )))
Покажи, плз. Насколько я знаю в hg без коммита ветку не создать.
_>>>·>Вроде это не linear sequence, сколько тут веток? _>>>А тут одна ветка отделяется от другой (в которой было разветвление)? И что? ) _>·>Это не linear sequence, как это согласуется приведённой тобой цитате? _>Я просто не понял твой формат рисования) Теперь понял) _>Но кстати вопрос "сколько веток" некорректен для некого отрезка истории, т.к. на его протяжение это число может меняться. Например тут в начале одна ветка, потом она разветвляется на две, а потом снова сливается в одну. Данный вопрос корректен только для фиксированного момента времени.
Мой вопрос в том, что имеется в виду в приведённой тобой документации: «"line of development" is a linear sequence of consecutive changesets». Где в приведённом мной графе истории line of develpment? Что есть head? Что есть branch?
_>>>Глупое состояние было в репозитории с которым игрался netch80. А в данном куске документации подробно объяснялось как он его добился. _>·>А толком можно объяснить? Где игрался, как игрался, почему глупое? Как ещё можно играться? Если у тебя есть какая-то мысль, сформулируй её чётко. _>Это всё было в сообщениях выше) Он спрашивал каким образом получилась некая ересь, так вот данная фраза из документации была объяснением. )
Не понял я, что именно ты имеешь в виду.
_>>>У тебя будет просто две ветки с именем experiment после синхронизации. ) _>·>Нет, rtfm. В моём репо будет моя ветка "experiment", и твоя "alex_public_experiment". _>·>А в hg что будет? _>Я вообще то про Mercurial и говорил. )))
Ааа. Понял. Хорошо, как в mercurial отличать мой "experiment" от твоего?
_>>>Судя по твоему следующему сообщению ты уже сам всё понял, но всё же отвечу: будет 4 ветки, каждая пара из которых будет с одним именем. И команда heads покажет все 4. ) _>·>Если ты читал документацию, тебя не должно затруднить привести цитату, что ветки-alex_public-вида называются именно словом "ветка". Я читал документацию, это называется не ветки, а головы.
_>Голова — это одна ревизия, не путай с ветками (они состоят из набора ревизий). ) Ну а что касается цитаты... Я тебе уже в который раз говорю прочитать внимательно эту https://www.mercurial-scm.org/wiki/Branch ссылку. Там же всего лишь пара страниц, а ты уже в который раз не можешь осилить. ))) Например: _>
_>Strictly speaking, a branch is created when a user creates a new changeset C2 in a repository R0, if its parent changeset P already has a child C1, thus adding a second child changeset C2 to that parent P. This adds a new head to R0.
Или, иначе говоря, выразить тот факт, что мы зарелизили всё что надевелопили.
_>или _>
_>As such, each changeset in Mercurial forms an element of a branch. A changeset thus can be said to "belong to a branch". Per that definition, a branch is simply a linear sequence of changesets.
_>Ещё требуются пояснения? ) Думаю вполне видно, что никаких намёков на именованные ветки тут нет.
Не осиливаю потому что полная мешанина из терминов. Чем тогда бранч отличается от "line of development"?
_>>>Ну а я что сказал? ) Список ревизий без потомков. ) _>·>Ты говорил: «Никакой сущности "головы" в mercurial нет». В оф.документации есть, однако. Даже команда есть такая. Я не понимаю зачем ты вводишь в заблуждение. _>Это не отдельная сущность, а просто название ревизии без потомков. Т.е. этот "термин" можно спокойно и в git применять. )))
Бранч может иметь несколько их. В этом и путаница, которая требует новой сущности. В гите этот термин бессмысленен.
_>>> А tip — это всего лишь автоматический Tag, опять же для удобства. ) _>·>tag вообще-то неизменяемая сущность во всех других мне известных vcs. Так что и таги в hg оказывается какие-то особенные. _>·>А tip значит не просто некий таг как и все, а особенный, "автоматический", ещё одна сущность. Бардак. _>Кошмар, кошмар. ))) Нельзя ничего добавлять в систему для удобства пользоваться. Пускай он лучше побольше сам работает, не развалится, да? )))
Конечно нельзя, если можно не добавлять, иначе Оккам бритвочкой полоснёт. Никакого удобства.. путаница только — вроде бы и тег, но какой-то особенный...
_>·>Не знаю, странная ссылка была. Я мало что понял что и как тестировалось, да ещё и 5 лет назад. Хочется более-менее реальные тесты увидеть. Гигахостинги типа github говорят о том, что это значительной проблемой не является. _>·>И вообще, если просто почитать выводы: "If you need the fastest system and don’t mind occassional performance glitches and volatile repository sizes, git is the way to go", ибо я, как юзер, предпочитаю работать с быстрой системой. "If you need reliable performance and space requirements, Mercurial is the better choice" — это проблема серверов и железа, которое сейчас дешевое. _>Ну так я же это тестирование привёл не в качестве аргумента за использование одной или другой системы (в этом смысле я уже давно сказал, что подобные вопросы у них одинаково удовлетворительно для пользователя решены и есть смысл выбирать только по вкусу удобства работы с системой команд), а в контексте нашего обсуждения преимуществ разных архитектур. Это не я начал первым утверждать, что у Git архитектура более совершенная. Я лишь указал, что на практике эта вроде как совершенная архитектура проигрывает. )))
Этот конкретный пример не убедительный, ибо непонятно как мерили и как воспроизвести результат. А так я и не отрицаю, что можно найти такие условия, когда эта архитектура будет вести себя хуже. "Хррр... — сказала японская бензопила."
_>>>При мелком апдейте основной размер идёт на накладные расходы. Я как раз потому и сказал большой файл засунуть, чтобы было видно. ) _>·>Так я засунул ~1мб текстовый файл. Изменение я делал добавлением новой строчки в конец "echo boo >> file", как ты и просил в описании эксперимента. _>Так я и говорю, что смысл имеет сравнение только цифр для пакета с двумя ревизиями (т.к. там мегабайтный файл), а в пакете с одной ревизией большую часть места занимают накладные расходы на формат пакета. Поэтому там и разницы особой нет. А вот при наличие большого объёма данных сразу видна разница в 1,5 раза.
Я не понял какой ты делаешь вывод и причём тут архитектура. Чем ты объясняешь разницу в размере?
_>>>Зато зависит от архитектуры системы. _>·>Каким образом? К чему эта тупая упёртость? Я ж привёл тебе результат эксперимента — 399 и 419 байт. Проведи эксперимент сам, если не веришь. _>У тебя всё верно, но я говорю об измерение пакетов с двумя ревизиями. ) И от чего по твоему оно зависит, если нет архитектуры системы? )
Мне кажется, что просто разный алгоритм компрессии применён (команды hg выполнялись медленее раза в два), надеюсь это он компрессией занимался.
Да, точно. Почитал доку на hg bundle и обнаружил флажок -t. Если добавить "-t gzip", то размер становится 228763 (напоминаю что у git было 228253). Ы?
_>>>Речь про бэкап сервера, а не про работу с git. ) _>·>Что за "бэкап сервера"? И чем он будет принципиально отличаться в случае git и hg? _>Эмм, тебе не знакомо понятие бэкапа сервера? Не важно инкрементального или нет... _>Отличие у git и hg будет в том, что в случае инкрементального бэкапа хранилище git'a после repack'а придётся копировать всё заново (хотя там может добавилась всего пара ревизий), а в случае hg будет скопировано только реальное изменение (новые ревизии). В случае большой истории в репозитории это может быть очень существенная разница.
Так я и говорю — если ты правда считаешь это проблемой, настрой бэкапы с помощью бандлов.
Я бы вначале подумал над проблемой — а правда ли наивный инкрементальный бэкап файлов активного hg репозитория можно будет использовать для восстановления?
Большой это сколько? Самый большой я видел в своей жизни это 3.2Gb. Фигня для современного железа.
Да и вообще, повторяю — насколько вообще нужны бэкапы для dvcs? Гораздо проще и полезнее сделать репликацию.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, alex_public, Вы писали:
_>>>·>Этого же эффекта можно добиться помещая имя текущей ветки в коммент коммита (можно хук сделать). Но зачем из буханки делать троллейбус? _>>>Можно и так))) Но тогда с этим не смогут работать различные команды (типа heads, pull/push и т.п.). _>·>Команда heads, конечно работать не будет, ибо такой команды в git нет, так как этого бреда с многоголовыми ветками нет. Неслитые ветки в git можно посмотреть, как ни странно, командой branch с ключиком "--no-merged". _>·>А с push/pull что случится-то? _>А причём тут git? ) Я отвечал на твой как бы юмор, что можно было бы сделать реализацию имён веток в Mercurial через добавления этого имени в комментарий ревизии через хук. Так вот я и ответил, что да, теоретически это было бы похоже, но тогда перестали бы работать возможности многих команд Mercurial, умеющих принимать имя ветки в качестве параметра.
Создали сложности и героически с ними борются.
_>Что касается git'a, то его вообще смешно обсуждать в данном контексте, т.к. он банально не умеет создавать ветки без имён. )
Потому что это не имеет смысла.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, netch80, Вы писали:
N>А должно быть "передаём команде ярлык branch1", например. Но не ветку. Но этот твой пример ещё интереснее. Я приводил диаграмму, где этим тегом пометил два коммита в разных ветках. Что команда сделает? Если отфильтрует из всего репо или от указанной точки роста все такие коммиты, то ещё понятно, но какой смысл, если они могут не входить в DAG с общей головой? А если что-то сделать с потенциальной головой, то если их две, какое будет принято решение?
Не, команды по определению имеющие дело с одной ревизией только их и принимают (а не имена ссылок/закладки/теги и т.п.).
_>>Неизменность истории мне нравится больше) N>А при чём тут вообще неизменность истории?
Ну точнее речь не вообще об истории, а о сохранение расклада с именными ветками)
_>>А если причиной развилки будет всего лишь синхронизация изменений с двух разных машин? ) N>Притянул состояние с другой машины — да, явно назвав, иначе несекьюрно — и начал играться. N>А при многих таких нескольких — даже в пределах одного отдела — название ветки начинает играть роль собственно принципиального указания, от кого взято конкретное изменение, потому что понять это по содержанию уже невозможно.
Так а зачем мне изменения другого отдела в чистом виде? ) Мне они не нужны. Мне нужна основная ветка развития, с применёнными к ней изменениями этого отдела (потому как кто кроме них правильнее осуществит слияние их изменений).
N>Безымянная ветка для этого становится случаем ничтожной экономии усилий на частный случай, когда таких источников считанные единицы, они не конфликтуют (до неразличения) по смыслу с любыми локальными изменениями (а программист ещё не устал и способен отличать источники по их виду), используемые средства явно показывают все эти головы и их не настолько много, чтобы не вмещались в интерфейс... возможно, ты и твоя команда способны всё это осиливать, но я предпочту тратить мысленные усилия на что-то более для меня полезное.
Какие мысленные усилия? ) Если предположим (для упрощения объяснения) в данной разработке не нужны долгоживущие отдельные ветки (которые по смыслу создаются, а не для синхронизации отдельных членов команды), то в Mercurial будет просто ровно одна ветка периодически разветвляющаяся (в моменты параллельной разработки членов команды) и тут же сливающаяся в одну.
А что будет в случае в Git? )
_>>Ну тут уже кидали результаты. У меня в принципе похожие — у Mercurial раза в 1,5 меньше получаются пакеты изменений. ) Т.е. где-то так же и сеть загружается при синхронизации. N>При остальных плюшках Git разница не принципиальна, но имеет смысл попинать авторов.
Согласен. ) Я собственно изначально сказал, что оба инструмента полностью удовлетворяют обычного пользователя. А все эти тесты размеров, скоростей и т.п. поднял только после заявления о том, что типа низкоуровневая архитектура git намного совершеннее. )))
Здравствуйте, ·, Вы писали:
_>>А, всё, я понял что ты нарисовал. Правда не знаю зачем применять для такого именованные ветки (когда нет реальных разветвлений), но если очень хочется, то в mercurial можно без проблем и оно прямо так и будет выглядеть. ) ·>Потому что ветки обычно имеют некий смысл, связанный с процессом разработки, а не с текущей структурой истории. Нужны же ветки для того, чтобы понимать что у нас сейчас release, а что development. А разветвление расхождение веток это текущее состояние истории.
Эм, а какой смысл имеет последовательная группа ревизий с меткой "release"? ) Release — это же обычно некий фиксированный момент времени, а не интервал. Соответственно в репозитории это соответствует одной выделенной ревизии. Обычно её или помечают соответствующим тегом прямо в основной ветке или же создают отдельную ветку с именем release, в которую изредка (как раз в моменты времени релиза) сливают результаты из основной ветки. А то, что показал ты, я никогда не видел и пока не могу представить для чего оно может понадобиться.
_>> И даже меньше команд чем в git понадобится. ))) ·>Покажи, плз. Насколько я знаю в hg без коммита ветку не создать.
Нельзя) Но у тебя же там как раз последовательность фиксаций нарисована. )
·>Мой вопрос в том, что имеется в виду в приведённой тобой документации: «"line of development" is a linear sequence of consecutive changesets». Где в приведённом мной графе истории line of develpment? Что есть head? Что есть branch?
"line of develpment"=="branch" (который реальная ветка, а не атрибут branch name). Ну а head — это последняя ревизия в ветке.
_>>Я вообще то про Mercurial и говорил. ))) ·>Ааа. Понял. Хорошо, как в mercurial отличать мой "experiment" от твоего?
Ну например по автору и по предку (в GUI по положения в дереве).
·>А как тогда такую историю создать? ·>
Я так и не понял, зачем ты хочешь применять ветки там, где нет развилок? )
·>Или, иначе говоря, выразить тот факт, что мы зарелизили всё что надевелопили.
Ну поставь на последнюю ревизию тег "release 2.0" и всё. Или же организуй отдельную ветку с релизами. Я уже писал выше.
_>>
_>>As such, each changeset in Mercurial forms an element of a branch. A changeset thus can be said to "belong to a branch". Per that definition, a branch is simply a linear sequence of changesets.
_>>Ещё требуются пояснения? ) Думаю вполне видно, что никаких намёков на именованные ветки тут нет. ·>Не осиливаю потому что полная мешанина из терминов. Чем тогда бранч отличается от "line of development"?
Ничем и не отличается.
_>>Это не отдельная сущность, а просто название ревизии без потомков. Т.е. этот "термин" можно спокойно и в git применять. ))) ·>Бранч может иметь несколько их. В этом и путаница, которая требует новой сущности. В гите этот термин бессмысленен.
Не может. ) Несколько голов может иметь виртуальная (потому как в реальности её не существует, а есть несколько веток с одинаковым атрибутом "имя") сущность называемая named branch.
_>>Кошмар, кошмар. ))) Нельзя ничего добавлять в систему для удобства пользоваться. Пускай он лучше побольше сам работает, не развалится, да? ))) ·>Конечно нельзя, если можно не добавлять, иначе Оккам бритвочкой полоснёт. Никакого удобства.. путаница только — вроде бы и тег, но какой-то особенный...
Он не особенный, а просто устанавливаемый самой системой (а не пользователем). ))) Автоматика... ) Можешь сам такое сделать хуками в том же git'e.
·>Я не понял какой ты делаешь вывод и причём тут архитектура. Чем ты объясняешь разницу в размере?
Разными алгоритмами и форматами хранилища.
_>>У тебя всё верно, но я говорю об измерение пакетов с двумя ревизиями. ) И от чего по твоему оно зависит, если нет архитектуры системы? ) ·>Мне кажется, что просто разный алгоритм компрессии применён (команды hg выполнялись медленее раза в два), надеюсь это он компрессией занимался. ·>Да, точно. Почитал доку на hg bundle и обнаружил флажок -t. Если добавить "-t gzip", то размер становится 228763 (напоминаю что у git было 228253). Ы?
А можно узнать флажок в git, который позволит добиться результата mercurial? )
Здравствуйте, alex_public, Вы писали:
_>>>А, всё, я понял что ты нарисовал. Правда не знаю зачем применять для такого именованные ветки (когда нет реальных разветвлений), но если очень хочется, то в mercurial можно без проблем и оно прямо так и будет выглядеть. ) _>·>Потому что ветки обычно имеют некий смысл, связанный с процессом разработки, а не с текущей структурой истории. Нужны же ветки для того, чтобы понимать что у нас сейчас release, а что development. А разветвление расхождение веток это текущее состояние истории. _>Эм, а какой смысл имеет последовательная группа ревизий с меткой "release"? ) Release — это же обычно некий фиксированный момент времени, а не интервал. Соответственно в репозитории это соответствует одной выделенной ревизии. Обычно её или помечают соответствующим тегом прямо в основной ветке или же создают отдельную ветку с именем release, в которую изредка (как раз в моменты времени релиза) сливают результаты из основной ветки. А то, что показал ты, я никогда не видел и пока не могу представить для чего оно может понадобиться.
Да, смысла меток на ревизиях нет, поэтому подход hg и является не самым осмысленным.
Ладно. Давай заменим "release" на "release_candidate", чтобы тебе понятнее было. Т.е. мы хотим знать какую ревизию мы сейчас тестируем более тяжелыми тестами (ручное или soak тестирование, например).
А тегом помечаются конкретные номера публичных версий, и теги — read-only.
_>>> И даже меньше команд чем в git понадобится. ))) _>·>Покажи, плз. Насколько я знаю в hg без коммита ветку не создать. _>Нельзя) Но у тебя же там как раз последовательность фиксаций нарисована. )
Что за фиксации? Ревизии в смысле? Ревизия это коммит, т.е. патч+автор+етс. Создание ветки это только в hg является коммитом, что опять фигня какая-то.
_>·>Мой вопрос в том, что имеется в виду в приведённой тобой документации: «"line of development" is a linear sequence of consecutive changesets». Где в приведённом мной графе истории line of develpment? Что есть head? Что есть branch? _>"line of develpment"=="branch" (который реальная ветка, а не атрибут branch name). Ну а head — это последняя ревизия в ветке.
Плиз, на моём графе отметь все эти понятия.
_>>>Я вообще то про Mercurial и говорил. ))) _>·>Ааа. Понял. Хорошо, как в mercurial отличать мой "experiment" от твоего? _>Ну например по автору и по предку (в GUI по положения в дереве).
"автор" не годится. Я могу продолжить твой эксперимент и накоммитить туда что-нибудь, и даже обратно тебе потом запушить.
"предок" уж тем более не годится, т.к. мы можем начать свои эксперименты от одной и той же ревизии, скажем, последнего публичного релиза.
Ещё что-то есть?
_>·>А как тогда такую историю создать? _>·>
_>Я так и не понял, зачем ты хочешь применять ветки там, где нет развилок? )
Не "нет развилок", а может не быть развилок. Даже hg это упоминает: "A new branch name can be started in the middle of a development line, not necessarily at a diverging point". Но начало именованного бранча это уже коммит, а поэтому история уже разъедется. Бардак жуткий.
_>·>Или, иначе говоря, выразить тот факт, что мы зарелизили всё что надевелопили. _>Ну поставь на последнюю ревизию тег "release 2.0" и всё. Или же организуй отдельную ветку с релизами. Я уже писал выше.
Теги для конкретных версий, а не для процесса релиза.
_>>>
_>>>As such, each changeset in Mercurial forms an element of a branch. A changeset thus can be said to "belong to a branch". Per that definition, a branch is simply a linear sequence of changesets.
_>>>Ещё требуются пояснения? ) Думаю вполне видно, что никаких намёков на именованные ветки тут нет. _>·>Не осиливаю потому что полная мешанина из терминов. Чем тогда бранч отличается от "line of development"? _>Ничем и не отличается.
Ок, если не отличается, значит одно можно заменить на другое, смысл меняться не должен. Давай попробуем. Возьмём
"Branches occur if lines of development diverge"
заменяем
"Branches occur if branches diverge"
Теперь объясни смысл этого предложения.
_>>>Это не отдельная сущность, а просто название ревизии без потомков. Т.е. этот "термин" можно спокойно и в git применять. ))) _>·>Бранч может иметь несколько их. В этом и путаница, которая требует новой сущности. В гите этот термин бессмысленен. _>Не может. ) Несколько голов может иметь виртуальная (потому как в реальности её не существует, а есть несколько веток с одинаковым атрибутом "имя") сущность называемая named branch.
Почему тогда без этой виртуальной сущности hg, как ты говоришь, не сможет функционировать?
_>>>Кошмар, кошмар. ))) Нельзя ничего добавлять в систему для удобства пользоваться. Пускай он лучше побольше сам работает, не развалится, да? ))) _>·>Конечно нельзя, если можно не добавлять, иначе Оккам бритвочкой полоснёт. Никакого удобства.. путаница только — вроде бы и тег, но какой-то особенный... _>Он не особенный, а просто устанавливаемый самой системой (а не пользователем). ))) Автоматика... ) Можешь сам такое сделать хуками в том же git'e.
Вот это и плохо — понятие тег в hg тоже особенное.
_>·>Я не понял какой ты делаешь вывод и причём тут архитектура. Чем ты объясняешь разницу в размере? _>Разными алгоритмами и форматами хранилища.
Разница между алгоритмами bzip2 и gzip не является достижением hg. А форматы тут причём? Какие форматы? Как они влияют на размер?
_>>>У тебя всё верно, но я говорю об измерение пакетов с двумя ревизиями. ) И от чего по твоему оно зависит, если нет архитектуры системы? ) _>·>Мне кажется, что просто разный алгоритм компрессии применён (команды hg выполнялись медленее раза в два), надеюсь это он компрессией занимался. _>·>Да, точно. Почитал доку на hg bundle и обнаружил флажок -t. Если добавить "-t gzip", то размер становится 228763 (напоминаю что у git было 228253). Ы? _>А можно узнать флажок в git, который позволит добиться результата mercurial? )
Не знаю, гугленьне не помогло. Наткнулся только на "The way git normally stores data is using zlib, which, on the tradeoff of performance vs. efficiency, is very fast but not very efficient. It does this because the difference is normally not sufficient that it is worth making operations on the contents of the repository (diffs, merges, etc.) require a large amount of either CPU or memory."
И да, git работает быстрее.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
_>>Эм, а какой смысл имеет последовательная группа ревизий с меткой "release"? ) Release — это же обычно некий фиксированный момент времени, а не интервал. Соответственно в репозитории это соответствует одной выделенной ревизии. Обычно её или помечают соответствующим тегом прямо в основной ветке или же создают отдельную ветку с именем release, в которую изредка (как раз в моменты времени релиза) сливают результаты из основной ветки. А то, что показал ты, я никогда не видел и пока не могу представить для чего оно может понадобиться. ·>Да, смысла меток на ревизиях нет, поэтому подход hg и является не самым осмысленным.
Какой ещё подход hg? ) Это же ты предлагаешь такую схему. )))
·>Ладно. Давай заменим "release" на "release_candidate", чтобы тебе понятнее было. Т.е. мы хотим знать какую ревизию мы сейчас тестируем более тяжелыми тестами (ручное или soak тестирование, например).
Так, давай разберёмся подробно что же ты собственно хочешь. Эти метки должны изменяться со временем или нет? Метка должна быть на одной ревизии или на последовательном их наборе? Ветвление (реальное) требуется или нет? )
·>А тегом помечаются конкретные номера публичных версий, и теги — read-only.
Ну так это смотря где))) В Mercurial они вполне редактируемы. )
_>>Нельзя) Но у тебя же там как раз последовательность фиксаций нарисована. ) ·>Что за фиксации? Ревизии в смысле? Ревизия это коммит, т.е. патч+автор+етс.
Что-то у тебя проблемы не только с пониманием документации Mercurial, но и вообще с переводом английского текста на русский. Commit — это действие (глагол), переводим как фиксация. А changeset — это объект (существительное), переводим как ревизия. Ну а слова "коммит" в русском языке нет и уж тем более в виде существительного (если уж и использовать подобный англицизм, то он должен быть глаголом).
·>Создание ветки это только в hg является коммитом, что опять фигня какая-то.
Только наоборот. Фиксация ревизии порождает ветвление (при условие наличие у текущей ревизии другого потомка) и это абсолютно логично.
_>>·>Ааа. Понял. Хорошо, как в mercurial отличать мой "experiment" от твоего? _>>Ну например по автору и по предку (в GUI по положения в дереве). ·>"автор" не годится. Я могу продолжить твой эксперимент и накоммитить туда что-нибудь, и даже обратно тебе потом запушить. ·>"предок" уж тем более не годится, т.к. мы можем начать свои эксперименты от одной и той же ревизии, скажем, последнего публичного релиза.
Скорее всего так и будет. Но при этом в визуальном дереве всё будет чётко видно и отделено. )
_>>Я так и не понял, зачем ты хочешь применять ветки там, где нет развилок? ) ·>Не "нет развилок", а может не быть развилок. Даже hg это упоминает: "A new branch name can be started in the middle of a development line, not necessarily at a diverging point". Но начало именованного бранча это уже коммит, а поэтому история уже разъедется. Бардак жуткий.
Я вообще то и не говорил, что это в Mercurial невозможно (более того, выше я упоминал, что это реализуется даже меньшим числом команд, чем в git). Я спрашиваю про другое — зачем может понадобится подобная бредовая конструкция? )
_>>·>Или, иначе говоря, выразить тот факт, что мы зарелизили всё что надевелопили. _>>Ну поставь на последнюю ревизию тег "release 2.0" и всё. Или же организуй отдельную ветку с релизами. Я уже писал выше. ·>Теги для конкретных версий, а не для процесса релиза.
Понятие "процесс релиза" в контексте систем контроля версий по прежнему остаётся для меня загадкой. )))
_>>·>Не осиливаю потому что полная мешанина из терминов. Чем тогда бранч отличается от "line of development"? _>>Ничем и не отличается. ·>Ок, если не отличается, значит одно можно заменить на другое, смысл меняться не должен. Давай попробуем. Возьмём ·>"Branches occur if lines of development diverge" ·>заменяем ·>"Branches occur if branches diverge" ·>Теперь объясни смысл этого предложения.
Ветвления происходят при разделение веток. )
_>>·>Бранч может иметь несколько их. В этом и путаница, которая требует новой сущности. В гите этот термин бессмысленен. _>>Не может. ) Несколько голов может иметь виртуальная (потому как в реальности её не существует, а есть несколько веток с одинаковым атрибутом "имя") сущность называемая named branch. ·>Почему тогда без этой виртуальной сущности hg, как ты говоришь, не сможет функционировать?
Ээээ что? ) Я как раз наоборот всё время говорю, что mercurial можно удобно пользоваться вообще без затрагивания "имён для веток"/закладок/тегов, работая только с чистыми базовыми ветвлениями (естественно анонимными) на основе ревизий. Т.е. в основе лежит именно это, а поверх накручены дополнительные опциональные удобства (имена для веток/закладки/теги).
Здравствуйте, alex_public, Вы писали:
_>Ну как видишь никаких ограничений нет на самом деле (и я кстати об этом говорил изначально). Есть только разница в удобстве (причём в пользу Mercurial). Люди даже подобные https://www.mercurial-scm.org/wiki/GitConcepts#Command_equivalence_table таблички соответствия команд делают. ))) Но опять же там есть не все команды (например нет heads) из-за отсутствия в конкуренте соответствующей концепции (типа анонимных веток).
Вот тут на родственном форуме (если ты в РФ, то без Tor не прочтёшь) коллега Lyubomyr Shaydariv пишет (месяца 3 назад, так что актуально):
Я справді дуже люблю hg, і для своїх особистих проектів надаю йому перевагу, а не git, проте з часом я маю все ж деякі розчарування стосовно нього. З ходу можу назвати наступне:
* Відсутність staging area. В git її наповнювати можна в імперативній формі, і згодом видалити із неї файли, випадково туди занесені. Писати hg commit із складним фільтром для комміта важко, і виправляти такий комміт незручно або важко (як і через hg commit —amend, так і через hg strip —keep).
* Імена гілок у hg вічні. Якщо планується якась експериментальна гілка, яку планується назвати «experimental», дуже бажано подумати ще раз, чи вартує їй давати саме таке ім’я, оскільки навіть з hg commit —close-branch створити нову гілку із таким іменем більше не можна буде. Ніколи. Навіть через два роки. Смішно, але тут навіть svn ліпше виглядає.
* Закладки (bookmarks), які концептуально трохи ближчі до git-ових гілок, в hg випиляти інколи також складно (якщо можливо).
* Субрепозиторії в hg мені особисто здаються «дикішими» за субмодулі в git, оскільки hg при коміті в батьківському репозиторії оновляє .hgsubstate, якщо, знову ж таки, в hg commit не вказати правильний фільтр.
* .hgignore лише, по ходу, в кореневій директорії. Якщо субдиректорії мігрують з місця на місце з часом, це також означає, що шляхи в одному .hgignore також потрібно поправити вручну.
Заметь, человек для себя предпочитает Hg, но его подобные грабли таки достали. Я до такой глубины ещё даже первично не докопался.
_>Ну и зря. Если лично тебе оно не нужно, то это не значит что и другим тоже. Я знаю многих использующих Mercurial вообще без named branches/bookmarks и при этом очень довольных удобством работы.
Это несекьюрно, годится только для персонального репо, который ни с кем не обменивается.
Лучше это было бы перенести в extensions и не включать по умолчанию.
_>Ох, ну я же ещё в самом начале этой дискуссии писал, что за годы параллельного развития все современные dcvs обрели приблизительно одинаковые технические возможности (ну вот разве что git так и не научился по нормальному анонимным веткам) и выбор должен делаться только по удобству (достаточно субъективная вещь) их использования. Ну если хочешь, можем разобрать по пунктам. )
Ну да, теперь осталось сделать совсем немного мелочей:
1. Внести такие действительно полезные вещи, как shelve, record, histedit, rebase в базовую функциональность, а не расширения.
2. Диверсии в виде неименованных голов, наоборот, вынести в расширения и не включать по умолчанию.
3. Описанным расширениям довести функциональность до минимально необходимого набора:
* показ staging, сброс staging в ноль, частичный сброс (по файлу, по диффу).
* shelve должен уметь брать не только локальные изменения, но и staging.
4. Решить остальные описанные Lyubomyr Shaydariv проблемы. Для начала, переименовать таки "ветки" во что-то другое (покопался в словаре, нашёл замечательное слово tally). Далее, обеспечить возможность их делать неуникальными (а лучше вообще не опираться на "закрытие", эта концепция должна умереть). Решить остальные описанные им проблемы.
_>В Mercurial это тоже реализовано, через команду hg histedit. Однако я крайне не рекомендую использовать этот подход, т.к. правильным методом review в DCVS должно быть создание новой ревизии.
Я проверил — histedit меняет хэш ревизии, так что тут, похоже, сделано адекватно (как в Git, Monotone и прочих, где хэш гарантированно требуется проверяемым по содержанию конкретной ревизии). А вот то, что ты этого не знаешь, и то, что я про histedit вытащил только после долгой дискуссии, показывает, что твой опыт просто неприменим под мои задачи и подходы.
_>Кстати, решение конфликтов — это должен был бы быть ещё отдельный пункт (ж — это же у тебя про экспорт/импорт). Но думаю там особых отличий нет, хотя алгоритмы и совсем разные. А вот что касается экспорт/импорта, то как раз тут у Mercurial всё намного проще и удобнее.
Опять пустые эмоциональные заклинания.
_>Тут и наличие анонимных веток и их поведение при синхронизации (они просто все возникают у всех)
Я уже говорил, что в Git ты можешь потребовать синхронизации полного пучка веток, но по умолчанию это отключили в 2.2.
_>Это от непривычки. ) А потом оказывается, что это ещё и намного удобнее старых подходов.
приводил картинку того, что имею в виду. Предположим что ревизии 2 и 3 созданы на разных компьютерах. Как бы ты реализовал подобное с помощью git? )
Очевидно — fetch+merge. Если ты хочешь сказать, что тебя утомляет необходимость назвать принятую от другого ветку, то я могу только выразить соболезнования, но не согласиться.
Здравствуйте, alex_public, Вы писали:
N>>А должно быть "передаём команде ярлык branch1", например. Но не ветку. Но этот твой пример ещё интереснее. Я приводил диаграмму, где этим тегом пометил два коммита в разных ветках. Что команда сделает? Если отфильтрует из всего репо или от указанной точки роста все такие коммиты, то ещё понятно, но какой смысл, если они могут не входить в DAG с общей головой? А если что-то сделать с потенциальной головой, то если их две, какое будет принято решение? _>Не, команды по определению имеющие дело с одной ревизией только их и принимают (а не имена ссылок/закладки/теги и т.п.).
А зачем тогда эти ярлыки используются? Только для чтения истории "под какой ярлык была эта ревизия"? Из пушки по воробьям.
_>>>Неизменность истории мне нравится больше) N>>А при чём тут вообще неизменность истории? _>Ну точнее речь не вообще об истории, а о сохранение расклада с именными ветками)
Так это же не именные ветки. Это произвольные ярлыки. Если ревизия зафиксирована, их менять нельзя. Сохраняй себе сколько угодно, но не зови их ветками.
_>>>А если причиной развилки будет всего лишь синхронизация изменений с двух разных машин? ) N>>Притянул состояние с другой машины — да, явно назвав, иначе несекьюрно — и начал играться. N>>А при многих таких нескольких — даже в пределах одного отдела — название ветки начинает играть роль собственно принципиального указания, от кого взято конкретное изменение, потому что понять это по содержанию уже невозможно. _>Так а зачем мне изменения другого отдела в чистом виде? ) Мне они не нужны. Мне нужна основная ветка развития, с применёнными к ней изменениями этого отдела (потому как кто кроме них правильнее осуществит слияние их изменений).
Тогда у неё будет постоянное имя. С другой стороны, представь себе вариант, когда все слияния делает менеджер (мы рассматривали такое как вариант, правда, на базе Gerrit, а не локальных репо).
N>>Безымянная ветка для этого становится случаем ничтожной экономии усилий на частный случай, когда таких источников считанные единицы, они не конфликтуют (до неразличения) по смыслу с любыми локальными изменениями (а программист ещё не устал и способен отличать источники по их виду), используемые средства явно показывают все эти головы и их не настолько много, чтобы не вмещались в интерфейс... возможно, ты и твоя команда способны всё это осиливать, но я предпочту тратить мысленные усилия на что-то более для меня полезное.
_>Какие мысленные усилия? ) Если предположим (для упрощения объяснения) в данной разработке не нужны долгоживущие отдельные ветки (которые по смыслу создаются, а не для синхронизации отдельных членов команды), то в Mercurial будет просто ровно одна ветка периодически разветвляющаяся (в моменты параллельной разработки членов команды) и тут же сливающаяся в одну.
_>А что будет в случае в Git? )
Здравствуйте, alex_public, Вы писали:
_>>>Эм, а какой смысл имеет последовательная группа ревизий с меткой "release"? ) Release — это же обычно некий фиксированный момент времени, а не интервал. Соответственно в репозитории это соответствует одной выделенной ревизии. Обычно её или помечают соответствующим тегом прямо в основной ветке или же создают отдельную ветку с именем release, в которую изредка (как раз в моменты времени релиза) сливают результаты из основной ветки. А то, что показал ты, я никогда не видел и пока не могу представить для чего оно может понадобиться. _>·>Да, смысла меток на ревизиях нет, поэтому подход hg и является не самым осмысленным. _>Какой ещё подход hg? ) Это же ты предлагаешь такую схему. )))
Прошу прощения, не так понял. Я подумал, что под меткой ты понимаешь отметку каждой ревизии именем бранча.
_>·>Ладно. Давай заменим "release" на "release_candidate", чтобы тебе понятнее было. Т.е. мы хотим знать какую ревизию мы сейчас тестируем более тяжелыми тестами (ручное или soak тестирование, например). _>Так, давай разберёмся подробно что же ты собственно хочешь. Эти метки должны изменяться со временем или нет? Метка должна быть на одной ревизии или на последовательном их наборе? Ветвление (реальное) требуется или нет? )
Да. Если кто-то что-то коммитит/мержит в development, метка "development" должна указывать на последние изменения. То же верно и для release.
_>·>А тегом помечаются конкретные номера публичных версий, и теги — read-only. _>Ну так это смотря где))) В Mercurial они вполне редактируемы. )
Мрак. Фтопку.
_>>>Нельзя) Но у тебя же там как раз последовательность фиксаций нарисована. ) _>·>Что за фиксации? Ревизии в смысле? Ревизия это коммит, т.е. патч+автор+етс. _>Что-то у тебя проблемы не только с пониманием документации Mercurial, но и вообще с переводом английского текста на русский. Commit — это действие (глагол), переводим как фиксация. А changeset — это объект (существительное), переводим как ревизия. Ну а слова "коммит" в русском языке нет и уж тем более в виде существительного (если уж и использовать подобный англицизм, то он должен быть глаголом).
Хз, я плохо разбираюсь в русской терминологии.
В документации git слово commit используется и как существительное. Например: "After you have created several commits, or if you have cloned a repository with an existing commit history".
_>·>Создание ветки это только в hg является коммитом, что опять фигня какая-то. _>Только наоборот. Фиксация ревизии порождает ветвление (при условие наличие у текущей ревизии другого потомка) и это абсолютно логично.
Разве можно создать именованный бранч без коммита в hg? Т.е. была у тебя ветка development, ты создаёшь на её основе release_branch — нужно делать коммит? Если да, появится ли diverging point?
_>>>Ну например по автору и по предку (в GUI по положения в дереве). _>·>"автор" не годится. Я могу продолжить твой эксперимент и накоммитить туда что-нибудь, и даже обратно тебе потом запушить. _>·>"предок" уж тем более не годится, т.к. мы можем начать свои эксперименты от одной и той же ревизии, скажем, последнего публичного релиза. _>Скорее всего так и будет. Но при этом в визуальном дереве всё будет чётко видно и отделено. )
Как я понимаю, это будут "две головы одной именованной ветки" и это видно, но т.к. головы анонимны, как их различать? "Хочу поработать над своим экспериментом, делаю git checkout experiment, хочу поработать над твоим, делаю git checkout alex_public_experiment". Что делать в hg?
_>>>Я так и не понял, зачем ты хочешь применять ветки там, где нет развилок? ) _>·>Не "нет развилок", а может не быть развилок. Даже hg это упоминает: "A new branch name can be started in the middle of a development line, not necessarily at a diverging point". Но начало именованного бранча это уже коммит, а поэтому история уже разъедется. Бардак жуткий. _>Я вообще то и не говорил, что это в Mercurial невозможно (более того, выше я упоминал, что это реализуется даже меньшим числом команд, чем в git). Я спрашиваю про другое — зачем может понадобится подобная бредовая конструкция? )
Это одно из основных применений веток — отмечать какие-то разные стадии разработки.
_>>>·>Или, иначе говоря, выразить тот факт, что мы зарелизили всё что надевелопили. _>>>Ну поставь на последнюю ревизию тег "release 2.0" и всё. Или же организуй отдельную ветку с релизами. Я уже писал выше. _>·>Теги для конкретных версий, а не для процесса релиза. _>Понятие "процесс релиза" в контексте систем контроля версий по прежнему остаётся для меня загадкой. )))
Не понял. В релиз выпускаются версии несколько другие, чем сейчас в разработке, а ещё есть багфиксы, релиз-кандидаты, бета-релизы, публичные, внутренние, етс. Это всё является частью процесса релиза. И это нужно как-то контролировать.
_>·>Ок, если не отличается, значит одно можно заменить на другое, смысл меняться не должен. Давай попробуем. Возьмём _>·>"Branches occur if lines of development diverge" _>·>заменяем _>·>"Branches occur if branches diverge" _>·>Теперь объясни смысл этого предложения. _>Ветвления происходят при разделение веток. )
Масло маслянное. Ты более менее формальное определение можешь сказать? И почему ты избегаешь ответа на "Плиз, на моём графе отметь все эти понятия"?
_>>>·>Бранч может иметь несколько их. В этом и путаница, которая требует новой сущности. В гите этот термин бессмысленен. _>>>Не может. ) Несколько голов может иметь виртуальная (потому как в реальности её не существует, а есть несколько веток с одинаковым атрибутом "имя") сущность называемая named branch. _>·>Почему тогда без этой виртуальной сущности hg, как ты говоришь, не сможет функционировать? _>Ээээ что? ) Я как раз наоборот всё время говорю, что mercurial можно удобно пользоваться вообще без затрагивания "имён для веток"/закладок/тегов, работая только с чистыми базовыми ветвлениями (естественно анонимными) на основе ревизий. Т.е. в основе лежит именно это, а поверх накручены дополнительные опциональные удобства (имена для веток/закладки/теги).
Я тогда не понимаю, почему ты не можешь сказать определение этих базового понятия?
Вот в git есть три основных понятия — snapshot, dag и reference. Всё. Остальное — накручено для удобства.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, netch80, Вы писали: N>* Якщо планується якась експериментальна гілка, яку планується назвати «experimental», дуже бажано подумати ще раз, чи вартує їй давати саме таке ім’я, оскільки навіть з hg commit —close-branch створити нову гілку із таким іменем більше не можна буде. Ніколи. Навіть через два роки.
Брешет. Я не спец в hg (использую для домашних проектов), в git так вообще ноль, поэтому в дискуссию не лезу, но то что он описывает, я проделывал раз сто.
Здравствуйте, alexzz, Вы писали:
A>Здравствуйте, netch80, Вы писали:
N>>* Якщо планується якась експериментальна гілка, яку планується назвати «experimental», дуже бажано подумати ще раз, чи вартує їй давати саме таке ім’я, оскільки навіть з hg commit —close-branch створити нову гілку із таким іменем більше не можна буде. Ніколи. Навіть через два роки. A>Брешет. Я не спец в hg (использую для домашних проектов), в git так вообще ноль, поэтому в дискуссию не лезу, но то что он описывает, я проделывал раз сто.
Я склонен верить обеим сторонам Тогда остаётся понять, в чём же разница в условиях.
Здравствуйте, netch80, Вы писали:
N>Я склонен верить обеим сторонам Тогда остаётся понять, в чём же разница в условиях.
Сам попробуй. Проверил как мог:
Здравствуйте, alexzz, Вы писали:
A>Здравствуйте, netch80, Вы писали:
N>>Я склонен верить обеим сторонам Тогда остаётся понять, в чём же разница в условиях. A>Сам попробуй. Проверил как мог:
Видел. Не хочу. Всё равно я эту чушь с "permanent branches" не буду использовать, разве что начальство скажет, но это тогда их проблема научить отсутствию конфликтов Пока что вокруг меня Git и нет тенденции этому меняться. Так что среди всех описанных проблем это чуть ли не наименее важная.
Здравствуйте, ·, Вы писали:
·>Как я понимаю, это будут "две головы одной именованной ветки" и это видно, но т.к. головы анонимны, как их различать? "Хочу поработать над своим экспериментом, делаю git checkout experiment, хочу поработать над твоим, делаю git checkout alex_public_experiment". Что делать в hg?
Вот три анонимные ветви. Одна, допустим, твоя, а две другие прилетели от других пользователей. Не понимаю проблему.
N>Всё равно я эту чушь с "permanent branches" не буду использовать,
Если имеется в виду, что после слияния ветки, например, experimental с default команда hg branches продолжает показывать оба названия, то закрываешь experimental, если пока больше не нужна, и она перестаёт отсвечивать в списке. Закрытие, по-моему, ни на что больше не влияет и никаких ограничений не накладывает.
Здравствуйте, alexzz, Вы писали:
A>·>Как я понимаю, это будут "две головы одной именованной ветки" и это видно, но т.к. головы анонимны, как их различать? "Хочу поработать над своим экспериментом, делаю git checkout experiment, хочу поработать над твоим, делаю git checkout alex_public_experiment". Что делать в hg? A>Вот три анонимные ветви. Одна, допустим, твоя, а две другие прилетели от других пользователей. Не понимаю проблему. A>Image: hg3.png
Проблема — различить эти анонимные ветки: что от кого прилетело, как узнать на какую из них переключится, как что-то там поменять и запушить обратно, туда, откуда прилетело.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, netch80, Вы писали:
_>>Не, команды по определению имеющие дело с одной ревизией только их и принимают (а не имена ссылок/закладки/теги и т.п.). N>А зачем тогда эти ярлыки используются? Только для чтения истории "под какой ярлык была эта ревизия"? Из пушки по воробьям.
Так есть же множество команд работающих с наборами ревизий) Там и push/pull/bundle/clone и incoming/outgoing и log и т.д. и т.п.
_>>Так а зачем мне изменения другого отдела в чистом виде? ) Мне они не нужны. Мне нужна основная ветка развития, с применёнными к ней изменениями этого отдела (потому как кто кроме них правильнее осуществит слияние их изменений). N>Тогда у неё будет постоянное имя. С другой стороны, представь себе вариант, когда все слияния делает менеджер (мы рассматривали такое как вариант, правда, на базе Gerrit, а не локальных репо).
Т.е. чтобы сделать аналог простейшего режима работы в Mercurial вообще без именованных веток в Git надо завести в каждом репозитории минимум 2 ветки (одну общую для синхронизации и слияний и одну для локальной разработки), правильно? )
_>>Какие мысленные усилия? ) Если предположим (для упрощения объяснения) в данной разработке не нужны долгоживущие отдельные ветки (которые по смыслу создаются, а не для синхронизации отдельных членов команды), то в Mercurial будет просто ровно одна ветка периодически разветвляющаяся (в моменты параллельной разработки членов команды) и тут же сливающаяся в одну. _>>А что будет в случае в Git? ) N>То же самое.
Ну покажи пример такого графа. )
P.S. Кстати, тут что-то вспомнилось... А что у git с аналогами команд hg copy/rename/remove? ) Помнится он там что-то автоматическое пытался делать, но чаще всего криво... )))
Здравствуйте, ·, Вы писали:
A>>Вот три анонимные ветви. Одна, допустим, твоя, а две другие прилетели от других пользователей. Не понимаю проблему. A>>Image: hg3.png ·>Проблема — различить эти анонимные ветки: что от кого прилетело, как узнать на какую из них переключится, как что-то там поменять и запушить обратно, туда, откуда прилетело.
У каждого коммита написано, кто его автор. Прилетело оттуда, откуда сделал к себе pull. Туда же и пушить.
Репозиторий Маши:
0 — установочный коммит
1 — Маша сделала pull, закоммитила, сделала push
2 — Маша закоммитила ещё и снова сделала push.
Потом она решила посмотреть, как там дела у остальных и сделала pull. Увидела, что Петя тоже кое-что закоммитил:
3 — Изменения, пришедшие от Пети
4 — Маша решила Пете помочь, сделала изменения в его ветке, закоммитила, запушила.
5 — Потом Маша вернулась к своей задаче, вечером закоммитила в свою ветку, сделала push и ушла домой.
Репозиторий Пети:
0 — установочный коммит
1 — Петя сделал pull и увидел коммит от Маши.
2 — Взяв его за основу, Петя кое-то добавил, закоммитил, сделал push и пошёл пить чай до вечера.
3 — Вернувшить, Петя закоммитил ещё и решил посмотреть, что Маша успела наделать за день — pull.
4
5 — Петя увидел, что Маша внесла некоторые изменения в Петину фичу
6
7 — Петя влил Машины изменения к себе, закоммитил, запушил и тоже пошёл домой.
Центральный репозиторий на bitbucket.org, с которым Маша с Петей синхронизируются, выглядит теперь как-то так:
Маша и Петя спокойно обошлись без именованных веток, без bookmarks, без тэгов, вообще без всего.
Здравствуйте, ·, Вы писали:
_>>·>Да, смысла меток на ревизиях нет, поэтому подход hg и является не самым осмысленным. _>>Какой ещё подход hg? ) Это же ты предлагаешь такую схему. ))) ·>Прошу прощения, не так понял. Я подумал, что под меткой ты понимаешь отметку каждой ревизии именем бранча.
Я на самом деле просто не понял твою задачу и соответственно не мог сказать какой именно из сервисных инструментов (работающих поверх базовой функциональности анонимных веток) mercurial надо использовать в твоём случае:
1. имя ветки — неизменяемый атрибут (т.е. применим ко многим ревизиям) ревизии с особым свойством (автоматически наследуется потомками, если пользователем не указано иного при фиксации)
2. закладка — указатель (т.е. применим только к одной ревизии) с особым свойством (автоматически перескакивает на следующую ревизию при фиксации)
3. тег — указатель, свободно меняемый пользователем
_>>Так, давай разберёмся подробно что же ты собственно хочешь. Эти метки должны изменяться со временем или нет? Метка должна быть на одной ревизии или на последовательном их наборе? Ветвление (реальное) требуется или нет? ) ·>Да. Если кто-то что-то коммитит/мержит в development, метка "development" должна указывать на последние изменения. То же верно и для release.
Ну так значит под случай похоже оптимальнее всего подходят закладки из mercurial.
_>>·>А тегом помечаются конкретные номера публичных версий, и теги — read-only. _>>Ну так это смотря где))) В Mercurial они вполне редактируемы. ) ·>Мрак. Фтопку.
Ммм, завидно? )))
_>>Что-то у тебя проблемы не только с пониманием документации Mercurial, но и вообще с переводом английского текста на русский. Commit — это действие (глагол), переводим как фиксация. А changeset — это объект (существительное), переводим как ревизия. Ну а слова "коммит" в русском языке нет и уж тем более в виде существительного (если уж и использовать подобный англицизм, то он должен быть глаголом). ·>Хз, я плохо разбираюсь в русской терминологии. ·>В документации git слово commit используется и как существительное. Например: "After you have created several commits, or if you have cloned a repository with an existing commit history".
Ну собственно "фиксация" — это и есть существительное. ) Это я выше некорректно написал (там было правильнее написать "фиксировать"). Только его значение является совсем не синонимом слову ревизия, а обозначает событие. )
_>>Только наоборот. Фиксация ревизии порождает ветвление (при условие наличие у текущей ревизии другого потомка) и это абсолютно логично. ·>Разве можно создать именованный бранч без коммита в hg? Т.е. была у тебя ветка development, ты создаёшь на её основе release_branch — нужно делать коммит? Если да, появится ли diverging point?
Нельзя) Нет, ветвления не появится пока не породишь ещё одного потомка из этой точки (не важно с каким именем). А пока у тебя вышло просто переименование одной и той же ветки. )
_>>Скорее всего так и будет. Но при этом в визуальном дереве всё будет чётко видно и отделено. ) ·>Как я понимаю, это будут "две головы одной именованной ветки" и это видно, но т.к. головы анонимны, как их различать? "Хочу поработать над своим экспериментом, делаю git checkout experiment, хочу поработать над твоим, делаю git checkout alex_public_experiment". Что делать в hg?
Так в Mercurial checkout (он же update) работает с именем ревизии и это является как раз привычным путём в любом случае. Правда туда можно передавать различные "хоткеи" (именованные ветки — тогда подразумевается их tip, закладки, теги), но это уже добавлено поверх, для удобства.
_>>Я вообще то и не говорил, что это в Mercurial невозможно (более того, выше я упоминал, что это реализуется даже меньшим числом команд, чем в git). Я спрашиваю про другое — зачем может понадобится подобная бредовая конструкция? ) ·>Это одно из основных применений веток — отмечать какие-то разные стадии разработки.
Первый раз про такое слышу. Использовать ветки для ситуации без ветвления. Это похоже только от убогости других инструментов git'a.
_>>Понятие "процесс релиза" в контексте систем контроля версий по прежнему остаётся для меня загадкой. ))) ·>Не понял. В релиз выпускаются версии несколько другие, чем сейчас в разработке, а ещё есть багфиксы, релиз-кандидаты, бета-релизы, публичные, внутренние, етс. Это всё является частью процесса релиза. И это нужно как-то контролировать.
Вот всё, что ты перечислил, можно применить к какой-то отдельной ревизии (соответственно для этого оптимальные теги). А вот куда применить понятие "процесс релиза" не ясно. )
_>>·>Теперь объясни смысл этого предложения. _>>Ветвления происходят при разделение веток. ) ·>Масло маслянное. Ты более менее формальное определение можешь сказать? И почему ты избегаешь ответа на "Плиз, на моём графе отметь все эти понятия"?
Формальное определение я тебе показывал не раз и даже цитировал пару сообщений назад. ) По поводу твоего графа я не понял что собственно на нём нарисовано. Там есть последовательность ревизий без ветвлений (это понятно). И пара каких-то меток, причём в одной точке (что это собственно не понятно, по идее похоже на теги или закладки, раз применены к одной ревизии).
_>>Ээээ что? ) Я как раз наоборот всё время говорю, что mercurial можно удобно пользоваться вообще без затрагивания "имён для веток"/закладок/тегов, работая только с чистыми базовыми ветвлениями (естественно анонимными) на основе ревизий. Т.е. в основе лежит именно это, а поверх накручены дополнительные опциональные удобства (имена для веток/закладки/теги). ·>Я тогда не понимаю, почему ты не можешь сказать определение этих базового понятия? ·>Вот в git есть три основных понятия — snapshot, dag и reference. Всё. Остальное — накручено для удобства.
А вообще, если кратко, то главной сущностью является граф ревизий (changeset'ов, у каждого уникальный id), связанный отношениями потомок/предок. И собственно всё. В Git на самом деле внутри тоже самое. Единственная разница в том, что в Git нет адекватных инструментов для удобной работы с этим базисом — требуется введение дополнительных сущностей более высокого уровня (типа указателей на ветки, специальных команд для ветвления и т.п.). А в Mercurial есть удобные инструменты для работы на этом уровне и соответственно это и является основным режимом работы, а всякие там дополнительные удобства (имена веток, закладки, теги) являются лишь опциональной надстройкой над этим.
Здравствуйте, alexzz, Вы писали:
A>>>Вот три анонимные ветви. Одна, допустим, твоя, а две другие прилетели от других пользователей. Не понимаю проблему. A>>>Image: hg3.png A>·>Проблема — различить эти анонимные ветки: что от кого прилетело, как узнать на какую из них переключится, как что-то там поменять и запушить обратно, туда, откуда прилетело. A>У каждого коммита написано, кто его автор. Прилетело оттуда, откуда сделал к себе pull. Туда же и пушить.
Автор может быть один и тот же. Представь один репо на моём ноуте, второй — на моём десктопе. Т.е. по автору отличить можно далеко не всегда.
A>Репозиторий Маши: A>Image: hg4.PNG
Даже в случае разных авторов — в этом репозитории уже сложно отличить ревизии 4 и 5 — оба имеют автором Машу, нужно смотреть историю глубже, разбираться с коммит-сообщениями... а в общем случае, когда Маша и Петя меняют что попало где попало — в каждой из голов может быть полная мешанина авторов. Т.е. автор это не точное отличие, а империческое — обычно работает, но иногда подводит.
A>Маша и Петя спокойно обошлись без именованных веток, без bookmarks, без тэгов, вообще без всего.
Собственно в git будет та же история, но не будет путаницы. Т.к. при совпадении имён веток, Маша может вытянуть ветку Пети под другим именем, скажем, назвать её в своём репозитории как petya_dev. По смыслу — ветки dev у Пети и у Маши — независимые истории. Почему их нужно насильно сталкивать лишь по тому, что у них случайно совпали имена — хз.
Ну и ещё отличие — графы истории во всех репозиториях будут выглядеть эквивалентно, не будет путаницы с совпадающими номерами ревизий.
A>5 — Петя увидел, что Маша внесла некоторые изменения в Петину фичу A>6 A>7 — Петя влил Машины изменения к себе, закоммитил, запушил и тоже пошёл домой.
Кстати, интересно. Как Петя может посмотреть Машины изменения перед вливанием? Я правильно понимаю, что у него уже будет три безымянные головы?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
A>>Маша и Петя спокойно обошлись без именованных веток, без bookmarks, без тэгов, вообще без всего. ·>Собственно в git будет та же история, но не будет путаницы. Т.к. при совпадении имён веток, Маша может вытянуть ветку Пети под другим именем, скажем, назвать её в своём репозитории как petya_dev. По смыслу — ветки dev у Пети и у Маши — независимые истории.
Если Маша и Петя станут путаться, они могут начать использовать и локальные закладки, и синхронизируемые закладки, и именованные ветки. Например, в самом простом варианте, Маша может пометить локальной закладкой свою головную ревизию и легко отличать её от всех остальных головных ревизий, если таковые возникнут; а Петя может ничего не делать, если его всё устраивает. Или они могут каждый сделать себе по закладке и сказать синхронизировать их между репозиториями. Могут под свои задачи именованные ветки завести, если захотят или потребуется зачем-то.
·> Почему их нужно насильно сталкивать лишь по тому, что у них случайно совпали имена — хз.
Я думаю, слово "нужно" неверно. Устраивает базовый функционал анонимных веток? Пользуешься им. Испытываешь неудобства? Можешь использовать закладки и/или именованные ветки.
A>>5 — Петя увидел, что Маша внесла некоторые изменения в Петину фичу A>>6 A>>7 — Петя влил Машины изменения к себе, закоммитил, запушил и тоже пошёл домой. ·>Кстати, интересно. Как Петя может посмотреть Машины изменения перед вливанием? Я правильно понимаю, что у него уже будет три безымянные головы?
Я слово «влил» использовал не подумав, имея в виду merge Петей изменений, которые Маша сделала в Петину ветку. В результате не очень понимаю, о чём ты спрашиваешь. После того как Петя пришёл вечером, сделал коммит и выполнил pull, он действительно увидит три головные ревизии. Одна Машина, другая Петина, третья тоже Петина, но созданная Машей. Как он поймёт, что Маша что-то сделала в его ветке?
Если использовать только неименованные ветки, то просто увидит, что из одной из ревизий, над которыми он работал, выросла новая голова.
Если он знает, что ему так будет неудобно, он может озаботиться, например, использованием синхронизируемых закладок. Тогда он тоже увидит три головные ревизии, но они будут подписаны:
1. Petya's stuff — последняя ревизия, над которой работал Петя.
2. Petya's stuff@default — нечто, некогда отпочковавшееся от Петиной ветки и вернувшееся обратно со стороны, из удалённого репозитория, с которым Петя синхронизировался, и который у него в настройках назван default. Это локальная закладка, видимая только Пете. Он может её оставить, переименовать или удалить, если хочет.
3. Головная ревизия без закладки — от ветки, которую ведёт Маша. Она знает, что Петя к ней не полезет и не стала делать закладку для своей ветки. (На самом деле мне лень редактировать репозитории).
После слияния двух Петиных веток, коммита и пуша финальный результат выглядит так:
Репозиторий Маши (она ушла раньше, и у неё не хватает последних изменений):
Здравствуйте, alex_public, Вы писали:
_>>>Так, давай разберёмся подробно что же ты собственно хочешь. Эти метки должны изменяться со временем или нет? Метка должна быть на одной ревизии или на последовательном их наборе? Ветвление (реальное) требуется или нет? ) _>·>Да. Если кто-то что-то коммитит/мержит в development, метка "development" должна указывать на последние изменения. То же верно и для release. _>Ну так значит под случай похоже оптимальнее всего подходят закладки из mercurial.
Собственно да, букмарки и создавались по образу и подобию веток гита. Но проблемы с ними есть. Скажем, управлять нельзя как они пуллятся. И опять — глобальные имена "Be aware that there is only one namespace for bookmarks — it is advised to prefix your local-only bookmarks to avoid conflicts with other users."
И т.к. это опциональная фича с боку... как они поддерживаются другими тулзами? CI сервера, IDE, и т.п.?
_>>>·>А тегом помечаются конкретные номера публичных версий, и теги — read-only. _>>>Ну так это смотря где))) В Mercurial они вполне редактируемы. ) _>·>Мрак. Фтопку. _>Ммм, завидно? )))
В git их тоже можно редактировать (ибо это принципиально невозможно запретить в распределённой системе), но git при этом громко орёт и матерится: "Ты чЁ?! С дубу рухнул?! Справку от психиатра предъяви, ламьё!!!".
_>·>Хз, я плохо разбираюсь в русской терминологии. _>·>В документации git слово commit используется и как существительное. Например: "After you have created several commits, or if you have cloned a repository with an existing commit history". _>Ну собственно "фиксация" — это и есть существительное. ) Это я выше некорректно написал (там было правильнее написать "фиксировать"). Только его значение является совсем не синонимом слову ревизия, а обозначает событие. )
Брр. Бардак, ибо lingvo говорит, что commit это глагол только.
_>>>Только наоборот. Фиксация ревизии порождает ветвление (при условие наличие у текущей ревизии другого потомка) и это абсолютно логично. _>·>Разве можно создать именованный бранч без коммита в hg? Т.е. была у тебя ветка development, ты создаёшь на её основе release_branch — нужно делать коммит? Если да, появится ли diverging point? _>Нельзя) Нет, ветвления не появится пока не породишь ещё одного потомка из этой точки (не важно с каким именем). А пока у тебя вышло просто переименование одной и той же ветки. )
Будет ревизия, с новым уникальным id, так ведь? Значит уже история пошла врозь.
И что сбивает с толку, есть коммит, с датой, с автором... но никаких изменений, diff пустой!
_>>>Скорее всего так и будет. Но при этом в визуальном дереве всё будет чётко видно и отделено. ) _>·>Как я понимаю, это будут "две головы одной именованной ветки" и это видно, но т.к. головы анонимны, как их различать? "Хочу поработать над своим экспериментом, делаю git checkout experiment, хочу поработать над твоим, делаю git checkout alex_public_experiment". Что делать в hg? _>Так в Mercurial checkout (он же update) работает с именем ревизии и это является как раз привычным путём в любом случае. Правда туда можно передавать различные "хоткеи" (именованные ветки — тогда подразумевается их tip, закладки, теги), но это уже добавлено поверх, для удобства.
В git тоже, всё так же. Правда работать с номерами ревизий — не гуманно, git освобождает от этой необходимости когда возможно. Все эти ветки, теги, символические ссылки и т.п. — чисто для удобства человеков, сам гит может обходиться исключительно sha1 (и это удобно, особенно когда пишешь какую-нибудь автоматизацию/скрипты/славароботам).
_>>>Я вообще то и не говорил, что это в Mercurial невозможно (более того, выше я упоминал, что это реализуется даже меньшим числом команд, чем в git). Я спрашиваю про другое — зачем может понадобится подобная бредовая конструкция? ) _>·>Это одно из основных применений веток — отмечать какие-то разные стадии разработки. _>Первый раз про такое слышу. Использовать ветки для ситуации без ветвления. Это похоже только от убогости других инструментов git'a.
Ещё раз. Оно расходится _может_, но не обязательно что _будет_. Скажем, если мы зарелизили что-то и оно всё сразу суперски заработало с первого раза — релиз будет в точности равен тому что надевелопилось. А если мы сделали поверх релиза хотфикс(ы) — ветки разойдутся.
_>>>Понятие "процесс релиза" в контексте систем контроля версий по прежнему остаётся для меня загадкой. ))) _>·>Не понял. В релиз выпускаются версии несколько другие, чем сейчас в разработке, а ещё есть багфиксы, релиз-кандидаты, бета-релизы, публичные, внутренние, етс. Это всё является частью процесса релиза. И это нужно как-то контролировать. _>Вот всё, что ты перечислил, можно применить к какой-то отдельной ревизии (соответственно для этого оптимальные теги). А вот куда применить понятие "процесс релиза" не ясно. )
Эээ. Если эти теги работают так же (можно, например, туда хотфикс закоммитиь) и мержить туды-сюды... то наверное сгодятся.
Т.е. я пушу что-нибудь в "release", это подхватывает CI-сервер, билдит, запускает тесты, шлёт имейлы, строит release notes, etc...
_>>>·>Теперь объясни смысл этого предложения. _>>>Ветвления происходят при разделение веток. ) _>·>Масло маслянное. Ты более менее формальное определение можешь сказать? И почему ты избегаешь ответа на "Плиз, на моём графе отметь все эти понятия"? _>Формальное определение я тебе показывал не раз и даже цитировал пару сообщений назад. ) По поводу твоего графа я не понял что собственно на нём нарисовано. Там есть последовательность ревизий без ветвлений (это понятно). И пара каких-то меток, причём в одной точке (что это собственно не понятно, по идее похоже на теги или закладки, раз применены к одной ревизии).
Пусть другой граф, пороще, с расхождением, мержем и одной веткой:
_>>>Ээээ что? ) Я как раз наоборот всё время говорю, что mercurial можно удобно пользоваться вообще без затрагивания "имён для веток"/закладок/тегов, работая только с чистыми базовыми ветвлениями (естественно анонимными) на основе ревизий. Т.е. в основе лежит именно это, а поверх накручены дополнительные опциональные удобства (имена для веток/закладки/теги). _>·>Я тогда не понимаю, почему ты не можешь сказать определение этих базового понятия? _>·>Вот в git есть три основных понятия — snapshot, dag и reference. Всё. Остальное — накручено для удобства. _>Вообще то я уже показывал все определения и ссылками и цитатами. Ну можешь глянуть ещё здесь https://www.mercurial-scm.org/wiki/UnderstandingMercurial — подробное объяснение с примерами. _>А вообще, если кратко, то главной сущностью является граф ревизий (changeset'ов, у каждого уникальный id), связанный отношениями потомок/предок. И собственно всё. В Git на самом деле внутри тоже самое.
dag т.е.
_>Единственная разница в том, что в Git нет адекватных инструментов для удобной работы с этим базисом — требуется введение дополнительных сущностей более высокого уровня (типа указателей на ветки, специальных команд для ветвления и т.п.).
Что ещё за указатели на ветки? Есть просто reference (ссылка) и всё. Сссылка с префиксом refs/heads/ является веткой, с префиксом refs/tags/ — тегом, с префиксом refs/remotes/ — ссылки из чужих репо, и т.п. Там же и stash, там же и notes и кастомные вещи, типа pull requests гитхаба.
Команды какие ещё? update-ref только, остальные (branch, tag, notes) просто надстройки — для удобства человеков только.
_>А в Mercurial есть удобные инструменты для работы на этом уровне и соответственно это и является основным режимом работы, а всякие там дополнительные удобства (имена веток, закладки, теги) являются лишь опциональной надстройкой над этим.
И все эти штуки — совершенно разные сущности.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, alexzz, Вы писали:
A>>>Маша и Петя спокойно обошлись без именованных веток, без bookmarks, без тэгов, вообще без всего. A>·>Собственно в git будет та же история, но не будет путаницы. Т.к. при совпадении имён веток, Маша может вытянуть ветку Пети под другим именем, скажем, назвать её в своём репозитории как petya_dev. По смыслу — ветки dev у Пети и у Маши — независимые истории.
A>Если Маша и Петя станут путаться, они могут начать использовать и локальные закладки, и синхронизируемые закладки, и именованные ветки. Например, в самом простом варианте, Маша может пометить локальной закладкой свою головную ревизию и легко отличать её от всех остальных головных ревизий, если таковые возникнут; а Петя может ничего не делать, если его всё устраивает.
Как локальная закладка будет отслеживать голову именованной ветки? Никак.
A>Или они могут каждый сделать себе по закладке и сказать синхронизировать их между репозиториями.
Не могут. Проблема ровно та же: "Be aware that there is only one namespace for bookmarks — it is advised to prefix your local-only bookmarks to avoid conflicts with other users. "
A>Могут под свои задачи именованные ветки завести, если захотят или потребуется зачем-то.
Ветки же уже заведены — с именем "experiment". Надо будет кому-то из них ветку переименовывать, переписывая историю. А от этой истории уже могут другие зависимости существовать...
A>·> Почему их нужно насильно сталкивать лишь по тому, что у них случайно совпали имена — хз. A>Я думаю, слово "нужно" неверно. Устраивает базовый функционал анонимных веток? Пользуешься им. Испытываешь неудобства? Можешь использовать закладки и/или именованные ветки.
Как выяснилось выше — не могу, проблему они не решают.
A>>>5 — Петя увидел, что Маша внесла некоторые изменения в Петину фичу A>>>6 A>>>7 — Петя влил Машины изменения к себе, закоммитил, запушил и тоже пошёл домой. A>·>Кстати, интересно. Как Петя может посмотреть Машины изменения перед вливанием? Я правильно понимаю, что у него уже будет три безымянные головы? A>Я слово «влил» использовал не подумав, имея в виду merge Петей изменений, которые Маша сделала в Петину ветку. В результате не очень понимаю, о чём ты спрашиваешь. После того как Петя пришёл вечером, сделал коммит и выполнил pull, он действительно увидит три головные ревизии. Одна Машина, другая Петина, третья тоже Петина, но созданная Машей. Как он поймёт, что Маша что-то сделала в его ветке?
Вот. Уже внезапно стало три анонимные ветки, различать их стало ещё сложнее.
A>Если использовать только неименованные ветки, то просто увидит, что из одной из ревизий, над которыми он работал, выросла новая голова.
A>Если он знает, что ему так будет неудобно, он может озаботиться, например, использованием синхронизируемых закладок. Тогда он тоже увидит три головные ревизии, но они будут подписаны:
Та же проблема, имена закладок глобальны, да ещё и пушатся без спросу — думай тщательно каждый раз когда даёшь название.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Собственно да, букмарки и создавались по образу и подобию веток гита. Но проблемы с ними есть. Скажем, управлять нельзя как они пуллятся. И опять — глобальные имена "Be aware that there is only one namespace for bookmarks — it is advised to prefix your local-only bookmarks to avoid conflicts with other users." ·>И т.к. это опциональная фича с боку... как они поддерживаются другими тулзами? CI сервера, IDE, и т.п.?
Зато применяются по делу, в отличие от git.
Смотри, в mercurial и именновые ветки и закладки (выбираешь в зависимости от своего вкуса) применяются исключительно для выделения долгоживующих сущностей. Т.е. если у тебя реально в репозитории намечаются две принципиально разные ветки (скорее всего созданные в самом начале истории), то надо применять что-то из этой области. Если же у тебя реально только одна ветка, которая периодически разделяется и сливается из-за синхронизации работы команды, то выделенные именные сущности просто не нужны.
В Git же приходится применять ветки не только для реальных выделенных сущностей, но но и для обслуживания ситуации синхронизации параллельной разработки в одной (смысловой) ветке.
_>>Ну собственно "фиксация" — это и есть существительное. ) Это я выше некорректно написал (там было правильнее написать "фиксировать"). Только его значение является совсем не синонимом слову ревизия, а обозначает событие. ) ·>Брр. Бардак, ибо lingvo говорит, что commit это глагол только.
Нуу такие вещи лучше тут смотреть: http://www.multitran.ru/c/m.exe?a=110&t=858983_1_2&sc=138
_>>Нельзя) Нет, ветвления не появится пока не породишь ещё одного потомка из этой точки (не важно с каким именем). А пока у тебя вышло просто переименование одной и той же ветки. ) ·>Будет ревизия, с новым уникальным id, так ведь? Значит уже история пошла врозь. ·>И что сбивает с толку, есть коммит, с датой, с автором... но никаких изменений, diff пустой!
Ммм, я что-то не понял. Вот смотри, у нас идёт цепочка ревизий, в которой используется некое имя ветки (Х). Потом мы с какого-то момента решили продолжать эту цепочку под новым именем (Y). Мы сообщаем об этом mercurial (командой branch, которая по сути ничего не делает в самом хранилище) и следующие ревизии в цепочке будет носить уже новое имя Y. При этом никаких реальных развилок не наблюдается — они появятся только если вернуться назад и добавить новых потомков (не важно под каким именем ветки) к точке развилки.
Ну и да, это бредовый способ использования именованных веток (т.к. собственно ветвления тут нет) и его никто не использует. Но если очень хочется (я правда так и не понял зачем оно тебе такое было надо), то технически возможно.
_>>Так в Mercurial checkout (он же update) работает с именем ревизии и это является как раз привычным путём в любом случае. Правда туда можно передавать различные "хоткеи" (именованные ветки — тогда подразумевается их tip, закладки, теги), но это уже добавлено поверх, для удобства. ·>В git тоже, всё так же. Правда работать с номерами ревизий — не гуманно, git освобождает от этой необходимости когда возможно. Все эти ветки, теги, символические ссылки и т.п. — чисто для удобства человеков, сам гит может обходиться исключительно sha1 (и это удобно, особенно когда пишешь какую-нибудь автоматизацию/скрипты/славароботам).
В том то и дело, что не так же. Нет в git нормальной работы на уровне чистых ревизий. Вот к примеру как мне узнать список всех "голов" в хранилище? Я уже молчу про то, что git-gc может самовольно удалять подобные данные. Нет, в git нельзя нормально работать без именованных веток, хотя внутри у него в базисе такая же основа как и у mercurial. Но не смогли...
_>>Первый раз про такое слышу. Использовать ветки для ситуации без ветвления. Это похоже только от убогости других инструментов git'a. ·>Ещё раз. Оно расходится _может_, но не обязательно что _будет_. Скажем, если мы зарелизили что-то и оно всё сразу суперски заработало с первого раза — релиз будет в точности равен тому что надевелопилось. А если мы сделали поверх релиза хотфикс(ы) — ветки разойдутся.
Ну и пускай расходятся просто так — в mercurial всё равно же не обязательны именованные ветки/закладки для этого. Собственно ситуация кратковременного ответвления идеальна для реализации через анонимные ветки.
А вот реальные именованные ветки/закладки есть смысл использовать при наличие логически выделенных веток разработки, а не для синхронизации работы или установки каких-то меток (для этого есть теги).
_>>Вот всё, что ты перечислил, можно применить к какой-то отдельной ревизии (соответственно для этого оптимальные теги). А вот куда применить понятие "процесс релиза" не ясно. ) ·>Эээ. Если эти теги работают так же (можно, например, туда хотфикс закоммитиь) и мержить туды-сюды... то наверное сгодятся. ·>Т.е. я пушу что-нибудь в "release", это подхватывает CI-сервер, билдит, запускает тесты, шлёт имейлы, строит release notes, etc...
Практически все главные команды mercurial работают с понятием "ревизия" (а не ветка/закладка/тег и т.п.). В качестве идентификатора ревизии можно передавать:
— её уникальный id (хеш)
— её локальный id (порядковый номер)
— имя ветки (тогда подразумевается ревизия с тегом tip в этой ветке)
— имя закладки (прямой указатель на некую ревизию)
— имя тега (прямой указатель на некую ревизию)
Так что всё работает везде одинаково)
·>Пусть другой граф, пороще, с расхождением, мержем и одной веткой: ·>
Ну так ты поясни что это. Я вот вижу некую ветку, которая разделяется и потом сливается. Это понятно и нормально. Потом я вижу некую метку "development" на последней ревизии ветки. Что она у тебя должна означать? )
_>>Единственная разница в том, что в Git нет адекватных инструментов для удобной работы с этим базисом — требуется введение дополнительных сущностей более высокого уровня (типа указателей на ветки, специальных команд для ветвления и т.п.). ·>Что ещё за указатели на ветки? Есть просто reference (ссылка) и всё. Сссылка с префиксом refs/heads/ является веткой, с префиксом refs/tags/ — тегом, с префиксом refs/remotes/ — ссылки из чужих репо, и т.п. Там же и stash, там же и notes и кастомные вещи, типа pull requests гитхаба. ·>Команды какие ещё? update-ref только, остальные (branch, tag, notes) просто надстройки — для удобства человеков только.
ОК, а если у нас репозитории ревизия на которую нет ссылок через ветки/теги, то как нам с ней работать? )
Здравствуйте, netch80, Вы писали:
N>Не терялась. Но и не сохранялась. История подобного рода может только создаваться в процессе чтения истории изменений. На уровне коммита есть только новое состояние двух объектов — исходных файлов. Само понимание того, что произошёл перенос кода, возникает на основании сравнения объектов — источников и объектов — приёмников и определяется долей неизменённого кода при этом переносе (точной границы не помню, навскидку это около 70%).
N>Да, я тоже хотел бы, как в darcs, алгебру изменений с возможностью логически определять каждое из них в стиле "переименование", "перенос", "форматирование" и т.п. — это очень облегчает мержинг. Но реально это не выжило ни в одной из современных массово используемых DVCS.
N>Сколько при этом меняется внутри того файла? Если, например, в среднем одна строчка из 10, в истории будет факт переименования с указанием типа "91% similarity".
ну вот реальный пример из последних.
дано: большой класс (файл).
хочу: сделать его parital (разбить на два файла), соответственно "половина" функционал пойдет в один файл, половина в другой. оба имени файла отличные от оригинального, название класса тоже изменилось, попутно что-то пофиксилось.
что скажет история git про эти два новых файла? как они будут связаны с оригиналом?
Здравствуйте, AK107, Вы писали:
AK>ну вот реальный пример из последних.
AK>дано: большой класс (файл). AK>хочу: сделать его parital (разбить на два файла), соответственно "половина" функционал пойдет в один файл, половина в другой. оба имени файла отличные от оригинального, название класса тоже изменилось, попутно что-то пофиксилось.
AK>что скажет история git про эти два новых файла? как они будут связаны с оригиналом?
git пытается восстановить происшедшее, сравнивая содержимое файлов. Скажем, git blame -C сможет показать строчки в новых файлах как переехавшие из старого.
Этот процесс основан на нечётких сравнениях строчек. Поэтому, желательно такие громадные изменения делать серией мелких коммитов — это будет проще отследить не только гиту, но и человеку делающему ревью, и тебе самому пол года спустя.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Как локальная закладка будет отслеживать голову именованной ветки? Никак.
Не понял. Задача локальной закладки, которую я устанавливаю в своём репозитории, — показывать мне место, на котором я остановился. Если кто-то закоммитит в мою ветку, закладка продолжит показывать мне ревизию, на которой остановился именно я.
Петя поставил локальную закладку, сделал коммит, пуш, и ушел домой. Маша посмотрела на это дело, внесла исправление, закомимтила, запушила и ушла домой. Петя утром пришёл, сделал pull, увидел место, на котором он остановился вчера, и ещё увидел, что Маша кое-что добавила:
Петя просмотрел Машины изменения, ему они понравились. Он передвинул закладку на Машину ревизию и продолжил работу с неё:
Или не понравились. "Что за фигня?" — подумал Петя и продолжил работу с того места, на котором остановился в прошлый раз.
A>>Или они могут каждый сделать себе по закладке и сказать синхронизировать их между репозиториями. ·>Не могут. Проблема ровно та же: "Be aware that there is only one namespace for bookmarks — it is advised to prefix your local-only bookmarks to avoid conflicts with other users. "
Допустим, у Маши с Петей отсутствует фантазия. Маша закоммитила, поставила синхронизируемую закладку, запушила. Петя закоммитил у себя и поставил закладку с таким же именем. Попробовал её синхронизировать, но оказалось, что закладка с таким именем уже есть. Петя переименовал свою закладку, и они жили долго и счастливо.
A>>Могут под свои задачи именованные ветки завести, если захотят или потребуется зачем-то. ·>Ветки же уже заведены — с именем "experiment". Надо будет кому-то из них ветку переименовывать, переписывая историю. А от этой истории уже могут другие зависимости существовать...
В худшем случае, если Маша с Петей две недели пахали локально в ветках с одинаковым названием, успели наделать много-много ревизий, даже успели засветить где-то на стороне хеши этих ревизий, а потом одновременно запушили на сервер, так что ни у кого из них не было шанса заранее узнать о совпадении имён ― ну, значит, пока будет две ветки "experiment". Хоть три. Можно их сразу закрыть и продолжить с новыми внятными названиями. Можно повесить закладки. Можно оставить как есть.
Я толком не пользовался Гитом и не могу прочувствовать проблему совпадения имён.
A>>Маша и Петя спокойно обошлись без именованных веток, без bookmarks, без тэгов, вообще без всего. ·>Т.к. при совпадении имён веток, Маша может вытянуть ветку Пети под другим именем, скажем, назвать её в своём репозитории как petya_dev. По смыслу — ветки dev у Пети и у Маши — независимые истории.
Вот на самом деле зачем Маше Петина ветка под другим именем? По смыслу это одна ветка, у который есть своё имя (если есть). С чего его вдруг менять?
A>>·> Почему их нужно насильно сталкивать лишь по тому, что у них случайно совпали имена — хз. A>>Я думаю, слово "нужно" неверно. Устраивает базовый функционал анонимных веток? Пользуешься им. Испытываешь неудобства? Можешь использовать закладки и/или именованные ветки. ·>Как выяснилось выше — не могу, проблему они не решают.
Чем больше перечитываю, тем больше не понимаю, о чём речь. Что конкретно ты не можешь? Hg ругается на совпадение имён, виснет, теряет данные или не даёт коммитить, пушить и т.д.? Ему пофиг.
·>Вот. Уже внезапно стало три анонимные ветки, различать их стало ещё сложнее.
Там всё было подписано.
A>>Если использовать только неименованные ветки, то просто увидит, что из одной из ревизий, над которыми он работал, выросла новая голова. A>>Если он знает, что ему так будет неудобно, он может озаботиться, например, использованием синхронизируемых закладок. Тогда он тоже увидит три головные ревизии, но они будут подписаны: ·>Та же проблема, имена закладок глобальны, да ещё и пушатся без спросу — думай тщательно каждый раз когда даёшь название.
Можно тщательно думать, давая имена. Можно не думать, давая имена. Можно не давать имена. Имена не на что не влияют.
Я так понял из разговоров, что Гит заставляет давать каждой головной ревизии уникальные в пределах репозитория имена. Но поскольку головных ревизий бывает много, а слов в языке мало, то названия совершенно разных веток в разных репозиториях периодически совпадают. И тогда чтобы влить в один репозиторий изменения из другого, иногда приходится чужие ветки у себя переименовывать. И тогда в разных репозиториях совершенно разные ветки могут называться одинаково, а одна и та же ветка может называться по-разному. Отсюда, наверное, такая любовь и ненависть к именам?
Здравствуйте, ·, Вы писали:
_>>Зато применяются по делу, в отличие от git. _>>Смотри, в mercurial и именновые ветки и закладки (выбираешь в зависимости от своего вкуса) применяются исключительно для выделения долгоживующих сущностей. Т.е. если у тебя реально в репозитории намечаются две принципиально разные ветки (скорее всего созданные в самом начале истории), то надо применять что-то из этой области. Если же у тебя реально только одна ветка, которая периодически разделяется и сливается из-за синхронизации работы команды, то выделенные именные сущности просто не нужны. ·>Собственно по-моему это и есть философское отличие. В hg ты должен заранее решить что и как ты делаешь, что у тебя намечается и в зависимости от этого выбирать какой-то из механизмов, если ты принял неверное решение — исправить ситуацию довольно геморно. В git принципиальной разницы нет. Сделай как-нибудь что-нибудь как кажется правильным на текущий момент, а потом, если что, поменяешь как надо, когда будешь точно знать что тебе надо.
Эм, никакой технической проблемы поменять расклад в Mercurial в любой момент. Это я тебе рассказал наиболее логичный и удобный подход на мой взгляд, а не ограничение системы.
_>>В Git же приходится применять ветки не только для реальных выделенных сущностей, но но и для обслуживания ситуации синхронизации параллельной разработки в одной (смысловой) ветке. ·>Ты так говоришь, как будто это что-то плохое. В стандартном случае у тебя после clone будет две ветки — master — твоя работа и origin/master — ветка оригинального репозитория. Ты сразу можешь точно видеть где твоё, а что идёт от других.
Вот уж свою ветку со своими комментариями к ревизиям я уж как-нибудь отличу от чужих. )))
·>Да, верно. Чтобы появилось имя ветки надо сделать коммит, даже если содержимое X и Y идентично (тот же snapshot), их sha1 будет разный. ·>Т.е. если строгаю я всё в default-ветке, потом создаю release_candidate, и продолжу строгать default — появится расхождение графа ревизий. Это алогично, ведь по факту, с т.з. моих рабочих файлов — никаких расхождений нет, история изменений working copy — линейная. release_candidate не разхождение ревизий, а просто left behind ветка, которую можно fast forward. ·>Расхождение должно появиться только в том случае, если я внёс изменение и в release_candidate, и в default, т.е. появилась ревизия с двумя детьми. А что собственно значит появилось расхождение — это значит, что появилась "альтернативная история", которую можно 3-way мержить.
Ммм, так а ты объясни тогда зачем в твоём сценарии создавать новую ветку и делать в ней пустую ревизию?
_>>Ну и да, это бредовый способ использования именованных веток (т.к. собственно ветвления тут нет) и его никто не использует. Но если очень хочется (я правда так и не понял зачем оно тебе такое было надо), то технически возможно. ·>Да, закладки — как возможное решение. Остаётся вопрос — накой нужны ветки. И почему "это" называется "веткой" в hg.
Формально оно называется "именем ветки" и при этом несколько веток официально могут иметь одно название. ))) Но согласен, что название не совсем удачное. Что касается функциональности, то из их фундаментального отличия (имя ветки идентифицирует целый набор ревизий, а закладка только одну) следует и большая разница в применение. Например имена веток остаются навсегда в истории, что очень полезно для отслеживание работы команды. Кроме того, имена веток не реагируют (наследуются в обе части) на мелкие анонимные разветвления, а закладки соответственно идут только по какому-то одному пути. Так что разница принципиальная. И лично мне для выделения принципиальных долгоживущих частей истории проекта больше нравится использовать именные ветки, а не закладки. Но это дело вкуса. В Mercurial богатый выбор вариантов, в отличие от Git. )))
_>>В том то и дело, что не так же. Нет в git нормальной работы на уровне чистых ревизий. Вот к примеру как мне узнать список всех "голов" в хранилище? Я уже молчу про то, что git-gc может самовольно удалять подобные данные. Нет, в git нельзя нормально работать без именованных веток, хотя внутри у него в базисе такая же основа как и у mercurial. Но не смогли... ·>Голов слишком много, их можно найти через "fsck", или через "reflog". Например, когда правишь коммит (скажем поправить орфографическую ошибку в комменте), возникает "голова", которую и не грех собрать gc. Без именнованных веток работать можно, но бессмысленно, человекам имена понятнее, чем циферки. Комфорт работы с безымяными ветками в hg является удобством лишь в сравнении с тем, что с именованными ветками работать хреново.
Ну т.е. как я и говорил, нормально работать с анонимными ветками в Git нельзя. Несмотря на то, что где-то на низком уровне там как раз такой же механизм (хэши и связи). Но не смогли...
·>Скажем, изменения приезжающие из других репозитоиев появляются как безымянные головы именованной ветки — нужно догадываться что откуда. В git они приезжают с префиксом имени других репозиториев, human friendliness, однако.
Смешно) В Git мы имеем ровно один способ реализации ветвлений. А в Mercurial мы имеем 3 разных способа (причём один из них совпадает с реализацией в Git) — используй какой тебе больше по вкусу, никто не ограничивает. Но при этом ты считаешь, что Git в этом смысле лучше? )))
_>>А вот реальные именованные ветки/закладки есть смысл использовать при наличие логически выделенных веток разработки, а не для синхронизации работы или установки каких-то меток (для этого есть теги). ·>А вот представь себе, что в гите неважно кратковременно или долговременно что-то ответвляется. Механизмы те же, инструменты те же, команды те же, и то, и то использовать просто.
Собственно я ещё в самом начале дискуссии сказал, что данный вопрос больше дело вкуса. )
_>>·>Пусть другой граф, пороще, с расхождением, мержем и одной веткой: _>>·>
_>>Ну так ты поясни что это. Я вот вижу некую ветку, которая разделяется и потом сливается. Это понятно и нормально. Потом я вижу некую метку "development" на последней ревизии ветки. Что она у тебя должна означать? ) ·>Пусть именованную ветку или закладку. Не важно. Покажи на этом рисунке "a linear sequence of consecutive changesets", например.
Ну вот то, что ты нарисовал — это оно и есть как раз. ) В начале одна линия, потом разделяется на две, потом сливается снова в одну. ) Что тут может быть непонятного? )
_>>ОК, а если у нас репозитории ревизия на которую нет ссылок через ветки/теги, то как нам с ней работать? ) ·>А почему нет? Создать ссылку — элементарно, ничего не стоит, никаких проблем не создаёт, если вдруг мешается, можно удалить, никаких последствий.
Про Оккама забываем? )))
·>А если ты робот и тебе надо без ссылок, всегда есть id.
Да, вот только робот и может пользоваться анонимными ветками в git (записывая на бумажку хеши и отключив при этом git-gc).
Здравствуйте, ·, Вы писали:
AK>>что скажет история git про эти два новых файла? как они будут связаны с оригиналом? ·>git пытается восстановить происшедшее, сравнивая содержимое файлов. Скажем, git blame -C сможет показать строчки в новых файлах как переехавшие из старого. ·>Этот процесс основан на нечётких сравнениях строчек. Поэтому, желательно такие громадные изменения делать серией мелких коммитов — это будет проще отследить не только гиту, но и человеку делающему ревью, и тебе самому пол года спустя.
Хехе, а если взглянуть на это с точки зрения нашей дискуссии.. Ты в курсе наличие в Mercurial команд copy/rename/remove? )))
Здравствуйте, ·, Вы писали:
·>Вроде я понял чего тебе не понятно. hg имеет жуткое cvcs наследие, которым жестоко коцают мозги юзеров. Ты видишь только два репозитория, притом один из них более главный, или ещё "центральный сервер". А в dvcs — репозиториев потенциально бесконечно и они все равноправны. Маша и Петя это могут быть две БОЛЬШИЕ команды. И закладка команды ПЕТЯ уже разползлась в 1000 реп, закладка команды МАША в 2000 реп. И вот теперь приходит тут такая МАША и указывает ПЕТЕ что он у себя всё везде обязан поменять, т.к. МАША так хочет, как думаешь, куда пошлёт её ПЕТЯ?
Нет, подходы совсем не такие, хотя действительно различаются:
1. В централизованных VCS имеем ровно одно хранилище где-то на сервере, а у пользователей нет ничего. Соответственно в синхронизированном состояние у всех абсолютно одинаковая картинка.
2. В Mercurial у каждого пользователя имеется копия репозитория (как и во всех DVCS), но при этом в синхронизированном состояние она у всех одинаковая.
3. В Git у каждого пользователя имеется копия репозитория (как и во всех DVCS), но при этом у каждого репозиторий выглядит по разному (разные имена веток соответствую разным реальным ревизиям и т.д.).
Здравствуйте, Dair, Вы писали:
D>Диспозиция: я в своей ветке, наменял разного, делаю коммит (не push) и готовлюсь взять последюю версию от коллег из develop, чтобы не сильно отставать. Для этого надо мне тут сделать commit, переключиться на общий develop, сделать pull, переключиться обратно, сделать merge.
Строго говоря нет, не нужно переключать ветки. Если ты не изменял ничего в своей локальной версии develop-a, то можно сделать просто
git fetch origin develop:develop
Еще лучше просто написать alias и делать в одну команду все это.
·>Что ещё за указатели на ветки? Есть просто reference (ссылка) и всё. Сссылка с префиксом refs/heads/ является веткой, с префиксом refs/tags/ — тегом, с префиксом refs/remotes/ — ссылки из чужих репо, и т.п. Там же и stash, там же и notes и кастомные вещи, типа pull requests гитхаба. ·>Команды какие ещё? update-ref только, остальные (branch, tag, notes) просто надстройки — для удобства человеков только.
Можно как-то откатиться на коммит HEAD~N и увидеть все эти ветки в том виде как они были на тот момент на сервере (тот что origin). Считаем что за давностью лет все эти ветки и метки на origin давно потерты.
Здравствуйте, woah, Вы писали:
W>Можно как-то откатиться на коммит HEAD~N и увидеть все эти ветки в том виде как они были на тот момент на сервере (тот что origin). Считаем что за давностью лет все эти ветки и метки на origin давно потерты.
Что значит "откатиться"? У нас не централизованная VCS, некуда откатываться.
Можно посмотреть какие в репозитории были названия голов в данное время.
Здравствуйте, alex_public, Вы писали:
AK>>>что скажет история git про эти два новых файла? как они будут связаны с оригиналом? _>·>git пытается восстановить происшедшее, сравнивая содержимое файлов. Скажем, git blame -C сможет показать строчки в новых файлах как переехавшие из старого. _>·>Этот процесс основан на нечётких сравнениях строчек. Поэтому, желательно такие громадные изменения делать серией мелких коммитов — это будет проще отследить не только гиту, но и человеку делающему ревью, и тебе самому пол года спустя. _>Хехе, а если взглянуть на это с точки зрения нашей дискуссии.. Ты в курсе наличие в Mercurial команд copy/rename/remove? )))
Ага, круто, конечно, сразу видно, Бритва тупая попалась. Но как оно поможет разделить один файл на два новых?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, alex_public, Вы писали:
_>1. В централизованных VCS имеем ровно одно хранилище где-то на сервере, а у пользователей нет ничего. Соответственно в синхронизированном состояние у всех абсолютно одинаковая картинка. _>2. В Mercurial у каждого пользователя имеется копия репозитория (как и во всех DVCS), но при этом в синхронизированном состояние она у всех одинаковая.
Враньё же... Показывали же тут эти картинки — выглядят по-разному, т.к. корёжатся локальными номерами ревизий.
Ещё интересно, что же такое "синхронизованное состояние у всех" в dvcs. Ты имеешь в виду "после полной синхронизации всего между парой репозиториев"?
_>3. В Git у каждого пользователя имеется копия репозитория (как и во всех DVCS), но при этом у каждого репозиторий выглядит по разному (разные имена веток соответствую разным реальным ревизиям и т.д.).
Неверно. Имена веток совпадают. Ремотные ветки имеют то же имя что и ветки в ремотном репо. Другое дело, что при необходимости их _можно_ замапить под другим именем на локальные.
_>Лично мне больше всего нравится вариант 2.
Если только дело вкуса.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, woah, Вы писали:
W>·>Ещё можно просто по sha1 обращаться. Можно reflog полистать, можно в stash закинуть. Вариантов куча. W> И ни один неудобен для человека.
В каком случае ты столкнёшься с этим неудобством? Опиши сценарий.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
_>>Эм, никакой технической проблемы поменять расклад в Mercurial в любой момент. Это я тебе рассказал наиболее логичный и удобный подход на мой взгляд, а не ограничение системы. ·>Как ты branch переделаешь в bookmark? ·>Ты говоришь, мол это для короткоживущих, это для долгоживущих... Как ты это определяешь? Ты знаешь будущее? Я не ясновидец, я не умею и не хочу думать об этом выборе. Почему это должно отличаться?
Зачем переделывать одно в другое? ) Они же все совместимы между собой. Собственно их так обычно и используют. Вот нужна тебе долгоживущая ветка — устанавливаешь имя. Требуется мелкое ответвление в ней — используешь анонимные ветки (правда в данном случае они на самом деле будут не анонимные, а просто с совпадающими именами изначальной). Хочешь как-то выделить одну из этих анонимных подветок — ставишь на неё закладку. ) В общем всё полностью совместимо на любом уровне.
_>>·>Расхождение должно появиться только в том случае, если я внёс изменение и в release_candidate, и в default, т.е. появилась ревизия с двумя детьми. А что собственно значит появилось расхождение — это значит, что появилась "альтернативная история", которую можно 3-way мержить. _>>Ммм, так а ты объясни тогда зачем в твоём сценарии создавать новую ветку и делать в ней пустую ревизию? ·>А разве можно запушить ветку, если она не закоммичена?
А что значит "запушить ветку"? ) И зачем это надо? )
_>>Формально оно называется "именем ветки" и при этом несколько веток официально могут иметь одно название. ))) Но согласен, что название не совсем удачное. ·>Не знаю откуда ты берёшь это "формально", в официальной документации это называется named branch, "именованная ветка". Да и команды, работающие с ними "hg branch", "hg branches". "--branch".
Да, имена команд тоже неудачно вышли, хотя понятно что это так для краткости. Но тут вообще непонятно как было правильно назвать. Смотри, тут есть:
— ветки. Это которые мы в данной дискуссии называем анонимными (хотя на самом деле это неверно, т.к. у любой из них на самом деле есть имя (default или какое-то другое), просто оно может совпадать с именем соседней ветки).
— имена веток. Просто атрибут у каждой ревизии.
Так вот команды hg branch и т.п. работают как раз с именами веток, так что теоретически должны были бы называться как-то типа branch_name и т.п. Но это же тоже бредово... )
_>>Ну т.е. как я и говорил, нормально работать с анонимными ветками в Git нельзя. Несмотря на то, что где-то на низком уровне там как раз такой же механизм (хэши и связи). Но не смогли... ·>Я не понимаю что ты подразумеваешь под нормально работать. Зачем вообще с анонимными ветками работать? Особенно в случае, если с именованными проблем никаких.
Это уже отдельный вопрос (который мы вроде как тоже параллельно обсуждаем). Но вне зависимости от его результатов у нас останется тот факт, что в Git отсутствует имеющаяся в Mercurial возможность работы с анонимными ветками.
_>>Смешно) В Git мы имеем ровно один способ реализации ветвлений. А в Mercurial мы имеем 3 разных способа (причём один из них совпадает с реализацией в Git) — используй какой тебе больше по вкусу, никто не ограничивает. Но при этом ты считаешь, что Git в этом смысле лучше? ))) ·>Букмарки не совпадают с git, имеют неразрешимые проблемы. Так что я предпочту один способ, но универсальный, чем три — но ограниченных.
Что за неразрешимые проблемы? )
·>Эти проблемы, надеюсь, уже пофиксили?
Хы, к mercurial там ровно две претензии:
1. не позволяет подчищать репозиторий задним числом без особых манипуляций. Смешно, т.к. сохранности историй — это один из базовых принципов Mercurial.
2. не позволяет сделать push закладки. Видимо автор не в курсе про параметр -B у команды push. )))
_>>Собственно я ещё в самом начале дискуссии сказал, что данный вопрос больше дело вкуса. ) ·>Хорошо, пусть дело вкуса. Но смысла уж точно нет.
Вот не надо только пропагандировать тут подход Apple — в профессиональной среде он плохо проходит. )))
_>>>>·>Пусть другой граф, пороще, с расхождением, мержем и одной веткой: _>>>>·>
_>>>>Ну так ты поясни что это. Я вот вижу некую ветку, которая разделяется и потом сливается. Это понятно и нормально. Потом я вижу некую метку "development" на последней ревизии ветки. Что она у тебя должна означать? ) _>>·>Пусть именованную ветку или закладку. Не важно. Покажи на этом рисунке "a linear sequence of consecutive changesets", например. _>>Ну вот то, что ты нарисовал — это оно и есть как раз. ) В начале одна линия, потом разделяется на две, потом сливается снова в одну. ) Что тут может быть непонятного? ) ·>Не понял. В каком начале? Это текущий граф, текущая история. sequence может быть выражена как последовательность точек. Я поменял граф, обозначив точки уникально. Перечисли эти линии.
Я так и не понял что ты хочешь))) Точнее не пойму чем тебя не устраивает мой ответ в первом же сообщение (много страниц назад). Ну да ладно, мне не сложно повторить в сотый раз, уже с буковками. ))) Последовательности ревизий: {a, b, c}, {d, e, f}, {g}, {h, i, j, k}.
·>В hg об Оккаме и не всмоминали: помимо "именованных веток" ввели сущность "анонимные ветки" и прочие закладки с головами. ·>Мне вообще интересно, опиши сценарий: откуда в git появится ревизия на которую нет ссылкок и что ты с ней хочешь делать, для чего она тебе может понадобится?
Ну вот работаю над каким-то проектом, решил проверить некое решение, закодировал, убедился что оно сейчас не подходит (но код полезный и пригодится в будущем), зафиксировал его в виде ревизии, откатился назад на одну ревизий и пошёл работать дальше, создавая новые ревизии. При этом у меня там останется маленький отросток (ветка из одной ревизии), который возможно когда-нибудь пригодится.
Это я описал сценарий в Mercurial. А как оно будет в Git? ) Будешь создавать по каждому такому поводу отдельную ветку с новым именем? )
Кстати, возвращаясь к дискуссии выше о совместимости разных техник. Если я захочу, то я могу поставить данному отростку (и всем остальным подобным) имя ветки "experimental" и это отлично сработает. Не смотря на то, что в реальности данные отростки не образуют связное дерево.
Здравствуйте, ·, Вы писали:
_>>Хехе, а если взглянуть на это с точки зрения нашей дискуссии.. Ты в курсе наличие в Mercurial команд copy/rename/remove? ))) ·>Ага, круто, конечно, сразу видно, Бритва тупая попалась. Но как оно поможет разделить один файл на два новых?
Эм, ну вообще то даже без всяких VCS, разделение обычно производят через копирование файла и потом стирания в каждой копии ненужного. )))
Здравствуйте, ·, Вы писали:
_>>1. В централизованных VCS имеем ровно одно хранилище где-то на сервере, а у пользователей нет ничего. Соответственно в синхронизированном состояние у всех абсолютно одинаковая картинка. _>>2. В Mercurial у каждого пользователя имеется копия репозитория (как и во всех DVCS), но при этом в синхронизированном состояние она у всех одинаковая. ·>Враньё же... Показывали же тут эти картинки — выглядят по-разному, т.к. корёжатся локальными номерами ревизий.
Это типа юмор? ))) Тогда уж у разных участников команды возможно ещё и разные GUI к Mercurial и там уж точно по разному деревья рисуются... )))
·>Ещё интересно, что же такое "синхронизованное состояние у всех" в dvcs. Ты имеешь в виду "после полной синхронизации всего между парой репозиториев"?
Все участники команды делают push в один репозиторий (любой), а потом все делают pull из него. ) Получаем синхронизированное состояние всей команды в этот момент времени. Естественно при использование DVCS в этом нет надобности, но для проверки одинаковости отображения каждого репозитория вполне подходит. )
_>>3. В Git у каждого пользователя имеется копия репозитория (как и во всех DVCS), но при этом у каждого репозиторий выглядит по разному (разные имена веток соответствую разным реальным ревизиям и т.д.). ·>Неверно. Имена веток совпадают. Ремотные ветки имеют то же имя что и ветки в ремотном репо. Другое дело, что при необходимости их _можно_ замапить под другим именем на локальные.
Ну так а разработка то идёт в других ветках с другими именами. Ну и к тому же имя Петя/develop вовсе не совпадает с именем develop (не говоря уже о том, что у тебя есть своя ветка develop с совсем другими данными).
Здравствуйте, alex_public, Вы писали:
_>>>Не, команды по определению имеющие дело с одной ревизией только их и принимают (а не имена ссылок/закладки/теги и т.п.). N>>А зачем тогда эти ярлыки используются? Только для чтения истории "под какой ярлык была эта ревизия"? Из пушки по воробьям. _>Так есть же множество команд работающих с наборами ревизий) Там и push/pull/bundle/clone и incoming/outgoing и log и т.д. и т.п.
Очень радует идея представить себе, как, например, log показывает последовательность коммитов совершенно разных веток в одну линию.
_>Т.е. чтобы сделать аналог простейшего режима работы в Mercurial вообще без именованных веток в Git надо завести в каждом репозитории минимум 2 ветки (одну общую для синхронизации и слияний и одну для локальной разработки), правильно? )
Да. И это правильно.
_>>>Какие мысленные усилия? ) Если предположим (для упрощения объяснения) в данной разработке не нужны долгоживущие отдельные ветки (которые по смыслу создаются, а не для синхронизации отдельных членов команды), то в Mercurial будет просто ровно одна ветка периодически разветвляющаяся (в моменты параллельной разработки членов команды) и тут же сливающаяся в одну. _>>>А что будет в случае в Git? ) N>>То же самое. _>Ну покажи пример такого графа. )
Он совпадает с точностью до пометок на коммитах. Не вижу смысла тратиться на рисование примера.
_>P.S. Кстати, тут что-то вспомнилось... А что у git с аналогами команд hg copy/rename/remove? ) Помнится он там что-то автоматическое пытался делать, но чаще всего криво... )))
Здравствуйте, woah, Вы писали:
N>>Слушай, а у тебя с RAM, шиной и т.п. на данном компе всё в порядке? N>>Ничем иным я объяснить подобные чудеса на сейчас не могу, кроме как битым железом.
W>Скорее всего crlf настройки разные стоят у разных членов команды.
Ситуацию, когда в пределах одной рабочей копии status показывает изменение, а hard reset его не сбрасывает, это не даст.
W>Боянная проблема гитоводов.
Боянное верхоглядское делание выводов на основании недочтения с твоей стороны. Или покажи живой пример.
Здравствуйте, woah, Вы писали:
N>>Если авторы не в состоянии отработать с точки зрения даже простейший сценарий использования, как можно предлагать использовать их творение?
W>Резюмирую твои проблемы и вопросы: ты просто не прочитал документацию
Именно, что я её прочитал, и в этом была ошибка. Потому что чтобы понять бред с "ветка — это не ветка, это другая ветка", надо было не читать документацию, в которой это ясно не описано, а надо было начинать с поясняющих источников от тех, кто уже потоптался по этим граблям. И только после этого, уяснив грабли наперекор всему тому, что говорится в документации и туториалах, и прошлому опыту (у меня CVS и SVN), можно начинать "работать" с ним.
"Минус" за необоснованный личный наезд.
W>Гит в этом плане еще хуже, там нормально пользоваться нельзя пока ты досконально не прочитаешь хотя бы git-scm book.
Я не читал никакую git-scm book до начала его использования. Более того, я и сейчас не знаю, что это. Я прочитал двухстраничное руководство по основным сценариям (не помню, как звалось), страничку Git Daily и взял у коллеги распечатку Git Cheat Sheet. Этого хватило для полноценной работы до тех пор, пока не потребовалось корректировать свои глупости в коммитах, для чего был внимательно вкурен git help rebase. После этого потребовалось ещё только несколько раз перечитывать инструкции по конкретным командам. В целом, я не видел ещё более лёгкой в освоении системы. Даже CVS был немного сложнее (хотя тут, возможно, сказалось таки, что это мне была вообще первая система контроля версий).
W>Вообще то что по использованию гита книги пишут уже хороший показатель "удобства" инструмента.
Нет. То, что по нему пишут книги, всего лишь показывает его популярность. Книги писали по всем популярным VCS, начиная с CVS. О любом подобном средстве можно написать книгу, причём в десятках разных стилей — от краткого справочника до полного описания всего, что может встретиться на практике, причём 90% этого будет вообще не зависеть от применяемого средства. Уж поверь автору пары учебных курсов с реальным опытом преподавания.
W>Тот же svn я пользовал из под гуя несколько лет и только пару раз заглядывал в документацию. Просто не было необходимости такой. По гиту то и дело лезу то на стек, то в handbook, то в гугл.
"Из-под гуя" ты пользовал не SVN, а его гуёвую морду, если уж на то пошло. И если ты используешь Git в том же стиле, что SVN, то проблемы не с Git.
Морды вроде Tortoise* универсализуют подходы всех систем (у меня есть коллеги, которые привыкли к SVN и не знают, что его родные средства не позволяют, например, банальный частичный коммит изменений файла). Но это не сами описываемые средства, а нашлёпки.
Здравствуйте, alex_public, Вы писали:
_>>>Хехе, а если взглянуть на это с точки зрения нашей дискуссии.. Ты в курсе наличие в Mercurial команд copy/rename/remove? ))) _>·>Ага, круто, конечно, сразу видно, Бритва тупая попалась. Но как оно поможет разделить один файл на два новых?
_>Эм, ну вообще то даже без всяких VCS, разделение обычно производят через копирование файла и потом стирания в каждой копии ненужного. )))
Именно в таком варианте в анализаторе истории будет обнаружено полное совпадение файла и показан факт копирования.
Но этот метод полезен только для того, чтобы помочь с автослежением по истории.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>>Думаю тут наоборот — одна из причин популярности GitHub, в том что он именно GitHub.
НС>А почему тогда слился битбакет, где и гит, и меркьюриал, на выбор?
В каком смысле "слился"? Вчера я с него pull'ил, сейчас зашёл на веб — работает.
Какие проблемы могут быть с публичным сервисом, который зарабатывает на платных версиях сервиса и косвенных источниках — да любые. Вон сейчас GitHub "перетрахивают" ((c) Бацька). Но я подозреваю, что большинство из тех, кто размещают репозитории типа "скрипт для слежения за моей собакой", пугаются фактора "бесплатность до 5 участников", даже когда количество участников не превосходит 3, включая саму собаку.
Здравствуйте, Mazenrab, Вы писали:
M>·>Да нет такой проблемы, открой для себя "git log -M" или ещё круче — "git blame -C", который может найти, например, перемещённый метод из одного файла в другой (такого в hg вроде нет). M>Спасибо, попробую при случае. Но я вообще стараюсь пользоваться встроенным в студию инструментарием полагая что так сложнее выстрелить себе в ногу.
Безотносительно git, зачем навязывать себе искусственные рамки вроде использования только инструментария Студии?
Здравствуйте, alex_public, Вы писали:
_>>>2. В Mercurial у каждого пользователя имеется копия репозитория (как и во всех DVCS), но при этом в синхронизированном состояние она у всех одинаковая. _>·>Враньё же... Показывали же тут эти картинки — выглядят по-разному, т.к. корёжатся локальными номерами ревизий. _>Это типа юмор? ))) Тогда уж у разных участников команды возможно ещё и разные GUI к Mercurial и там уж точно по разному деревья рисуются... )))
Интересно посмотреть консольный граф, чтобы выглядел одинаково.
_>·>Ещё интересно, что же такое "синхронизованное состояние у всех" в dvcs. Ты имеешь в виду "после полной синхронизации всего между парой репозиториев"? _>Все участники команды делают push в один репозиторий (любой), а потом все делают pull из него. ) Получаем синхронизированное состояние всей команды в этот момент времени. Естественно при использование DVCS в этом нет надобности, но для проверки одинаковости отображения каждого репозитория вполне подходит. )
Т.е. сценарий CVCS. В такой ситуации графы git будут совпадать с точностью до буковки.
_>>>3. В Git у каждого пользователя имеется копия репозитория (как и во всех DVCS), но при этом у каждого репозиторий выглядит по разному (разные имена веток соответствую разным реальным ревизиям и т.д.). _>·>Неверно. Имена веток совпадают. Ремотные ветки имеют то же имя что и ветки в ремотном репо. Другое дело, что при необходимости их _можно_ замапить под другим именем на локальные. _>Ну так а разработка то идёт в других ветках с другими именами. Ну и к тому же имя Петя/develop вовсе не совпадает с именем develop (не говоря уже о том, что у тебя есть своя ветка develop с совсем другими данными).
Имя совпадает, это "develop", а "Петя/" это префикс или пространство (namespace). Т.е. имена не глобальны, а разделены на пространства естественным образом.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, netch80, Вы писали:
_>>Трудно читать на украинском) Хотя смысл угадывается конечно. ))) N>Если ты не в Китае или ещё каком медвежьем углу, есть Google Translate. Навязывать свой вариант перевода я не хотел.
Хы, точно, как-то я не подумал. ) Видимо он всё же не как иностранный ощущается. )))
_>>Из существенных претензий тут только пункт с close-branch. Если бы он был правдивый (тут уже вроде всё показали на эту тему). N>Не-а. Из существенных тут невозможность узнать в любой момент, что в staging. Вот это действительно очень серьёзный злобный фактор. А работа веток, которые не ветки, тут действительно мелкий фактор.
Это ты про что (в Mercurial же нет понятия staging), про возможность показать что будет зафиксировано или про какие-то дополнения к работе расширения record? )
_>>А чем по твоему отличаются расширения входящие в поставку Mercurial от обычных команд? ) Лично я не вижу вообще никакой разницы. N>Тем, что их ещё включать надо. Значит, авторы считают, что по умолчанию они не нужны. А это как раз показывает, на какой вариант они сами рассчитывают и что пропагандируют. Если возможность изменить уже зафиксированный коммит это для них что-то необычное, то это не нормальная работа, а грязнокодинг.
Всё верно. Режим по умолчанию рекомендует не трогать историю, а если уж очень хочется, то можешь включить в расширениях.
А почему это грязнокодинг? ) Разве нельзя добиться нужного результата не меняя историю (например та же команда hg backout демонстрирует пример подобного)? В итоге у тебя будет всё красиво и история сохранится. Или тебе надо скрыть из истории все следы косяков и т.п.? )))
N>>>2. Диверсии в виде неименованных голов, наоборот, вынести в расширения и не включать по умолчанию. _>>Как ты себе представляешь отключение по умолчанию базовой функциональности, вокруг которой и строится вся система? ))) N>Она не базовая. Базовая это цепочки коммитов. А фиксация безымянных голов это уже расширение. И это ещё раз показывает следствия безумного бардака с терминологией.
А как можно организовать цепочки без фиксации? )
N>>>4. Решить остальные описанные Lyubomyr Shaydariv проблемы. Для начала, _>Причём тут изменение хэша ревизии? ) Я вообще про другое говорил. Что предпочитаю подход в котором всё, что попадает в систему контроля версий, уже навсегда остаётся в истории. N>Это называется наплевательством на качество результата. Я не могу принять ни такой стиль, ни следствия в виде "нефиг менять, раз однажды закоммитил" для *VCS.
А что ты называешь качественным результатом то? ) Мне казалось это должна быть идеально работающая последняя ревизия. Но у тебя это похоже что-то иное... )))
Здравствуйте, netch80, Вы писали:
_>>Т.е. чтобы сделать аналог простейшего режима работы в Mercurial вообще без именованных веток в Git надо завести в каждом репозитории минимум 2 ветки (одну общую для синхронизации и слияний и одну для локальной разработки), правильно? ) N>Да. И это правильно.
Ага, и в итоге у каждого репозиторий выглядит по своему. Весело. )))
_>>P.S. Кстати, тут что-то вспомнилось... А что у git с аналогами команд hg copy/rename/remove? ) Помнится он там что-то автоматическое пытался делать, но чаще всего криво... ))) N>Не понимаю проблемы.
Да тут вот народ рядом жалуется на то, что при рефакторинге git делает некую ересь. )
Здравствуйте, netch80, Вы писали:
_>>Эм, ну вообще то даже без всяких VCS, разделение обычно производят через копирование файла и потом стирания в каждой копии ненужного. ))) N>Именно в таком варианте в анализаторе истории будет обнаружено полное совпадение файла и показан факт копирования. N>Но этот метод полезен только для того, чтобы помочь с автослежением по истории.
Это только если зафиксировать изменения сразу после копирования. А если закончить рефакторинг до конца, то что тогда будет? )
Здравствуйте, ·, Вы писали: _>>Зачем переделывать одно в другое? ) Они же все совместимы между собой. Собственно их так обычно и используют. Вот нужна тебе долгоживущая ветка — устанавливаешь имя. Требуется мелкое ответвление в ней — используешь анонимные ветки (правда в данном случае они на самом деле будут не анонимные, а просто с совпадающими именами изначальной). Хочешь как-то выделить одну из этих анонимных подветок — ставишь на неё закладку. ) В общем всё полностью совместимо на любом уровне. ·>Опять. Почему меня должно волновать долго ли, коротко ли живёт ветка? Зачем меня ставить перед этим выбором? Какую пользу приносит это решение?
Я тебе описал наиболее продуманные решения. Но тебя никто не заставляет ими пользоваться. Может приделывать имя на каждое микроветвление или вести основные ветки через закладки. Делай как тебе нравится. ))) _>>А что значит "запушить ветку"? ) И зачем это надо? ) ·>Опубликовать в удалённый репозиторий, или, что аналогично, затащить (fetch) из удалённого. Чтобы передать знание о том, что я решил считать релиз-кандидатом.
Эм, т.е. ты снова пытаешься просто повесить некую метку на конкретную ревизию с помощью создания именованной ветки? ) Жесть, вот что привычки к git'у делают. ))) _>>Так вот команды hg branch и т.п. работают как раз с именами веток, так что теоретически должны были бы называться как-то типа branch_name и т.п. Но это же тоже бредово... ) ·>Бредово, т.к. с твоей верой не согласуется...
Бредово в том смысле что длинно и неудобно, хотя и верно по смыслу) _>>Вот не надо только пропагандировать тут подход Apple — в профессиональной среде он плохо проходит. ))) ·>Вроде ты тут пропагандируешь — смысла нет, остаётся только дело вкуса.
Не, подход Apple "у нас этого нет — значит оно вам не нужно". ))) _>>Я так и не понял что ты хочешь))) Точнее не пойму чем тебя не устраивает мой ответ в первом же сообщение (много страниц назад). Ну да ладно, мне не сложно повторить в сотый раз, уже с буковками. ))) Последовательности ревизий: {a, b, c}, {d, e, f}, {g}, {h, i, j, k}. ·>Ок, допустим. Ты говорил, что последовательность ревизий это и есть ветка. Ты говорил, что hg позволяет хорошо работать с ветакми. Какой командой мне вывести эти четыре ветки для этого графа истории?
Так это смотря в какой момент времени смотреть) В разные моменты будут разные ответы. ) _>>Ну вот работаю над каким-то проектом, решил проверить некое решение, закодировал, убедился что оно сейчас не подходит (но код полезный и пригодится в будущем), зафиксировал его в виде ревизии, откатился назад на одну ревизий и пошёл работать дальше, создавая новые ревизии. При этом у меня там ·>останется маленький отросток (ветка из одной ревизии), который возможно когда-нибудь пригодится. _>>Это я описал сценарий в Mercurial. А как оно будет в Git? ) Будешь создавать по каждому такому поводу отдельную ветку с новым именем? ) ·>Конечно, в гите будет всё очень сложно. Поместил под кат длинный скрипт, чтобы не делать сообщение чрезвычайно очень длинным. ·>
Тут этот офигительно сложный скрипт, который доступен только после двадцатилетних курсов изучения гит фулл-тайм на специальных платных курсах, дарю тебе бесплатно
·>git stash
·>Неужели в hg так нельзя?
Так можно (это будет hg shelve), но это даже не близко к тому, что я описал. Как мне к примеру воспользоваться этим кодом из соседнего репозитория? ) Я уже не говорю о том, чтобы посмотреть разницу с текущей копией и т.п.
Здравствуйте, ·, Вы писали:
_>>·>Ещё интересно, что же такое "синхронизованное состояние у всех" в dvcs. Ты имеешь в виду "после полной синхронизации всего между парой репозиториев"? _>>Все участники команды делают push в один репозиторий (любой), а потом все делают pull из него. ) Получаем синхронизированное состояние всей команды в этот момент времени. Естественно при использование DVCS в этом нет надобности, но для проверки одинаковости отображения каждого репозитория вполне подходит. ) ·>Т.е. сценарий CVCS. В такой ситуации графы git будут совпадать с точностью до буковки.
Не будут — см. ниже)
_>>Ну так а разработка то идёт в других ветках с другими именами. Ну и к тому же имя Петя/develop вовсе не совпадает с именем develop (не говоря уже о том, что у тебя есть своя ветка develop с совсем другими данными). ·>Имя совпадает, это "develop", а "Петя/" это префикс или пространство (namespace). Т.е. имена не глобальны, а разделены на пространства естественным образом.
Так, я сажусь за один компьютер даю команду показать мне содержимое ветки develop. Потом сажусь за соседний, даю такую же команду и вижу другие данные. Это ты называешь одинаковыми репозиториями? )))
Здравствуйте, alex_public, Вы писали:
_>>>Ну так а разработка то идёт в других ветках с другими именами. Ну и к тому же имя Петя/develop вовсе не совпадает с именем develop (не говоря уже о том, что у тебя есть своя ветка develop с совсем другими данными). _>·>Имя совпадает, это "develop", а "Петя/" это префикс или пространство (namespace). Т.е. имена не глобальны, а разделены на пространства естественным образом.
_>Так, я сажусь за один компьютер даю команду показать мне содержимое ветки develop. Потом сажусь за соседний, даю такую же команду и вижу другие данные. Это ты называешь одинаковыми репозиториями? )))
Если мы рассматриваем ситуацию, когда всё синхронизировано — то с чего ты взял что данные будут другие? Репы будут идентичны.
А в общем случае да, могут быть другие, как и в hg — tip же может разный в разных репо.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, alex_public, Вы писали:
_>·>Опять. Почему меня должно волновать долго ли, коротко ли живёт ветка? Зачем меня ставить перед этим выбором? Какую пользу приносит это решение? _>Я тебе описал наиболее продуманные решения. Но тебя никто не заставляет ими пользоваться. Может приделывать имя на каждое микроветвление или вести основные ветки через закладки. Делай как тебе нравится. )))
Т.е. если я захочу в своём клоне делать всё через закладки, а ты в своём — через имена, то мы без проблем сможем обмениваться изменениями друг с другом? У нас ведь DVCS, каждый волен работать как ему нравится.
_>>>А что значит "запушить ветку"? ) И зачем это надо? ) _>·>Опубликовать в удалённый репозиторий, или, что аналогично, затащить (fetch) из удалённого. Чтобы передать знание о том, что я решил считать релиз-кандидатом. _>Эм, т.е. ты снова пытаешься просто повесить некую метку на конкретную ревизию с помощью создания именованной ветки? ) Жесть, вот что привычки к git'у делают. )))
Т.е. именованную ветку я "как мне нравится" уже не могу. Что-то ты себе противоречишь. Так "как нравится" или как разработчики hg решили?
_>>>Вот не надо только пропагандировать тут подход Apple — в профессиональной среде он плохо проходит. ))) _>·>Вроде ты тут пропагандируешь — смысла нет, остаётся только дело вкуса. _>Не, подход Apple "у нас этого нет — значит оно вам не нужно". )))
Я просто не понимаю чего "этого" у нас нет? Удобство работы с анонимными ветками что-ли? Но анонимные ветки это лишь способ решения неких задач, а не цель.
_>>>Я так и не понял что ты хочешь))) Точнее не пойму чем тебя не устраивает мой ответ в первом же сообщение (много страниц назад). Ну да ладно, мне не сложно повторить в сотый раз, уже с буковками. ))) Последовательности ревизий: {a, b, c}, {d, e, f}, {g}, {h, i, j, k}. _>·>Ок, допустим. Ты говорил, что последовательность ревизий это и есть ветка. Ты говорил, что hg позволяет хорошо работать с ветакми. Какой командой мне вывести эти четыре ветки для этого графа истории? _>Так это смотря в какой момент времени смотреть) В разные моменты будут разные ответы. )
В смысле? Я тебе говорю об одном моменте — который описан графом. Ты сказал в этом графе четыре ветки. Как их увидеть с помощью команд hg?
Ещё вопрос. Почему ты выбрал именно {h, i, j, k}? Чем {i, j, k}, {h, i, j}, {g, h, i, j, k} плохи? Тоже вроде линии.
_>>>Ну вот работаю над каким-то проектом, решил проверить некое решение, закодировал, убедился что оно сейчас не подходит (но код полезный и пригодится в будущем), зафиксировал его в виде ревизии, откатился назад на одну ревизий и пошёл работать дальше, создавая новые ревизии. При этом у меня там _>·>git stash _>Так можно (это будет hg shelve), но это даже не близко к тому, что я описал. Как мне к примеру воспользоваться этим кодом из соседнего репозитория? )
Да, когда шлёшь что-то другому репозиторию — надо создать имя. Иначе тому другому может пушить кто-то ещё и получится жуткий бардак.
Но в целом всё то же, всё так же, всё как обычно, ведь у нас всё — ветки!
git push origin stash@{13}:refs/heads/stash13
Да, длинновато писать приходится, но если это кому-то когда-то такое понадобится более одного раза, можно сделать алиас.
_>Я уже не говорю о том, чтобы посмотреть разницу с текущей копией и т.п.
git diff чем не устраивает?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, alex_public, Вы писали:
N>>>Ситуацию, когда в пределах одной рабочей копии status показывает изменение, а hard reset его не сбрасывает, это не даст. CX>>Я подобное наблюдал, когда в репозиторий были добавлены файлы с разным содержимым, но именами, отличающимися только регистром.
_>Какая милая система... )))
Очевидно, что это не проблема git-а. Это проблема различных используемых FS. Подобные проблемы будут с любым софтом. Но git с этим пытается бороться с помощью core.ignoreCase:
core.ignoreCase
If true, this option enables various workarounds to enable Git to work better on filesystems that are not case sensitive, like FAT. For example, if a directory listing finds "makefile" when Git expects "Makefile", Git will assume it is really the same file, and continue to remember it as "Makefile".
The default is false, except git-clone(1) or git-init(1) will probe and set core.ignoreCase true if appropriate when the repository is created.
_>Кстати, я помнится наблюдал ещё, что git (как и многий другой древний линуксовый софт) до сих пор ломается на каталога с пробелами в именах. ) Это вообще жесть и убогость. )))
Это не так. Если подавать пути ему на вход правильно (т.е. в кавычках или с экранированными пробелами), проблем нет.
Здравствуйте, ·, Вы писали:
_>>Так, я сажусь за один компьютер даю команду показать мне содержимое ветки develop. Потом сажусь за соседний, даю такую же команду и вижу другие данные. Это ты называешь одинаковыми репозиториями? ))) ·>Если мы рассматриваем ситуацию, когда всё синхронизировано — то с чего ты взял что данные будут другие? Репы будут идентичны. ·>А в общем случае да, могут быть другие, как и в hg — tip же может разный в разных репо.
Давай разберёмся. Для нормальной работы Git необходимо завести минимально две ветки в каждом репозитории: одну общую для синхронизации со всеми и одну собственно для работы. Так вот, даже если каждый член команды и назовёт эту вторую ветку одинаково, то всё равно в них будут разные данные.
Здравствуйте, ·, Вы писали:
_>>Я тебе описал наиболее продуманные решения. Но тебя никто не заставляет ими пользоваться. Может приделывать имя на каждое микроветвление или вести основные ветки через закладки. Делай как тебе нравится. ))) ·>Т.е. если я захочу в своём клоне делать всё через закладки, а ты в своём — через имена, то мы без проблем сможем обмениваться изменениями друг с другом? У нас ведь DVCS, каждый волен работать как ему нравится.
Без проблем. ) Правда я тогда буду видеть твои закладки, а ты будешь видеть мои ветки. ))) Правда закладки можно и локальные сделать...
_>>>>А что значит "запушить ветку"? ) И зачем это надо? ) _>>·>Опубликовать в удалённый репозиторий, или, что аналогично, затащить (fetch) из удалённого. Чтобы передать знание о том, что я решил считать релиз-кандидатом. _>>Эм, т.е. ты снова пытаешься просто повесить некую метку на конкретную ревизию с помощью создания именованной ветки? ) Жесть, вот что привычки к git'у делают. ))) ·>Т.е. именованную ветку я "как мне нравится" уже не могу. Что-то ты себе противоречишь. Так "как нравится" или как разработчики hg решили?
Ну формально то как раз можешь, но это бред. Для таких целей теги есть)
_>>Так это смотря в какой момент времени смотреть) В разные моменты будут разные ответы. ) ·>В смысле? Я тебе говорю об одном моменте — который описан графом. Ты сказал в этом графе четыре ветки. Как их увидеть с помощью команд hg? ·>Ещё вопрос. Почему ты выбрал именно {h, i, j, k}? Чем {i, j, k}, {h, i, j}, {g, h, i, j, k} плохи? Тоже вроде линии.
Если ты имеешь в виду момент последней ревизии, то к нему останется только одна ветка, в которую сольются предыдущие. )
_>>>>Ну вот работаю над каким-то проектом, решил проверить некое решение, закодировал, убедился что оно сейчас не подходит (но код полезный и пригодится в будущем), зафиксировал его в виде ревизии, откатился назад на одну ревизий и пошёл работать дальше, создавая новые ревизии. При этом у меня там _>>·>git stash _>>Так можно (это будет hg shelve), но это даже не близко к тому, что я описал. Как мне к примеру воспользоваться этим кодом из соседнего репозитория? ) ·>Да, когда шлёшь что-то другому репозиторию — надо создать имя. Иначе тому другому может пушить кто-то ещё и получится жуткий бардак.
Ну т.е. чтобы создать отросток в одну ревизию с неким альтернативным вариантом кода, мне надо будет придумывать по новому имени ветки каждый раз, правильно? ) И я не смогу например объединить все подобные отростки под одним именем (как можно в том же Mercurial)?
_>>Я уже не говорю о том, чтобы посмотреть разницу с текущей копией и т.п. ·>git diff чем не устраивает?
А он может показать разницу между stash и рабочим каталогом? )
Здравствуйте, ·, Вы писали:
_>>Какая милая система... ))) ·>Рад, что ты начал понимать. Есть "core.ignoreCase". В отличие от этого убожества hg:
Ну и как эта опция поможет мне применить на винде ревизию (созданную в линухе) с двумя файлами отличающимися только регистром? )
_>>Кстати, я помнится наблюдал ещё, что git (как и многий другой древний линуксовый софт) до сих пор ломается на каталога с пробелами в именах. ) Это вообще жесть и убогость. ))) ·>Можно пример? Надеюсь ты знаешь, что имена с пробелами надо заключать в кавычки?
Я не про это. Я про расположение самого Git'а в каталоге с пробелом (типа "Program Files").
Здравствуйте, CrystaX, Вы писали:
CX>[skipped...] CX>"Вы, Шариков, чепуху говорите и возмутительнее всего то, что говорите ее безапелляционно и уверенно". CX>Мне к этому добавить нечего.
Здравствуйте, alex_public, Вы писали:
_>·>Если мы рассматриваем ситуацию, когда всё синхронизировано — то с чего ты взял что данные будут другие? Репы будут идентичны. _>·>А в общем случае да, могут быть другие, как и в hg — tip же может разный в разных репо. _>Давай разберёмся. Для нормальной работы Git необходимо завести минимально две ветки в каждом репозитории: одну общую для синхронизации со всеми
Не со всеми, а с "центральным" репозиторием.
_>и одну собственно для работы. Так вот, даже если каждый член команды и назовёт эту вторую ветку одинаково, то всё равно в них будут разные данные.
По дефолту эта вторая ветка создаётся с тем же именем. Т.е. если никто явно не указал гиту другое имя, то оно будет совпадать.
Если же кто-то что-то нахитрил и изменил имя, всё равно сам граф будет идентичный, просто будет видно, что имя изменено.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, alex_public, Вы писали:
_>>>Я тебе описал наиболее продуманные решения. Но тебя никто не заставляет ими пользоваться. Может приделывать имя на каждое микроветвление или вести основные ветки через закладки. Делай как тебе нравится. ))) _>·>Т.е. если я захочу в своём клоне делать всё через закладки, а ты в своём — через имена, то мы без проблем сможем обмениваться изменениями друг с другом? У нас ведь DVCS, каждый волен работать как ему нравится. _>Без проблем. ) Правда я тогда буду видеть твои закладки, а ты будешь видеть мои ветки. ))) Правда закладки можно и локальные сделать...
И наймём третьего, чтобы букмарки с ветками с тегами и с шелфом и т.п. синхронизировал.
_>>>·>Опубликовать в удалённый репозиторий, или, что аналогично, затащить (fetch) из удалённого. Чтобы передать знание о том, что я решил считать релиз-кандидатом. _>>>Эм, т.е. ты снова пытаешься просто повесить некую метку на конкретную ревизию с помощью создания именованной ветки? ) Жесть, вот что привычки к git'у делают. ))) _>·>Т.е. именованную ветку я "как мне нравится" уже не могу. Что-то ты себе противоречишь. Так "как нравится" или как разработчики hg решили? _>Ну формально то как раз можешь, но это бред. Для таких целей теги есть)
Чем теги от букмарок отличаются?
_>>>Так это смотря в какой момент времени смотреть) В разные моменты будут разные ответы. ) _>·>В смысле? Я тебе говорю об одном моменте — который описан графом. Ты сказал в этом графе четыре ветки. Как их увидеть с помощью команд hg? _>·>Ещё вопрос. Почему ты выбрал именно {h, i, j, k}? Чем {i, j, k}, {h, i, j}, {g, h, i, j, k} плохи? Тоже вроде линии. _>Если ты имеешь в виду момент последней ревизии, то к нему останется только одна ветка, в которую сольются предыдущие. )
Какой ещё момент? Пусть тебе на read only CD дали hg репо, граф которого я изобразил и попросили посчитать и перечислить ветки. Это так сложно?
_>>>Так можно (это будет hg shelve), но это даже не близко к тому, что я описал. Как мне к примеру воспользоваться этим кодом из соседнего репозитория? ) _>·>Да, когда шлёшь что-то другому репозиторию — надо создать имя. Иначе тому другому может пушить кто-то ещё и получится жуткий бардак. _>Ну т.е. чтобы создать отросток в одну ревизию с неким альтернативным вариантом кода,
А если не отросток? Не diverged т.е.?
_> мне надо будет придумывать по новому имени ветки каждый раз, правильно? )
uuid используй или хеш какой-нибудь, если думать лень.
_> И я не смогу например объединить все подобные отростки под одним именем (как можно в том же Mercurial)?
Для чего под одним именем объединять-то? Чтобы всех запутать?
_>>>Я уже не говорю о том, чтобы посмотреть разницу с текущей копией и т.п. _>·>git diff чем не устраивает? _>А он может показать разницу между stash и рабочим каталогом? )
git diff stash@{13}
неожиданно, правда?
Любопытно как это будет в hg.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, alex_public, Вы писали:
_>>>Какая милая система... ))) _>·>Рад, что ты начал понимать. Есть "core.ignoreCase". В отличие от этого убожества hg: _>Ну и как эта опция поможет мне применить на винде ревизию (созданную в линухе) с двумя файлами отличающимися только регистром? )
Пофиксить ревизию можно хотя бы, избавившись от одного из файлов.
_>>>Кстати, я помнится наблюдал ещё, что git (как и многий другой древний линуксовый софт) до сих пор ломается на каталога с пробелами в именах. ) Это вообще жесть и убогость. ))) _>·>Можно пример? Надеюсь ты знаешь, что имена с пробелами надо заключать в кавычки? _>Я не про это. Я про расположение самого Git'а в каталоге с пробелом (типа "Program Files").
Сколько себя не помню, официальный "Git for Windows" всегда ставился в "Program Files" или "Program Files (x86)" — проблем не наблюдал.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, netch80, Вы писали:
N>Боянное верхоглядское делание выводов на основании недочтения с твоей стороны. Или покажи живой пример.
Сталкивался на практике с таким поведением гита. Когда резет делает переносы "как у другого разраба который их коммитил", а потом мой гит начинает кричать что файлы поменяны, надо коммитить.
Дико достает одним словом.
_>Кстати, я помнится наблюдал ещё, что git (как и многий другой древний линуксовый софт) до сих пор ломается на каталога с пробелами в именах. ) Это вообще жесть и убогость. )))
Ну с учетом того что система писалась Линусом для личных нужд Линуса это нормально
W>>·>Ещё можно просто по sha1 обращаться. Можно reflog полистать, можно в stash закинуть. Вариантов куча. W>> И ни один неудобен для человека. ·>В каком случае ты столкнёшься с этим неудобством? Опиши сценарий.
Кейсы когда надо git reflog не знаешь?
Сам же в треде приводил
Здравствуйте, woah, Вы писали:
C>>Что значит "откатиться"? У нас не централизованная VCS, некуда откатываться. W>Это значит иметь возможность сделать чекаут коммита HEAD-N и получить возможность осмотреться внутри репозитория годичной давности. Какие ветки были, кто куда коммитил и все такое.
А зачем? Ну сделай себе такой pre-commit hook на сервере: "git branch -a | sort > mybranches; git commit -am `date`".
W>Граф гита — то еще убожество в таких ситуациях.
Я не очень понимаю в чём проблема у аффтора.
W>В 99% продакшн энвайраментах есть центральная репа. Ее и можно считать основной.
А зачем?
W>У меня лично не было ни разу нужды заводить больше 1 remote репозитория. Поэтому все эти фичи децентрализованные только мешают и усложняют повседневные задачи.
Сожалею, в большой команде, значит, не работали.
W>Пользоваться же надо теми системами которые хорошо поддерживаются твоей IDE. В случае C++/C# под VS это не так.
Ну дык, а ещё можно привязать батарею цепью к ногам и не ходить дальше того, что разрешает цепь.
C>>Можно посмотреть какие в репозитории были названия голов в данное время. W>Как? Только чтобы удобно, а не а-ля полистать reflog
Какая конкретно задача-то?
Здравствуйте, woah, Вы писали:
N>>Боянное верхоглядское делание выводов на основании недочтения с твоей стороны. Или покажи живой пример.
W>Сталкивался на практике с таким поведением гита. Когда резет делает переносы "как у другого разраба который их коммитил", а потом мой гит начинает кричать что файлы поменяны, надо коммитить.
Повторюсь ещё раз, если с первого раза недостаточно. Покажи пример, как это после git reset --hard приведёт к тому, что git status покажет изменённые файлы. Все прочие рассказы про то, как вы бороздили просторы больших и малых интернетов, меняя на ходу концы строк, коту под хвост.
Здравствуйте, woah, Вы писали:
W>Здравствуйте, ·, Вы писали:
W>·>Сколько себя не помню, официальный "Git for Windows" всегда ставился в "Program Files" или "Program Files (x86)" — проблем не наблюдал.
W>Этих гитов под виндос как собак развелось. W>Каждый настраивается как бог на душу положит. Поди разберись кто из них официальный
Ну поставь винду со ZverCD и потребуй официальной поддержки.
W>Вообще отмазка про неправильный дистрибутив весьма характерна именно для линуксоидов. Позволяет бесконечно вилять задом от неудобных вопросов
"Виляет задом" тот, кто ставит ХЗ что и потом кричит про всё средство в целом.
Здравствуйте, woah, Вы писали:
N>>Нет. То, что по нему пишут книги, всего лишь показывает его популярность. W>Нет. Книги пишут по всему чему попало.
По никому не нужному — не пишут. Или не печатают.
W>Но гит это первая система при встрече с которой я начал читать эти книги чтобы заставить это работать
Значит, не сложилось. Соболезную. Видимо, коллега Средняя Точка был прав, что у Hg тяжкое наследие centralized VCS, но я этого не прочувствовал.
Здравствуйте, CrystaX, Вы писали:
N>>Ситуацию, когда в пределах одной рабочей копии status показывает изменение, а hard reset его не сбрасывает, это не даст. CX>Я подобное наблюдал, когда в репозиторий были добавлены файлы с разным содержимым, но именами, отличающимися только регистром.
Хм, вот это таки может быть вариантом. Надо запомнить, спасибо.
Здравствуйте, woah, Вы писали:
W>>>·>Ещё можно просто по sha1 обращаться. Можно reflog полистать, можно в stash закинуть. Вариантов куча. W>>> И ни один неудобен для человека. W>·>В каком случае ты столкнёшься с этим неудобством? Опиши сценарий. W>Кейсы когда надо git reflog не знаешь?
reflog обычно нужен для того, чтобы посмотреть какие действия и когда делал, типа "какую ветку я вчера утром смотрел?". И, иногда, откатиться к предыдущим состояниям после того, как понял, что сделал что-то не так, типа "хотел смержить ту ветку, а смержил эту", или "ну и накой я удалил тот коммит?!".
В hg аналогов нет.
W>Сам же в треде приводил
Напомни. Не знаю что ты имеешь в виду.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Из свежих "приятностей". У коллег стали пропадать изменения при слиянии веток в мастера. Стал разбираться и выяснилось что проблема возникает из за EOL. Выяснилось что алгоритм "странного мерджа" такой: человек работает в ветке, комитит,переключается на мастера, студия говорит о неконсистентных EOL в файле например 1.txt и предлагает исправить, человек нажимает да, после чего успешно мерджит ветку и мастера, при этом изменения из ветки сделанные в файле 1.txt не попадают в мердж.
Здравствуйте, Mazenrab, Вы писали:
M>Из свежих "приятностей". У коллег стали пропадать изменения при слиянии веток в мастера. Стал разбираться и выяснилось что проблема возникает из за EOL. Выяснилось что алгоритм "странного мерджа" такой: человек работает в ветке, комитит,переключается на мастера, студия говорит о неконсистентных EOL в файле например 1.txt и предлагает исправить, человек нажимает да, после чего успешно мерджит ветку и мастера, при этом изменения из ветки сделанные в файле 1.txt не попадают в мердж. M>Почему так происходит?
Трудно сказать. Надо смотреть что происходит конкретно, "git log -p" должен многое рассказать.
Могу предположить, что когда ветки переключатся, Студия "забывает" перечитать файлы с диска в память редактора и затирает изменения при "исправлении" EOL, человек не обращает на это внимание и коммитит это как результат мержа.
Самым правильным будет разобраться откуда у вас проблемы с EOL и пофиксить их.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Похоже что так и было в студии, но конечно это большой сюрприз. Сейчас поставил у себя autocrlf=false и склонировал репозиторий. Выяснилось что часть файлов в репозитории имеет LF формат EOL. Очень странно — значит у кого-то был autocrlf=false c которым он коммитил так что ли получается? А вот как теперь наладить чтобы у всех был CRLF не очень понятно. Мой первый порыв был сконвертить все EOL в CRLF и закомитить их в мастера. Но это ничего не даст веточникам. Как быть?
Здравствуйте, Mazenrab, Вы писали:
M>Похоже что так и было в студии, но конечно это большой сюрприз.
Да это вечная проблема. Если юзеры сидят под разными операционками, то конфликты неизбежны. Особенно под виндой. Скажем, если ты работаешь с родными виндовыми программами, то они ожидают crlf, а если скажем cygwin, то он хочет lf. Или если под виндой собираешь .tag.gz, который затем шлётся на линукс.
M>Сейчас поставил у себя autocrlf=false и склонировал репозиторий. Выяснилось что часть файлов в репозитории имеет LF формат EOL. Очень странно — значит у кого-то был autocrlf=false c которым он коммитил так что ли получается? А вот как теперь наладить чтобы у всех был CRLF не очень понятно. Мой первый порыв был сконвертить все EOL в CRLF и закомитить их в мастера. Но это ничего не даст веточникам. Как быть?
Обычно договорённость такая, что в репозитории всегда lf, а юзеры должны настраивать свои репозитории так, чтобы в рабочей копии были желаемые eols.
А сейчас можно пофиксить все ветки "главного" репозитория и навесить на него хук, чтобы он отпинывал все коммиты с crlf. В интернетах думаю можно найти готовый скрптик... или несложно написать самому. Правда непонятно как отличать текстовые файлы от бинарных, можно попробовать трюки типа этого...
UPD: А, что-то торможу. Ведь git diff покажет crlf, а бинарики он игнорирует. Т.е. в хуке надо просто грепнуть выхлоп git diff на отсутствие crlf
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
_>>и одну собственно для работы. Так вот, даже если каждый член команды и назовёт эту вторую ветку одинаково, то всё равно в них будут разные данные. ·>По дефолту эта вторая ветка создаётся с тем же именем. Т.е. если никто явно не указал гиту другое имя, то оно будет совпадать. ·>Если же кто-то что-то нахитрил и изменил имя, всё равно сам граф будет идентичный, просто будет видно, что имя изменено.
Откуда он будет одинаковым то? ))) Ну вот покажи мне git log --graph из первого и из второго репозитория для подобного простейшего случая (инициализация, потом по одной параллельной ревизии в каждом репозитории, потом слияние), про который тут говорил (где в Mercurial обходятся вообще только анонимными ветками). Могу показать пример такого графа для Mercurial. )
Здравствуйте, ·, Вы писали:
_>>·>Т.е. именованную ветку я "как мне нравится" уже не могу. Что-то ты себе противоречишь. Так "как нравится" или как разработчики hg решили? _>>Ну формально то как раз можешь, но это бред. Для таких целей теги есть) ·>Чем теги от букмарок отличаются?
Закладки — это указатель, который автоматически скачет на следующую ревизию при фиксации. А тег никуда не скачет, но зато может просто редактироваться пользователем.
_>>Если ты имеешь в виду момент последней ревизии, то к нему останется только одна ветка, в которую сольются предыдущие. ) ·>Какой ещё момент? Пусть тебе на read only CD дали hg репо, граф которого я изобразил и попросили посчитать и перечислить ветки. Это так сложно?
Ну так я тебе уже ответил только что. )
_>>·>Да, когда шлёшь что-то другому репозиторию — надо создать имя. Иначе тому другому может пушить кто-то ещё и получится жуткий бардак. _>>Ну т.е. чтобы создать отросток в одну ревизию с неким альтернативным вариантом кода, ·>А если не отросток? Не diverged т.е.?
Не понял, не отросток, а что тогда? )
_>> мне надо будет придумывать по новому имени ветки каждый раз, правильно? ) ·>uuid используй или хеш какой-нибудь, если думать лень.
Да, очень удобно. ))) Как раз принцип Оккама в действие. )))
_>> И я не смогу например объединить все подобные отростки под одним именем (как можно в том же Mercurial)? ·>Для чего под одним именем объединять-то? Чтобы всех запутать?
Почему запутать? Как раз удобно все эксперименты держать под одним именем experimental)
_>>·>git diff чем не устраивает? _>>А он может показать разницу между stash и рабочим каталогом? ) ·>git diff stash@{13} ·>неожиданно, правда?
Это разве покажет не разницу с последней ревизией? )
Здравствуйте, ·, Вы писали:
_>>Ну и как эта опция поможет мне применить на винде ревизию (созданную в линухе) с двумя файлами отличающимися только регистром? ) ·>Пофиксить ревизию можно хотя бы, избавившись от одного из файлов.
Ага, под линухом. А как мне исправить ситуацию из под винды? )
·>Сколько себя не помню, официальный "Git for Windows" всегда ставился в "Program Files" или "Program Files (x86)" — проблем не наблюдал.
Здравствуйте, netch80, Вы писали:
_>>Это ты про что (в Mercurial же нет понятия staging), про возможность показать что будет зафиксировано или про какие-то дополнения к работе расширения record? ) N>Вот я читаю `hg help record` и вижу описание того, что она "interactively select changes to commit". Где находятся эти изменения, когда hg record уже отработала, а hg commit ещё не запускалась? Это то, по чему я предположил существование staging area. Видишь ли, в отличие от предположений коллеги woah, я читаю документацию и верю ей. N>А вот сейчас проверил — hg record сразу коммитит. Значит, враньё с самого начала в документации — фраза "interactively select changes to commit" должна звучать на самом деле примерно как "commit interactively selected changes". Да, ты прав, всё ещё хуже, чем я предположил — в Hg нет staging, а в документации ещё один кусок гнилого обмана. N>(А ещё в таком случае интересно, зачем такую пустую банальность, не дающую никаких потенциально неожиданных свойств, как staging area, прятать в выключенные по умолчанию расширения. Конспирология, но у меня нет никаких идей, кроме как то, что авторы Hg считают своих пользователей за полных дебилов, которые всё протеряют.)
Собственно hg record был в старых версиях Mercruial, а в новых просто hg commit -i. Так что всё становится до конца логично и понятно, и без всяких расширений.
И это намного удобнее реализации в Git, т.к. полностью решает описанную тобой задачку (фиксации только части изменений рабочего каталога) без введения каких-либо дополнительных ненужных сущностей типа stage.
_>>А почему это грязнокодинг? ) Разве нельзя добиться нужного результата не меняя историю (например та же команда hg backout демонстрирует пример подобного)? В итоге у тебя будет всё красиво и история сохранится. Или тебе надо скрыть из истории все следы косяков и т.п.? ))) N>Кроме эмоциональных оценок в терминах "скрыть" и "косяк", всё верно. Первичная история — до начала взаимодействия с другими людьми — не должна быть историей косяков, она должна быть историей правильно сформированных и сгруппированных изменений. Ты предлагаешь хоть и маленький и временный, но _продукт_. Своей работы. Никого не должно волновать, сколько промежуточных косяков ты допускаешь по дороге, пока это укладывается в ограничения по ресурсам — на суд коллег должны быть вынесены результаты.
Похоже что ты забыл (или может вообще не знал?) один из главных научных принципов "отрицательный результат — тоже результат". ) Это же вполне касается и инженерной работы — надо документировать весь процесс разработки, в том числе и подробно описывать все тупики.
N>А эти результаты в нормальном варианте строятся в цепочку изменений (в сложном — несколько цепочек, но каждая должна быть логически закончена), так, что каждое из них N>* делает только одно из набора: стилевые правки, рефакторинг, функциональное изменение N>* или сделано вручную, или автоматически (как автоформаттером), кроме случаев, когда за автоформаттером надо подчищать N>* функциональное изменение по возможности максимально однородно по сути действий N>и только такое заслуживает передачи в общее репо так, чтобы не было чего мучительно стыдиться.
Это похоже на какие-то опенсорсные заморочки. )))
N>И реально сложное изменение такого рода не сделать без возможности разделения, перестановки, слияния коммитов, выбора нужного из локальных изменений. А если какое-то современное средство прячет эту функциональность поглубже (отдельные команды, выключенные по умолчанию расширения), то его авторы целенаправленно воспитывают ламеров и говнокодеров.
У меня противоположное мнение. )
N>>>Она не базовая. Базовая это цепочки коммитов. А фиксация безымянных голов это уже расширение. И это ещё раз показывает следствия безумного бардака с терминологией. _>>А как можно организовать цепочки без фиксации? ) N>Ключевое слово было "безымянных". Не делай вид, что не понял этого.
Ну так в Git же цепочки тоже внутри безымянные (у них есть только хэш, как и в Mercurial), а имена вешаются поверх (как закладки в Mercurial).
Здравствуйте, alex_public, Вы писали:
_>>>и одну собственно для работы. Так вот, даже если каждый член команды и назовёт эту вторую ветку одинаково, то всё равно в них будут разные данные. _>·>По дефолту эта вторая ветка создаётся с тем же именем. Т.е. если никто явно не указал гиту другое имя, то оно будет совпадать. _>·>Если же кто-то что-то нахитрил и изменил имя, всё равно сам граф будет идентичный, просто будет видно, что имя изменено.
_>Откуда он будет одинаковым то? ))) Ну вот покажи мне git log --graph из первого и из второго репозитория для подобного простейшего случая (инициализация, потом по одной параллельной ревизии в каждом репозитории, потом слияние), про который тут говорил (где в Mercurial обходятся вообще только анонимными ветками). Могу показать пример такого графа для Mercurial. )
А почему оно будет разным-то?
Как видишь — графы после синхронизации идентичны. Единственная разница — наличие в other веток с префиксом origin/, т.к. я other репозиторий клонировал. Если бы тоже создал новый через init, то remote-а и его веток не было бы.
Заметь — мне вообще не пришлось делать что-то с ветками, и никаких анонимных веток не понадобилось.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, netch80, Вы писали:
N>Это _распределённая_ система. Если удивляет, что у разных людей разное содержание — хм, я боюсь, тут вообще не centralized VCS должна помочь, а вообще файловая шара. N>Это не наезд, но попытка определить границы того, что тебе не нравится, что "у каждого репозиторий выглядит по своему", значит, для тебя он у всех должен быть одинаковым.
Ну так mercurial то предоставляет все возможности распределённой системы и при этом в дефолтном режиме создаёт одинаковые репозитории (в состояние синхронизации). )))
_>>Да тут вот народ рядом жалуется на то, что при рефакторинге git делает некую ересь. ) N>Он не делает никакой "ереси", это опять попытка втихую навесить эмоциональный ярлык (<sarcasm>branch, в терминах Hg</sarcasm>). А что именно он делает — уже обсудили и объяснили в деталях.
Мне понятно что он делает. Только вот он не справляется, как тут подробно показали. Аналогичный автоматический инструмент в Mercurial может тоже не справится, но кроме него тут есть и удобный ручной вариант, который полностью решает проблему. )
Здравствуйте, netch80, Вы писали:
N>У Git(*) нет проблем с пробелами в именах. Как и у подавляющего большинства юниксовых средств, где эта проблема давно отработана на всех уровнях.
Это не так. В линухе тоже натыкался. Опять же говорю не про передачу в качестве параметра имени файла с пробелами, а про запуск различных программ/скриптов из каталога с пробелами в имени. Вот помнится тот же autotools от этого корёжило. )
N>Проблема пробелов в именах существует (нежданчик, да?) в Windows, которая эти самые имена с пробелами использует значительно шире (начиная с знаменитой PROGRA~1, ой, простите, "Program Files"). Вызвана она тем, что:
Что-то не помню проблем с современным виндовым софтом. )
N>3. Посредники вроде cmd.exe ещё больше усложняют ситуацию. N>Передать в sh аргумент в вызываемую команду без репарсинга тривиально — "$x" вместо $x. Передать исходный набор аргументов — "$@". Аналога для Windows не вижу, или он настолько прочно спрятан внутрь, что не гуглится.
%* если ты говоришь про bat файлы) И для их запуска не требуется вызывать cmd руками (так же как и в линухе не обязательно руками писать sh).
N>Реально, я сталкивался со средствами, которые просто отказывались ставиться в Program Files и требовали для себя пути без пробелов. Видимо, их авторы задолбались.
И я сталкивался. Ну точнее они не отказывались, но настойчиво рекомендовали (и потом частенько глючили, если наплевать на рекомендации). Так вот все они представляли собой портированный из Линуха софт.
Здравствуйте, ·, Вы писали:
_>>Откуда он будет одинаковым то? ))) Ну вот покажи мне git log --graph из первого и из второго репозитория для подобного простейшего случая (инициализация, потом по одной параллельной ревизии в каждом репозитории, потом слияние), про который тут говорил (где в Mercurial обходятся вообще только анонимными ветками). Могу показать пример такого графа для Mercurial. ) ·>А почему оно будет разным-то?
Ну так ты тут обошёлся только одной веткой и всё. ) Для реальной работы команды такое естественно не пойдёт. ) Это же уже обсуждалось выше.
··>Как видишь — графы после синхронизации идентичны. Единственная разница — наличие в other веток с префиксом origin/, т.к. я other репозиторий клонировал. Если бы тоже создал новый через init, то remote-а и его веток не было бы.
Здравствуйте, alex_public, Вы писали:
_>>>Откуда он будет одинаковым то? ))) Ну вот покажи мне git log --graph из первого и из второго репозитория для подобного простейшего случая (инициализация, потом по одной параллельной ревизии в каждом репозитории, потом слияние), про который тут говорил (где в Mercurial обходятся вообще только анонимными ветками). Могу показать пример такого графа для Mercurial. ) _>·>А почему оно будет разным-то? _>Ну так ты тут обошёлся только одной веткой и всё. ) Для реальной работы команды такое естественно не пойдёт. ) Это же уже обсуждалось выше.
На уровне команд я вообще без веток обошелся. Но они использовались неявно, в репозиториях они есть.
Я не понимаю какой ты сценарий тогда хочешь, если будет 10 other репозиториев — ничего принципиально не поменяется.
_>··>Как видишь — графы после синхронизации идентичны. Единственная разница — наличие в other веток с префиксом origin/, т.к. я other репозиторий клонировал. Если бы тоже создал новый через init, то remote-а и его веток не было бы. _>О том и речь)
О чём речь?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>В смысле что на первых порах они с гитхабом активно конкурировали и были примерно одного уровня популярности. Но потом гитхабовцы их переплюнули за счет активного добавления новых фич. Битбакет задергался, но поезд уже ушел, и сейчас сравнивать их популярность просто смешно.
Я бы даже углубил эту мысль на собственном опыте. Лет ... назад гит был коряв и ужасен, особенно под виндой, Hg же вполне себе удобоварим. И в этот момент вылезает на сцену ГитХаб и начинает хостит 146% нового кода. Волей не волей ежей заставили кушать, а две столь похожие системы держать в голове влом. Теперь оно конечно обкаталось, но осадочек до сих пор остался.
Здравствуйте, alex_public, Вы писали:
_>>>Ну и как эта опция поможет мне применить на винде ревизию (созданную в линухе) с двумя файлами отличающимися только регистром? ) _>·>Пофиксить ревизию можно хотя бы, избавившись от одного из файлов. _>Ага, под линухом. А как мне исправить ситуацию из под винды? )
В отличие от hg, который грохнется уже при попытке запуллить changeset с такой ревизией, git спокойно всё сделает, но будет указывать, что один из файлов изменён (т.к. контент обоих файлов из репо будет записан в один и тот же файл на диске), сразу после чекаута. А потом — как обычно, удалить ненужное, закоммитить.
_>·>Сколько себя не помню, официальный "Git for Windows" всегда ставился в "Program Files" или "Program Files (x86)" — проблем не наблюдал. _>Это вот этот https://habrahabr.ru/post/255443/ вот, да? )))
Ы?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
_>>·>Пофиксить ревизию можно хотя бы, избавившись от одного из файлов. _>>Ага, под линухом. А как мне исправить ситуацию из под винды? ) ·>В отличие от hg, который грохнется уже при попытке запуллить changeset с такой ревизией, git спокойно всё сделает, но будет указывать, что один из файлов изменён (т.к. контент обоих файлов из репо будет записан в один и тот же файл на диске), сразу после чекаута.
Т.е. он даже не предупредит пользователя о проблеме и тот будет бегать по форумам в поисках ответа почему у него файл сам меняется магическим образом? ))) Как мило... )))
Что касается Mercurial, то естественно синхронизируется всё вообще без проблем (т.к. формат хранилища никак не зависит от файловой системы). А вот при попытке исполнения hg update ты получишь такое сообщение: "abort: case-folding collision between a.txt and A.txt". Всё информативно, понятно и удобно.
·>А потом — как обычно, удалить ненужное, закоммитить.
Ну так а можно подробности, каким собственно образом это будет реализовываться? ) И да, терять содержимое обоих файлов в следующей ревизии естественно нельзя... )
Да, в Mercurial кстати есть ещё и расширения для автоматического исправления таких вещей. Хотя на мой взгляд это уже перебор)))
_>>·>Сколько себя не помню, официальный "Git for Windows" всегда ставился в "Program Files" или "Program Files (x86)" — проблем не наблюдал. _>>Это вот этот https://habrahabr.ru/post/255443/ вот, да? ))) ·>Ы?
Прочитал статью? ) Там в каждом разделе можно найти по шедевру удобства использования Git под виндой. )))
Здравствуйте, alex_public, Вы писали:
_>>>·>Пофиксить ревизию можно хотя бы, избавившись от одного из файлов. _>>>Ага, под линухом. А как мне исправить ситуацию из под винды? ) _>·>В отличие от hg, который грохнется уже при попытке запуллить changeset с такой ревизией, git спокойно всё сделает, но будет указывать, что один из файлов изменён (т.к. контент обоих файлов из репо будет записан в один и тот же файл на диске), сразу после чекаута. _>Т.е. он даже не предупредит пользователя о проблеме и тот будет бегать по форумам в поисках ответа почему у него файл сам меняется магическим образом? ))) Как мило... )))
Честно говоря не знаю как оно выглядит. Винды под рукой сейчас нет...
_>Что касается Mercurial, то естественно синхронизируется всё вообще без проблем (т.к. формат хранилища никак не зависит от файловой системы). А вот при попытке исполнения hg update ты получишь такое сообщение: "abort: case-folding collision between a.txt and A.txt". Всё информативно, понятно и удобно.
А что делать-то?
_>·>А потом — как обычно, удалить ненужное, закоммитить. _>Ну так а можно подробности, каким собственно образом это будет реализовываться? )
git rm или git mv.
_> И да, терять содержимое обоих файлов в следующей ревизии естественно нельзя... )
Так история же иммутабельная, как можно потерять что-то закоммиченное...
_>>>Это вот этот https://habrahabr.ru/post/255443/ вот, да? ))) _>·>Ы? _>Прочитал статью? ) Там в каждом разделе можно найти по шедевру удобства использования Git под виндой. )))
"В поставке гит нет rsync и староватый perl, а ещё кофе не варит".
А в поставке hg какой версии rsync?
Дальше читать лениво. Давай конкретно.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
_>>Ну так ты тут обошёлся только одной веткой и всё. ) Для реальной работы команды такое естественно не пойдёт. ) Это же уже обсуждалось выше. ·>На уровне команд я вообще без веток обошелся. Но они использовались неявно, в репозиториях они есть. ·>Я не понимаю какой ты сценарий тогда хочешь, если будет 10 other репозиториев — ничего принципиально не поменяется.
Да, это я чуть спутал. Это я с netch80 обсуждал, а не с тобой, насчёт минимального режима по 2 ветки на репозиторий для Git'a. )
_>>··>Как видишь — графы после синхронизации идентичны. Единственная разница — наличие в other веток с префиксом origin/, т.к. я other репозиторий клонировал. Если бы тоже создал новый через init, то remote-а и его веток не было бы. _>>О том и речь) ·>О чём речь?
Ну смотри. Вот допустим у нас кто-то сделал не одну ревизию относительно init, а две, причём параллельные (для этого в git придётся ещё одну ветку завести, да?). А теперь он хочет сделать слияние одной из этих ревизий с чужими результатами (как в изначальном сценарии). Теперь представь себе как будет выглядеть весь процесс в каждом из двух случаев (ревизия_алт1 или ревизия_алт2) и насколько будут похожими после этого выглядеть репозитории участников.
Да, кстати, а в Mercurial не только итоговые графы будут одинаковые, но и сам процесс синхронизации/слияния не будет отличаться для этих двух параллельных ревизий. А в Git?)))
Здравствуйте, ·, Вы писали:
_>>Т.е. он даже не предупредит пользователя о проблеме и тот будет бегать по форумам в поисках ответа почему у него файл сам меняется магическим образом? ))) Как мило... ))) ·>Честно говоря не знаю как оно выглядит. Винды под рукой сейчас нет...
Ты же сам только что написал "git спокойно всё сделает". ) Да и народ тут как раз писал об этом как об известной причине таинственных багов. )))
_>>·>А потом — как обычно, удалить ненужное, закоммитить. _>>Ну так а можно подробности, каким собственно образом это будет реализовываться? ) ·>git rm или git mv.
Это ты просто помечаешь файл как удалённый, а не решаешь проблему.
_>> И да, терять содержимое обоих файлов в следующей ревизии естественно нельзя... ) ·>Так история же иммутабельная, как можно потерять что-то закоммиченное...
Я имею в виду, что если у тебя в кривой линуксовой ревизии были файлы a.txt и A.txt, то после исправления на винде у тебя в ревизии очевидно должно быть что-то вроде a.txt (с содержимым a.txt, а не некой рандомной хренью, создаваемой git'ом) и a1.txt (с содержимым А.txt), а не просто отсутствие файла A.txt.
_>>>>Это вот этот https://habrahabr.ru/post/255443/ вот, да? ))) _>>·>Ы? _>>Прочитал статью? ) Там в каждом разделе можно найти по шедевру удобства использования Git под виндой. ))) ·>"В поставке гит нет rsync и староватый perl, а ещё кофе не варит". ·>А в поставке hg какой версии rsync? ·>Дальше читать лениво. Давай конкретно.
Если кратко, то под винду существует множество реализаций Git'а и при этом каждая убога по своему. ))) Да, а последний раздел (про 64-ёх битный вариант) я вообще без смеха читать не мог. )))
Здравствуйте, ·, Вы писали:
_>>·>Чем теги от букмарок отличаются? _>>Закладки — это указатель, который автоматически скачет на следующую ревизию при фиксации. А тег никуда не скачет, но зато может просто редактироваться пользователем. ·>А tip это тег, который скачет как закладка? тегладка (tagmark)? Всё чудесатее и чудесатее.
Ну да, типа того. ) По идее tip было бы логично реализовать как закладку, но изначально их в Mercurial просто не было. )))
_>>Ну так я тебе уже ответил только что. ) ·>Ты ответил, что их четыре. Теперь одна. И ты так и не объяснил по какому принципу ты выбрал эти четыре и как оно согласуется с определением в документации.
Я же тебе уже отвечал и не один раз. Утомило уже. Последняя попытка... В разные периоды жизни существовали разные ветки. Они же не фиксированные навсегда сущности, а могут появляться и пропадать через разделения/слияния. Соответственно на момент последней ревизии у тебя в репозитории одна ветка. А вот за всю историю их там было больше. )
_>>·>А если не отросток? Не diverged т.е.? _>>Не понял, не отросток, а что тогда? ) ·>"the middle of a development line, not necessarily at a diverging point"
И? ) Что это должно было означать? )
_>>Да, очень удобно. ))) Как раз принцип Оккама в действие. ))) ·>Если тебе и правда нужен такой сценарий, то напишешь альяс: ·>git config alias.craZyexPerIment "!git branch experimental/`git rev-parse HEAD`" ·>Всё. После этого ·>git craZyexPerIment ·>будет создавать бранчи со случайным именем. ·>Их потом можно всех вывести командой "git branch --list experimental/*" , тоже можно заальясить. ·>Т.е. при желании это реализуется в несколько строчек конфига. И нет этого в стандартной поставке гита потому что это нафиг никому не сдалось, слава Оккаму, что этот анонимный бред отрезали. Такой инструмент — не удобен. Он может быть удобен только в том случае, когда ничего более удобного нет. А в гите есть куча более адекватных инструментов.
Например? )
_>>·>Для чего под одним именем объединять-то? Чтобы всех запутать? _>>Почему запутать? Как раз удобно все эксперименты держать под одним именем experimental) ·>Будет у тебя 20 экспериментов... и как их различать-то?
Вообще то у каждого есть подробное описание в комментарии к ревизии. )))
W>>Это значит иметь возможность сделать чекаут коммита HEAD-N и получить возможность осмотреться внутри репозитория годичной давности. Какие ветки были, кто куда коммитил и все такое. C>А зачем?
Затем чтобы посмотреть чем занималась команда в наследство от которой достался проект. Или команда пока ты был в отпуске.
Хуки ф топку. Должно работать из каробки. Элементарные вещи же.
W>>·>В каком случае ты столкнёшься с этим неудобством? Опиши сценарий. W>>Кейсы когда надо git reflog не знаешь? ·>reflog обычно нужен для того, чтобы посмотреть какие действия и когда делал, типа "какую ветку я вчера утром смотрел?". И, иногда, откатиться к предыдущим состояниям после того, как понял, что сделал что-то не так, типа "хотел смержить ту ветку, а смержил эту", или "ну и накой я удалил тот коммит?!".
Не только. Бывалоча отматаешь бошку ветки на Nкоммитов назад и растишь оттуда. А потом хочешь этот отросток отловить чтобы черрипикнуть оттуда.
Чем кроме рефлога это делать?
Здравствуйте, netch80, Вы писали:
W>>Но гит это первая система при встрече с которой я начал читать эти книги чтобы заставить это работать
N>Значит, не сложилось. Соболезную. Видимо, коллега Средняя Точка был прав, что у Hg тяжкое наследие centralized VCS, но я этого не прочувствовал.
Если бы не сложилось только у меня то еще ладно.
Просто гит кривой и неудобный. С кучей рудиментов и 100500 вариантами сделать одно и то же действие. Ни один из которых неудобен
Здравствуйте, woah, Вы писали:
C>>А зачем? W>Затем чтобы посмотреть чем занималась команда в наследство от которой достался проект. Или команда пока ты был в отпуске.
Ну так и смотри по общей истории веток. Элементарная вещь же, и работает изкаропки.
Здравствуйте, alex_public, Вы писали:
_>·>На уровне команд я вообще без веток обошелся. Но они использовались неявно, в репозиториях они есть. _>·>Я не понимаю какой ты сценарий тогда хочешь, если будет 10 other репозиториев — ничего принципиально не поменяется. _>Да, это я чуть спутал. Это я с netch80 обсуждал, а не с тобой, насчёт минимального режима по 2 ветки на репозиторий для Git'a. )
Минимальный режим — одна ветка. Если ты регулярно синхронизируешься с одним и тем же репозиторием, то имеет смысл (но не обязательно, просто задалбывает каждый раз урл вбивать) добавить его URL как remote, что _автоматически_ создаст удалённые ветки (ветки с префиксом remote/) для отслеживания состояния удалённого репо и состояния синхронизации с ним.
_>>>··>Как видишь — графы после синхронизации идентичны. Единственная разница — наличие в other веток с префиксом origin/, т.к. я other репозиторий клонировал. Если бы тоже создал новый через init, то remote-а и его веток не было бы. _>>>О том и речь) _>·>О чём речь? _>Ну смотри. Вот допустим у нас кто-то сделал не одну ревизию относительно init, а две, причём параллельные (для этого в git придётся ещё одну ветку завести, да?).
Можно не заводить, но тогда эту ревизию будет сложнее найти потом (только неявно, как в hg, читая коммит-сообщения и т.п.) и она может собраться GC через месяц (если хочется, можно увеличить время или вообще отключить).
_>А теперь он хочет сделать слияние одной из этих ревизий с чужими результатами (как в изначальном сценарии). Теперь представь себе как будет выглядеть весь процесс в каждом из двух случаев (ревизия_алт1 или ревизия_алт2)
Да ровно так же. Бранчевание локальное или бранчевание между разыми клонами репов — не отличается вообще никак.
_>и насколько будут похожими после этого выглядеть репозитории участников.
После синхронизации — репы будут идентичны.
_>Да, кстати, а в Mercurial не только итоговые графы будут одинаковые
По дефолту не будут из-за разных номеров ревизий. Или эти номера можно отключить?
_>, но и сам процесс синхронизации/слияния не будет отличаться для этих двух параллельных ревизий. А в Git?)))
Не понимаю на что ты намекаешь. А что будет в git по-твоему?
Короче, я уже перестал понимать что конкретно ты хочешь. Скачай гит, обыграй некий сценарий, сравни его с hg и покажи результаты исследований здесь что там плохо, и мы посмотрим, можно ли улучшить.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, alex_public, Вы писали:
_>>>Т.е. он даже не предупредит пользователя о проблеме и тот будет бегать по форумам в поисках ответа почему у него файл сам меняется магическим образом? ))) Как мило... ))) _>·>Честно говоря не знаю как оно выглядит. Винды под рукой сейчас нет... _>Ты же сам только что написал "git спокойно всё сделает". ) Да и народ тут как раз писал об этом как об известной причине таинственных багов. )))
Я не знаю как git реагирует, попробую когда-нибудь на досуге, самому интересно. Но не удивлюсь, что это выглядит не очень понятно по сравнению с hg. Как я понял, в git это никогда не было проблемой. Раньше в hg это было критическим багом. Ранние версии hg просто падали и было невозможно использовать репозиторй вообще. Поэтому они пофиксили багу добавив явную поддержку этого сценария. В git, похоже, просто никто не заморачивался.
_>>>·>А потом — как обычно, удалить ненужное, закоммитить. _>>>Ну так а можно подробности, каким собственно образом это будет реализовываться? ) _>·>git rm или git mv. _>Это ты просто помечаешь файл как удалённый, а не решаешь проблему.
А как ещё её можно решить?
_>>> И да, терять содержимое обоих файлов в следующей ревизии естественно нельзя... ) _>·>Так история же иммутабельная, как можно потерять что-то закоммиченное... _>Я имею в виду, что если у тебя в кривой линуксовой ревизии были файлы a.txt и A.txt, то после исправления на винде у тебя в ревизии очевидно должно быть что-то вроде a.txt (с содержимым a.txt, а не некой рандомной хренью, создаваемой git'ом) и a1.txt (с содержимым А.txt), а не просто отсутствие файла A.txt.
"git mv A.txt a1.txt"?
_>>>Прочитал статью? ) Там в каждом разделе можно найти по шедевру удобства использования Git под виндой. ))) _>·>"В поставке гит нет rsync и староватый perl, а ещё кофе не варит". _>·>А в поставке hg какой версии rsync? _>·>Дальше читать лениво. Давай конкретно. _>Если кратко, то под винду существует множество реализаций Git'а и при этом каждая убога по своему. )))
В чём официальная убога? "Устарвешая версия" — да, немного отстаёт от линуховой, но незначительно, на пару месяцев по моим наблюдениям.
_>Да, а последний раздел (про 64-ёх битный вариант) я вообще без смеха читать не мог. )))
И что?.. egit/jgit это pure java имплементации, оно изначально было сделано для работы с репозиториями из ява-приложений, чтобы не звать внешние тулзы или нативные либы. Для hg такого и нет.
Остальное — какие-то эксперименты, что в этом плохого? Не нравится — используй официальную версию.
64 бита — хз, понятия не имею, в последнее время проблем вроде нет. Хотя не удивлюсь что были, из-за разного понимания 64 под виндой и линухом.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, alex_public, Вы писали:
_>·>А tip это тег, который скачет как закладка? тегладка (tagmark)? Всё чудесатее и чудесатее. _>Ну да, типа того. ) По идее tip было бы логично реализовать как закладку, но изначально их в Mercurial просто не было. )))
Вот это в hg и не нравится. Нет концептуальной целостности — макароны слабосвязанных фич и нечёткой терминологии.
_>>>Ну так я тебе уже ответил только что. ) _>·>Ты ответил, что их четыре. Теперь одна. И ты так и не объяснил по какому принципу ты выбрал эти четыре и как оно согласуется с определением в документации. _>Я же тебе уже отвечал и не один раз. Утомило уже. Последняя попытка... В разные периоды жизни существовали разные ветки. Они же не фиксированные навсегда сущности, а могут появляться и пропадать через разделения/слияния. Соответственно на момент последней ревизии у тебя в репозитории одна ветка. А вот за всю историю их там было больше. )
Вот это хорошй пример нечёткой терминологии. Что-то как то было, толи один, толи эти четыре, толи ещё что... Гуманитарщина какая-то.
_>·>git craZyexPerIment _>·>будет создавать бранчи со случайным именем. _>·>Их потом можно всех вывести командой "git branch --list experimental/*" , тоже можно заальясить. _>·>Т.е. при желании это реализуется в несколько строчек конфига. И нет этого в стандартной поставке гита потому что это нафиг никому не сдалось, слава Оккаму, что этот анонимный бред отрезали. Такой инструмент — не удобен. Он может быть удобен только в том случае, когда ничего более удобного нет. А в гите есть куча более адекватных инструментов. _>Например? )
Ссылки (ветки, теги, stash, етс), reflog. Перечисляли же, не раз.
Вот скажем stash гораздо удобнее в git, чем анонимные ветки. А в hg это полная хрень, прикрученная сбоку, сделанная "шоб було" слабосвязанная фича, с которой даже diff нельзя сделать. Не удивительно, что приходится использовать анонимные ветки и считать их за благо.
_>>>·>Для чего под одним именем объединять-то? Чтобы всех запутать? _>>>Почему запутать? Как раз удобно все эксперименты держать под одним именем experimental) _>·>Будет у тебя 20 экспериментов... и как их различать-то? _>Вообще то у каждого есть подробное описание в комментарии к ревизии. )))
Почему подробное описание писать не лень (мне наоборот — лень, ибо потом всё равно менять — добавить story number, перечитать/переписать раза два для понятности ревьюверам), а одно-два слова сочинить для имени ветки — проблема?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, 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 увеличивают удобство работы с системой. Только вот мой оппонент всё никак не предоставит материал для точного сравнения...
Потому что реально бранчи-небранчи-метки-анонимки ни разу не понятная муть польза которой ну вообще вот не понятна
Здравствуйте, 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 в наличие, плюс ещё кое-что. )
Здравствуйте, ·, Вы писали:
_>>·>Cинхронизируй, разрешаю. _>>Каким образом? ) ·>Ну например просто "git stash pop", "git stash" поверх последних изменений коллег.
И каким образом то оно разойдётся по другим репозиториям? )
_>>Описания ревизий в Mercurial неизменные (ну если не считать редактирования истории с помощью ненормальных расширений), так же как и имена веток. ) ·>Т.е. пофиксить орфографическую ошибку в сообщении или добавить номер тикета не выйдет без заморочек? ·>Тебе просто кажется что они неизменные, промыли тебе мозг CVCS наследием. Ревизии в любой DVCS можно отредактировать всегда — сгенерить патчи, грохнуть локальный репозиторий, создать клон снова, чуть подредактировать и зааплаить патчи. Вопрос в другом — реализовать эту возможность нормально, для людей, как в git, или ненормально, через жо расширения, как в hg.
Если мы говорим об откате последних ревизий (несинхронизированных), то естественно это делается без проблем. Правда это будет не редактированием ревизии, а просто созданием её заново, но это не суть. Я же говорил о редактирование описания ревизии где-то в глубине уже устоявшейся истории... )
Здравствуйте, 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 — просто добавь это в сообщение коммита. И не ограничивай себя только именем ветки, а добавляй что надо — номер спринта, идентификатор истории, фамилию проджект-менеджера, уровень алкоголя в крови, и т.п.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
_>>Я всё понимаю, с точки зрения техники. ) Но по факту у тебя используется два эти имени в обоих репозиториях. И скорее всего во всех подобных сценариях так и будет. Хотя конечно формально есть возможность делать любые локальные имена. ) ·>Используются потому что я так захотел. А по факту это разные имена, их отдельно можно адресовать, указав явно. Полные имена это refs/heads/SomeName и refs/remotes/origin/SomeName — как видишь — они не равны. Просто git видя, что локальное имя SomeName используется в контексте ремотного репозитория origin, по умолчанию сопоставляет их друг другу при push или pull.
Я вообще то об этом и говорю. ) Что скорее всего будешь так хотеть и во всех остальных аналогичных случаях. )))
_>>Нуу кстати в данном случае это явно проявление архитектурной особенности git'a — наличия понятия stage. Это кстати единственный случае в git, где я вообще не понимаю зачем такое ввели, т.к. оно не приносит ни малейшей пользы, а лишнее телодвижения из-за этой хрени делать приходится. ·>Неверно. -a флажок же проблем не было реализовать. Просто, как мне кажется, это наиболее частый сценарий — закоммитить изменённые файлы, но не случайно появившееся.
Конечно самый частый и поэтом за него у mercurial отвечает просто "commit", а у git зачем-то "commit -a". А вот аналогом "commit -A" из mercurial будет уже "add . ; commit" из git. Хотя на самом деле все эти различия в параметрах — это естественно мелочи. Но я в любом случае не понимаю смысла существования такой штуки как stage в git.
_>>Да, ровно столько же. Но в варианте без именованных локальных веток один checkout можно выкинуть (он там только для вида у тебя был), а в случае локальных веток нельзя, т.к. он задаёт имя. ·>Локальное имя только для наглядности, можно обойтись и master.
Короче, вариант с именами в удалённом репозитории по числу команд сокращаем до аналога из Maercurial, а вариант с локальными именами нет. Можешь сам повычислять, на своих же примерах (я прямо по ним и смотрю, а не где-то ещё).
_>>Нуу покажи другой вариант решения, чтобы точка выбора между альтернативами находилась после их фиксации и чтобы после слияния одной из альтернатив (естественно не должно быть разницы в командах и графах в зависимости от выбора), другая осталась в истории (и была доступна в других репозиториях). ·>Была доступна как? Безымянной головой — не выйдет, конечно. А именованным бранчем — просто запушить да и всё. Я уже не понимаю что тебе ещё не понятно.
Мне всё понятно и ты уже давно предоставил нормальный работающий вариант. Просто потом вот написал что-то вроде "если бы не надо было синхронизировать на стадии развилки, то в git можно было бы сделать всё проще.". А я тебе говорю что нельзя, т.к. проблема была не в синхронизации, а в сохранение альтернативы на будущее. Но если ты считаешь по другому, то давай предоставь другой вариант с совсем другим кодом — посмотрим, может так и есть. )))
Здравствуйте, ·, Вы писали:
·> W>·>то в изначальном будет 3 головы master, clones_master, clones_branch, структура графа — идентична.
·> W>Слегка не в тему вопрос. Допустим я пилил ветку и слил ее в ремот. Там она была смержена куда надо и удалена. Потом я тоже у себя ее удалил. ·> W>Как понять в рамках какой ветки изначально был запилен тот или иной коммит?
·> Никак. А зачем?
В мире очень много девиаций Но я пока не натыкался на внятное описание такой.
Здравствуйте, alex_public, Вы писали:
_>·>Используются потому что я так захотел. А по факту это разные имена, их отдельно можно адресовать, указав явно. Полные имена это refs/heads/SomeName и refs/remotes/origin/SomeName — как видишь — они не равны. Просто git видя, что локальное имя SomeName используется в контексте ремотного репозитория origin, по умолчанию сопоставляет их друг другу при push или pull. _>Я вообще то об этом и говорю. ) Что скорее всего будешь так хотеть и во всех остальных аналогичных случаях. )))
Нет, далеко не всегда. Сейчас я локально работаю в master, а push делаю с именем jira issue.
_>>>Нуу кстати в данном случае это явно проявление архитектурной особенности git'a — наличия понятия stage. Это кстати единственный случае в git, где я вообще не понимаю зачем такое ввели, т.к. оно не приносит ни малейшей пользы, а лишнее телодвижения из-за этой хрени делать приходится. _>·>Неверно. -a флажок же проблем не было реализовать. Просто, как мне кажется, это наиболее частый сценарий — закоммитить изменённые файлы, но не случайно появившееся. _>Конечно самый частый и поэтом за него у mercurial отвечает просто "commit", а у git зачем-то "commit -a". А вот аналогом "commit -A" из mercurial будет уже "add . ; commit" из git. Хотя на самом деле все эти различия в параметрах — это естественно мелочи. Но я в любом случае не понимаю смысла существования такой штуки как stage в git.
Удобно. Коммит можно собирать по частям, серией различных команд.
Ещё удобно при разрешении конфликтов — при мерже неконфликтующие файлы идут в индекс, а кофликтующие не идут. Потом удобно по мере разрешения конфликтов добавлять разрешенное в индекс.
В общем, попробуешь — понравится.
_>>>Да, ровно столько же. Но в варианте без именованных локальных веток один checkout можно выкинуть (он там только для вида у тебя был), а в случае локальных веток нельзя, т.к. он задаёт имя. _>·>Локальное имя только для наглядности, можно обойтись и master. _>Короче, вариант с именами в удалённом репозитории по числу команд сокращаем до аналога из Maercurial, а вариант с локальными именами нет. Можешь сам повычислять, на своих же примерах (я прямо по ним и смотрю, а не где-то ещё).
Все push можно сделать одной командой. Тогда и получится столько же или даже меньше.
Например можно сделать так так:
cd clone
//мы уже находимся в master по умолчанию, не нужен checkout
//do change2A
git commit
git checkout -b change2B origin/master // switching back to previous revision
//do change 2B
git commit
теперь две альтернативы.
Выбрали 2B:
// мы уже находимся в change2B, не нужен checkout
git pull origin master// мержимся с изменениями пришедшими из начального репо
git push origin master:alternativeUnmergedSolution change2B:master
Выбрали 2A:
git checkout master
git pull origin master // мержимся с изменениями пришедшими из начального репо
git push origin master change2B:alternativeUnmergedSolution
В итоге в начальном репозитории будет две ветки — одна master — с замерженным решением и вторая alternativeUnmergedSolution.
_>>>Нуу покажи другой вариант решения, чтобы точка выбора между альтернативами находилась после их фиксации и чтобы после слияния одной из альтернатив (естественно не должно быть разницы в командах и графах в зависимости от выбора), другая осталась в истории (и была доступна в других репозиториях). _>·>Была доступна как? Безымянной головой — не выйдет, конечно. А именованным бранчем — просто запушить да и всё. Я уже не понимаю что тебе ещё не понятно. _>Мне всё понятно и ты уже давно предоставил нормальный работающий вариант. Просто потом вот написал что-то вроде "если бы не надо было синхронизировать на стадии развилки, то в git можно было бы сделать всё проще.". А я тебе говорю что нельзя, т.к. проблема была не в синхронизации, а в сохранение альтернативы на будущее. Но если ты считаешь по другому, то давай предоставь другой вариант с совсем другим кодом — посмотрим, может так и есть. )))
Что значит "сохранение"? Я понимаю под сохранением отправить альтернативную (незамерженную) ветку в ремотный (начальный) репо, т.е. то что ты называешь "синхронизация".
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
W>Слегка не в тему вопрос. Допустим я пилил ветку и слил ее в ремот. Там она была смержена куда надо и удалена. Потом я тоже у себя ее удалил. W>Как понять в рамках какой ветки изначально был запилен тот или иной коммит?
Не совсем понятно зачем, но да ладно.
При мерже обычно создается мерж комит в котором есть информаци какая ветка куда была замержена.
Здравствуйте, ·, Вы писали:
_>>Конечно самый частый и поэтом за него у mercurial отвечает просто "commit", а у git зачем-то "commit -a". А вот аналогом "commit -A" из mercurial будет уже "add . ; commit" из git. Хотя на самом деле все эти различия в параметрах — это естественно мелочи. Но я в любом случае не понимаю смысла существования такой штуки как stage в git. ·>Удобно. Коммит можно собирать по частям, серией различных команд. ·>Ещё удобно при разрешении конфликтов — при мерже неконфликтующие файлы идут в индекс, а кофликтующие не идут. Потом удобно по мере разрешения конфликтов добавлять разрешенное в индекс. ·>В общем, попробуешь — понравится.
Чтобы сделать частичную фиксацию эта сущность точно не нужна (hg commit -i тому доказательство). А какие ещё полезные сценарии могут быть? )
_>>Короче, вариант с именами в удалённом репозитории по числу команд сокращаем до аналога из Maercurial, а вариант с локальными именами нет. Можешь сам повычислять, на своих же примерах (я прямо по ним и смотрю, а не где-то ещё). ·>Все push можно сделать одной командой. Тогда и получится столько же или даже меньше. ·>Например можно сделать так так: ·>... ·>В итоге в начальном репозитории будет две ветки — одна master — с замерженным решением и вторая alternativeUnmergedSolution.
Да, но тогда во втором репозитории будет некая ересь. ) Причём степень её бредовости будет зависеть от выбранного варианта.)
P.S. Вообще не очень понимаю смысл этих твоих дальнейших упражнений, после того как правильное решение уже было найдено. )
Здравствуйте, vovkab, Вы писали:
V>Не совсем понятно зачем, но да ладно. V>При мерже обычно создается мерж комит в котором есть информаци какая ветка куда была замержена.
Там нет информации что входило в эти ветки.
В ответе на стеке автор полагает что "Your example shows that the branch feature is still available."
А в моем вопросе это не так.
Да и сам ответ жесть какая-то. Такая куча буков и мешанина команд чтобы просто найти что Вася пилил в своей ветке месяц назад.
Здравствуйте, alex_public, Вы писали:
_>Mercurial лучше — абсолютно те же самые технические возможности, но при этом более удобно. Хотя если делать всё через GUI или вообще из какой-нибудь IDE, то скорее всего разницы не увидишь.
Здравствуйте, netch80, Вы писали:
N>В этом примере не разное понимание, а одна мелочь — фиксация имени ветки в коммите hg. Да, я действительно не понимаю, зачем это настолько нужно, чтобы выдвигать на киллер-фичу, при том, что реально ни одна другая SCM это не ведёт.
Вот для меня это возможно и есть киллер фича которой не хватает в гите
Взять и посмотреть быстро и удобно все что Петя делал 3 недели в рамках своих ковыряний фичи ХХХ.
Да это отвал башки просто если меркуриал позволяет это делать не выковыривая пятистрочными командами всякую срань из гитлога
N>Добавить принудительно имя ветки в сообщение тривиально за счёт локального хука, но накойхер? Там лучше держать, например, герритовский change-id.
А накойхер держать геррит, если работаешь в visual studio?
Ради одного неудобного инструмента (гит) добавлять костыли в виде других неудобных инструментов (геррит) ?
AK>в итоге мне для меня неясен подход гита в отношении контроля версий файла. его выходит как бы и нет... AK>а blame это больше похоже на костыль ну или я вообще не догоняю философию гита
Весь гит это по сути красивое нутро (реально лаконичная и простая архитектура) и ворох костылей чтобы это операции с этим нутром наложить на ежедневные потребности разрабов. Каждый релиз допиливают новые опции и команды которые по сути являются юзкейсами.
Здравствуйте, willie, Вы писали:
w> _>Mercurial лучше — абсолютно те же самые технические возможности, но при этом более удобно. Хотя если делать всё через GUI или вообще из какой-нибудь IDE, то скорее всего разницы не увидишь.
w> Интересно сравнить. Меркуриал может решить проблему описаную тут http://rsdn.ru/forum/flame.comp/6352935.1
? w> Всегда бесила работа с ветками в гите которые были удалены.
А можно описать для чего это? Вот например была ветка feature1,которая потом влилась в ветку megafeatureX, которая в итоге влилась в ветку release2016.1, которая потом стала как бы "read only"(тагом например). Что нам дает то что мы знаем что коммит X был в рамках ветки feature1, а коммит Y только в рамках ветки megafeatureX?
Здравствуйте, willie, Вы писали:
w> W>>Как понять в рамках какой ветки изначально был запилен тот или иной коммит? w> ·>Никак. w> Очень плохо. А в hg так можно? Тогда стоит его посмотреть на замену гиту w> ·>А зачем? w> Например чтобы откатить все что наваял нерадивый юниор. Для начала надо все это как-то найти. Желательно удобнее чем с помощью команды w>
w> как мне тут советуют в соседней ветке и на стеке Ведь это гит для нас, а не мы для гита
Хм, а зачем тогда такие аттрибуты коммита как Author и Committer(не знаю есть ли такое в mercurial)?
Здравствуйте, alex_public, Вы писали:
_>>>Конечно самый частый и поэтом за него у mercurial отвечает просто "commit", а у git зачем-то "commit -a". А вот аналогом "commit -A" из mercurial будет уже "add . ; commit" из git. Хотя на самом деле все эти различия в параметрах — это естественно мелочи. Но я в любом случае не понимаю смысла существования такой штуки как stage в git. _>·>Удобно. Коммит можно собирать по частям, серией различных команд. _>·>Ещё удобно при разрешении конфликтов — при мерже неконфликтующие файлы идут в индекс, а кофликтующие не идут. Потом удобно по мере разрешения конфликтов добавлять разрешенное в индекс. _>·>В общем, попробуешь — понравится. _>Чтобы сделать частичную фиксацию эта сущность точно не нужна (hg commit -i тому доказательство). А какие ещё полезные сценарии могут быть? )
commit -i заставляет сделать всё одной командой — выбирать сразу. серия команд "add", "add -p" упрощает жизнь.
Например, IDEA не поддерживает (интересно, а какие поддерживают?) интерактивный коммит, может добавлять только файлы. У меня есть возможность добавить какие-то файлы из UI, а какие-то по-hunk-ово из командной строки.
_>·>Все push можно сделать одной командой. Тогда и получится столько же или даже меньше. _>·>Например можно сделать так так: _>·>... _>·>В итоге в начальном репозитории будет две ветки — одна master — с замерженным решением и вторая alternativeUnmergedSolution. _>Да, но тогда во втором репозитории будет некая ересь. ) Причём степень её бредовости будет зависеть от выбранного варианта.)
Что значит ересь? Граф истории — идентичен. Только имена веток отличаться будут.
_>P.S. Вообще не очень понимаю смысл этих твоих дальнейших упражнений, после того как правильное решение уже было найдено. )
Я вначале привёл решения наиболее осмысленные, более юзер-френдли, поэтому чуть больше команд. Если же делать по минимуму — то команд будет меньше, результат тот же, смысла столько же как и с анонимными ветками в hg.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, willie, Вы писали:
W>>>Как понять в рамках какой ветки изначально был запилен тот или иной коммит? W>·>Никак. W>Очень плохо. А в hg так можно? Тогда стоит его посмотреть на замену гиту
Можно, для небольшого проекта с центральным репозиторием, как CVCS hg ещё ок, в качестве альтернативы svn. Хотя в случае централизованной разработки лучше взять gerrit.
W>·>А зачем? W>Например чтобы откатить все что наваял нерадивый юниор. Для начала надо все это как-то найти. Желательно удобнее чем с помощью команды
Найти точку нерадивого мержа, заревертить её. Не вижу проблемы.
W>·>Если надо поместить какую-то информацию в коммит, скажем bug id — просто добавь это в сообщение коммита. И не ограничивай себя только именем ветки, а добавляй что надо — номер спринта, идентификатор истории, фамилию проджект-менеджера, уровень алкоголя в крови, и т.п. W>Проще в экселе это записывать. А исходники архивировать и на дискету. Удобней гита всяко
Если у тебя такой небольшой простой проект, что имени ветки хватает — то экзель вполне серьёзный конкурент.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, willie, Вы писали:
M>>>На днях натыкался — есть такая проблема. W>·>Да нет такой проблемы, открой для себя "git log -M" W>И что ? Покажет что смержились две ветки. Как посмотреть какие именно коммиты вошли в мою ветку из чужой?
git log myBranch^..alienBranch
Только причём тут переименование файлов?
.>>или ещё круче — "git blame -C" W>с консольки файлы листать?
Если консоль чем-то не нравится, в IDEA есть history for selection — выделяешь блок строк и смотришь историю для него.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, willie, Вы писали:
w> Например чтобы откатить все что наваял нерадивый юниор. Для начала надо все это как-то найти. Желательно удобнее чем с помощью команды
А вообще в нормальном процессе между нерадивым(а зачем такие вообще в команде нужны?) джуниором/мидлом/сениором будет что-то что не даст фигне просочиться в репо вообще.
Сорри, что не в тему, если ты под Windows, то не помешает обновиться — домен в подписи уж несколько лет как не существует, а с тех пор в openssl багов много.
P.S. С другой стороны, работает — не трогай.
Управляю вселенной не привлекая внимания санитаров.
Здравствуйте, ·, Вы писали:
W>>·>Да нет такой проблемы, открой для себя "git log -M" W>>И что ? Покажет что смержились две ветки. Как посмотреть какие именно коммиты вошли в мою ветку из чужой? ·>git log myBranch^..alienBranch
Не сработает. Ведь бранчи-то удаляются. Это тебе не меркуриал с его мегафичей вечных веток.
Здравствуйте, Dziman, Вы писали:
D>А вообще в нормальном процессе между нерадивым(а зачем такие вообще в команде нужны?) джуниором/мидлом/сениором будет что-то что не даст фигне просочиться в репо вообще.
Речь про гит, а не процессы )
Другие тулзы вполне позволяют отловить все коммиты.
Вместо юниора можно придумать кучу других примеров где удобно смотреть именно ветки N летней давности.
V>Это же чуть ли на самая часто используемуя фича.
Для тебя да, для меня нет. Код править на лету — легче застрелиться. Поправил — прогнал тесты, закоммитил пошел дальше. Какой тут интерактив и зачем.
V>Вы видимо не работали над большими фичами, либо нет нормального код ревью.
Как раз таки нормальное код ревью и подразумевает нормальные вдумчивые исправления кода. С подсветкой синтаксиса и рефакторингом на лету.
V>Правда руками я это не делаю, так как контекста мало. Но какой нить "gitx" или "git gui", справляются на ура.
Нет, на ура справляется только IDE которая сможет подсказать не привели ли твои интерактивные изменения к ошибкам. Опечатался в названии или забыл обновить где-то имя переменной.
Может я конечно не совсем понял что имелось в виду под самой используемой фичей и как именно ее использует автор. Но посмотрев бегло скринкасты на трубе могу сказать что это ужас пользоваться в середине 2010-х такими инструментами как консольный git interactive[add,rebase,whatever] это мазохизм
Здравствуйте, Dziman, Вы писали:
D>А можно описать для чего это? Вот например была ветка feature1,которая потом влилась в ветку megafeatureX, которая в итоге влилась в ветку release2016.1, которая потом стала как бы "read only"(тагом например). Что нам дает то что мы знаем что коммит X был в рамках ветки feature1, а коммит Y только в рамках ветки megafeatureX?
Ровно это и дает. Ты знаешь какой коммит зачем в рамках чего создавался.
Но мне интересно именно отслеживать как кто-то пилил что-то. А не копошиться в ворохе логов и коммитов гита влитых 10-ю людьми в development ветку два года назад в попытках разобраться как они что делали и в каком порятке на каких временных интервалах это происходило.
Здравствуйте, Dziman, Вы писали:
w>> как мне тут советуют в соседней ветке и на стеке Ведь это гит для нас, а не мы для гита D>Хм, а зачем тогда такие аттрибуты коммита как Author и Committer(не знаю есть ли такое в mercurial)?
Не знаю. Я про них вообще не спрашивал. Это линуксоидам наверное надо, которым патчи по имейлам до сих пор шлют. Мне это не надо У нас нормальный процесс разработки, без извращений.
W>>Например чтобы откатить все что наваял нерадивый юниор. Для начала надо все это как-то найти. Желательно удобнее чем с помощью команды ·>Найти точку нерадивого мержа, заревертить её. Не вижу проблемы.
Я вижу как минимум проблему найти удобно коммиты которые ревертить.
Здравствуйте, ·, Вы писали:
·>Можно, для небольшого проекта с центральным репозиторием, как CVCS hg ещё ок, в качестве альтернативы svn. Хотя в случае централизованной разработки лучше взять gerrit.
Не понимаю этого упора на централизованность-децентрализованность.
В большинстве продуктовых компаний по факту вся разработка централизована. Нету там никаких "распределенных систем равноправных репозиториев". Нету равноправия между офисами Есть центральный, куда все остальные сливаются по спринтам и откуда они забирают код других команд. Даже аутсорсеры зачастую либо получают репу и отдают ее на сливание заказчику, либо тупо по vpn сидят подключившись к серверу заказчика. Все эти мульки гита с распределенностью просто не нужны.
Весь этот тред сводится к спору пары человек которые видимо работают в распределенных командах.
Я вот почитал и понял что все же выбор гита видимо был ошибкой предыдущей команды. Повелись на баззворды, послушались красноглазого тимлида и вот результат. Постоянно за кем=то разруливать косяки приходится из-за того что кто-то не осилил документацию гита в очередной раз
Здравствуйте, willie, Вы писали:
W>Здравствуйте, Dziman, Вы писали:
D>>А можно описать для чего это? Вот например была ветка feature1,которая потом влилась в ветку megafeatureX, которая в итоге влилась в ветку release2016.1, которая потом стала как бы "read only"(тагом например). Что нам дает то что мы знаем что коммит X был в рамках ветки feature1, а коммит Y только в рамках ветки megafeatureX? W>Ровно это и дает. Ты знаешь какой коммит зачем в рамках чего создавался.
Использовать номер тикета в комите?
W>Но мне интересно именно отслеживать как кто-то пилил что-то.
Код ревью с пул реквестами не достаточно?
W>А не копошиться в ворохе логов и коммитов гита влитых 10-ю людьми в development ветку два года назад в попытках разобраться как они что делали и в каком порятке на каких временных интервалах это происходило.
W>>Для тебя да, для меня нет. Код править на лету — легче застрелиться. Поправил — прогнал тесты, закоммитил пошел дальше. Какой тут интерактив и зачем.
V>Что значит на лету?
Если что я имел в виду это сообщение http://rsdn.ru/forum/flame.comp/6339216.1
Где описаны edit-add, interactive-add и прочее.
V>Что мешает прогнать тесты во время ребэйза? Или делать все эти изменения из иде?
Про ребейз я не говорил, причем тут иде и interactive-add не понял.
Здравствуйте, willie, Вы писали:
W>Я вот почитал и понял что все же выбор гита видимо был ошибкой предыдущей команды. Повелись на баззворды, послушались красноглазого тимлида и вот результат. Постоянно за кем=то разруливать косяки приходится из-за того что кто-то не осилил документацию гита в очередной раз
Интересно как прошедшие код ревью, тесты и автоматически смерженный пулл реквест доставляет вам проблемы?
Здравствуйте, willie, Вы писали:
W>Здравствуйте, vovkab, Вы писали:
W>>>Для тебя да, для меня нет. Код править на лету — легче застрелиться. Поправил — прогнал тесты, закоммитил пошел дальше. Какой тут интерактив и зачем.
V>>Что значит на лету? W>Если что я имел в виду это сообщение http://rsdn.ru/forum/flame.comp/6339216.1
Именно этот воркфлоу я имел ввиду.
V>>Что мешает прогнать тесты во время ребэйза? Или делать все эти изменения из иде? W>Про ребейз я не говорил, причем тут иде и interactive-add не понял.
Например:
1. нарезал комит, добавляя файлы, строчки, куски, что угодно
2. спрятал все остальное
3. прогнал тесты, убедился что все работает
4. вытащил свой wip и продолжил дальше пилить
Надо поменять что то в старом комите, сделал ребэйз или просто фиксап комит, что бы не тратить время сейчас,
оно потом само автоматически вольется куда надо при ребэйзе.
V>Нормальное код ревью подразумевает нормальную историю и комиты в которых нет лишнего. А для этого надо уметь нарезать и потом перенарезать комиты.
Нарезать и перенарезать это лишнее. Уши этого "мастерства" торчат из неудобств гита, где при наличии коммитов с месседжами "quickly fix " или "save state" ты хрен разберешься что имелось в виду. Если у тебя есть бранч как в меркуриале то тебе в общем-то пофиг что там внутри, ты оперируешь макро изменениями, а не микро. Разработчикам удобно работать, можно хоть 100 раз коммитить полуготовые файлы перемежая с полноценными коммитами. И изменения не теряются, и всякой фигней вроде git stash пользоваться не надо, и историю "вдумчиво переписывать" не надо сидеть. Ты просто работаешь как тебе удобно, а vcs тебе в этом помогает.
V>Пример, у тебя большая фича и что бы ее сделать надо выполнить несколько рефакторингов, будешь все в один комит пихать?
Нет, сделаю несколько коммитов с рефакторингами, потом фичу. В чем проблема-то.
V>А если комиты уже есть и надо их подправить, например, опечатку сделал?
Опять таки в чем проблема? Вот в гите да, проблема. Пушнул в ремот хрена с два поправишь без --force. Со всеми вытекающими.
V>Я считаю что и не надо делать этого из консоли, используй что удобнее.
В случае с гитом под винду я пока не видел удобных инструментов. Почти все поддерживают только какие-то базовые вещи, а за извратами надо в консоль лезть. А извратов в гите многО
Здравствуйте, willie, Вы писали:
W>Здравствуйте, vovkab, Вы писали:
V>>Использовать номер тикета в комите?
W>1) Я не хочу его вписывать руками W>2) Я не хочу его видеть в git log W>3) Я хочу полноценное название ветки, а не номер какого-то тикета
W>Номер тикета в коммите это костыль.
А как детали потом если надо находите, или у вас экстрасенсы работают?
Если прям так сильно хочется ветку, так не удаляйте?
W>>>Но мне интересно именно отслеживать как кто-то пилил что-то. V>>Код ревью с пул реквестами не достаточно?
W>Мы не на гитхабе работаем.
Полно систем для код ревью — gerrit, stash and etc...
Иначе вы получите полный бардак, если все будут мержить что хотят, куда хотят, еще и репозиторий поломают.
То есть код ревью никакого у вас нет как я вижу.
V>А как детали потом если надо находите, или у вас экстрасенсы работают? V>Если прям так сильно хочется ветку, так не удаляйте?
Так я не хочу ветку. Нафиг мне ветка нужна Мне нужны макроблоки работы которыми можно легко и удобно оперировать.
V>Полно систем для код ревью — gerrit, stash and etc... V>Иначе вы получите полный бардак, если все будут мержить что хотят, куда хотят, еще и репозиторий поломают.
Мы и пользуемся. Только все эти герриты фигня на палочке, т.к. язык не понимают, рефакторинг не могут и вообще. Приходится держать зоопарк тулзов и смазывать это мерж-реквестами (ака pull реквесты в гитхабе) чтобы удобно понимать по истории изменений что происходило когда.
Жалкое подобие левой руки в общем.
V>То есть код ревью никакого у вас нет как я вижу.
Как и чем ты это увидел?
В курсе хоть что ревью намного удобнее делать с помощью плагинов в IDE а не этими убожествами вроде герритов, стешей и прочими аспорами.
Здравствуйте, willie, Вы писали:
W>В курсе хоть что ревью намного удобнее делать с помощью плагинов в IDE а не этими убожествами вроде герритов, стешей и прочими аспорами.
Чем удобнее? Эти плагины могут делать аннотации для изменений, смотреть signoff'ы от других reviewer'ов и т.п.?
Здравствуйте, Cyberax, Вы писали:
W>>В курсе хоть что ревью намного удобнее делать с помощью плагинов в IDE а не этими убожествами вроде герритов, стешей и прочими аспорами. C>Чем удобнее? Эти плагины могут делать аннотации для изменений, смотреть signoff'ы от других reviewer'ов и т.п.?
Конечно могут
Выделил мышкой два слова, написал коммент. Выделенный кусок подсветился.
Второй разраб моментально увидел коммент, открыл, увидел что плохо названа переменная, нажал кнопку рефакторить, ВО ВСЕМ проекте ПРАВИЛЬНО поменял название в два клика. Закрыл твой коммент. Ты увидел обновление, нажал accept, ревью закончилось.
Для большинства линуксоидов это звучит как фантастика конечно
Здравствуйте, willie, Вы писали:
W>Второй разраб моментально увидел коммент, открыл, увидел что плохо названа переменная, нажал кнопку рефакторить, ВО ВСЕМ проекте ПРАВИЛЬНО поменял название в два клика. Закрыл твой коммент. Ты увидел обновление, нажал accept, ревью закончилось. W>Для большинства линуксоидов это звучит как фантастика конечно
Это извращение, а не фантастика. Примерно на том же уровне, что и "checkout" файлов из SourceSafe.
Здравствуйте, willie, Вы писали:
W>Здравствуйте, vovkab, Вы писали:
V>>Например: V>>1. нарезал комит, добавляя файлы, строчки, куски, что угодно
W>Пока я не видел как можно удобно в гите нарезать строчки, куски что угодно. W>Ругаемый гитовцами вариант "сохранить в файлик, потом вернуть" реально удобнее всех этих гитовских консольных симулякров а-ля vimdiff.
V>>2. спрятал все остальное V>>3. прогнал тесты, убедился что все работает V>>4. вытащил свой wip и продолжил дальше пилить
W>И что, с этим есть проблемы где-то? Стешить wip даже в майкросовтовской тфс можно было еще сто лет назад.
Вы написали что все время косячите при создании комитов, я вам написал один из сценариев как сделать что бы все было железно.
V>>Надо поменять что то в старом комите, сделал ребэйз или просто фиксап комит, что бы не тратить время сейчас, V>>оно потом само автоматически вольется куда надо при ребэйзе.
W>Одна из немногих фич гита которая более-менее работает, да. Да и то не факт что в других системах нет аналогов + работает эта фича до первого синка с ремотом.
С какого перепугу что то поломается?
Ну потянул ты мастер/дев, чего в друго в твоем бранче что то сломается?
Ну сделал ты ребэйз поверх мастера, опять же ничего не поломается.
Здравствуйте, willie, Вы писали:
W>Здравствуйте, vovkab, Вы писали:
V>>А как детали потом если надо находите, или у вас экстрасенсы работают? V>>Если прям так сильно хочется ветку, так не удаляйте?
W>Так я не хочу ветку. Нафиг мне ветка нужна Мне нужны макроблоки работы которыми можно легко и удобно оперировать.
Вы суете кучу мусора в историю, от этого и появилась надобность выслеживать по ветка, иначе похоже вообще ни как.
Я даже не представляю как вы git blame используете с такой историей, наверное вообще жесть?
V>>Полно систем для код ревью — gerrit, stash and etc... V>>Иначе вы получите полный бардак, если все будут мержить что хотят, куда хотят, еще и репозиторий поломают.
W>Мы и пользуемся. Только все эти герриты фигня на палочке, т.к. язык не понимают, рефакторинг не могут и вообще. Приходится держать зоопарк тулзов и смазывать это мерж-реквестами (ака pull реквесты в гитхабе) чтобы удобно понимать по истории изменений что происходило когда. W>Жалкое подобие левой руки в общем.
И кофе тоже не варит?
Вообще как это относится к гит? В целом код ревью не зависит от используемой системы контроля версий.
Разница будет только насколько просто делать запрошенные командой изменения.
V>>То есть код ревью никакого у вас нет как я вижу.
W>Как и чем ты это увидел? W>В курсе хоть что ревью намного удобнее делать с помощью плагинов в IDE а не этими убожествами вроде герритов, стешей и прочими аспорами.
Делай на здоровье ни кто ведь не запрещает? Я согласен так даже лучше, вытащить код, проверить с удобной подстветкой и навигацией, что все работает как надо.
Но ведь нужно как то общаться с командой, обсуждать, правильно? Что бы все одобрили изменения. В целом для этого и нужны герит, стэш и тд
Здравствуйте, willie, Вы писали:
W>Здравствуйте, vovkab, Вы писали:
V>>В общем на сколько я вижу, тут проблема не столько в гите, сколько в организации процесса разработки, которого нет.
W>Он есть и в случае использования не гита он вполне работает. Все эти промежуточные коммиты могут быть весьма полезны когда придется отлавливать странный баг или поведение. Далеко не все и далеко не всегда можно\нужно вылизывать до блеска и полировать тестами в своей песочнице.
W>Если все пихать в каноничные мега коммиты с рюшечками и сообщениями на пять строк, то хрена с два ты там найдешь тот самый момент когда что-то отвалилось
Где я писал про мега комиты? Если изменение может жить отдельно без все остального, значит должно быть в отдельном комите.
Видишь ничего не поменялось? Только разница в том, что в истории не будет шума о том как я переименовывал класс 5 раз, пока не определился с именем.
Здравствуйте, willie, Вы писали:
W>Здравствуйте, vovkab, Вы писали:
V>>Такие комиты не пройдут код ревью, так что их по определению нет.
W>Тоже вопрос весьма спорный. Что плохого в промежуточном коммите, если у тебя есть нормальная история на более высоком уровне? W>Зачем тратить время на причесывание истории к каноничным стандартам, если в 99% случаев ты эту историю даже не откроешь? W>В Меркуриале достаточно глянуть какие ветки слились и тебе сразу понятно что было проделано. В гите с помощью сторонних приблуд можно сделать симулякр в виде пулл реквестов.
Пример, ты работаешь на фичей и я, допустим ты уже сделал кусок, который нужен мне, но он у тебя разбросан по 100500 комитам, типа wip1 wip2 wip3 (очень полезно)
Если бы делал нормально, то можно было бы просто вырезать нужный комит и сделать пулл реквест, или просто зачерипикать.
W>На ревью ты смотришь уже готовый результат. Было-стало. А промежуточный стейт нужнен только для случая разбора полетов. Много мелких коммитов это лучше чем пара развесистых на 100500 файлов каждый. Когда ты берешь, открываешь и просто не понимаешь откуда могут расти ноги проблемы.
W>Просто в гите не делают такие коммиты т.к. гит с историей и ветками нормально работать не позволяет
Здравствуйте, willie, Вы писали:
W>Здравствуйте, vovkab, Вы писали:
V>>Например: V>>1. нарезал комит, добавляя файлы, строчки, куски, что угодно
W>Пока я не видел как можно удобно в гите нарезать строчки, куски что угодно. W>Ругаемый гитовцами вариант "сохранить в файлик, потом вернуть" реально удобнее всех этих гитовских консольных симулякров а-ля vimdiff.
Не знаю о чем ты, но обычно нужно:
1. выделить строчки что хочешь закомитить мышкой
2. нажать правой кнопкой
3. кликнуть на "stage"
Здравствуйте, Anton Batenev, Вы писали:
AB> D> avalon 1.0rc3 build 430, zlib 1.2.5
AB> Сорри, что не в тему, если ты под Windows, то не помешает обновиться — домен в подписи уж несколько лет как не существует, а с тех пор в openssl багов много.
AB> P.S. С другой стороны, работает — не трогай.
на маке я и вроде готовых новых сборок нет,а самому лень
W>>Весь этот тред сводится к спору пары человек которые видимо работают в распределенных командах. ·>Даже в централизованной команде можно распределяться между собой — офисный десктоп/домашний десктоп/лаптоп/виртуалки.
Это и без гита можно.
W>>Я вот почитал и понял что все же выбор гита видимо был ошибкой предыдущей команды. Повелись на баззворды, послушались красноглазого тимлида и вот результат. Постоянно за кем=то разруливать косяки приходится из-за того что кто-то не осилил документацию гита в очередной раз ·>Какие косяки приходится разруливать? Тем более в случае вашей централизованной разработки.
Я ж написал. Прямо в предложении на которое ты отвечаешь.
V>Пример, ты работаешь на фичей и я, допустим ты уже сделал кусок, который нужен мне, но он у тебя разбросан по 100500 комитам, типа wip1 wip2 wip3 (очень полезно) V>Если бы делал нормально, то можно было бы просто вырезать нужный комит и сделать пулл реквест, или просто зачерипикать.
Ты писал про не плодить промежуточных и мелких
V> Только разница в том, что в истории не будет шума о том как я переименовывал класс 5 раз, пока не определился с именем.
Ну, настолько мелких мы не делаем Не все так запущено как ты нарисовал в своем воображении.
Здравствуйте, vovkab, Вы писали:
V>Вы суете кучу мусора в историю, от этого и появилась надобность выслеживать по ветка, иначе похоже вообще ни как. V>Я даже не представляю как вы git blame используете с такой историей, наверное вообще жесть?
Слегка утрировано конечно написал. Нормально все с blame. Просто без фанатизма отношусь к требованиям по оформлению коммитов. VCS это врежде всего фиксация потока идей и состояний. Вовсе не обязательно чтобы каждый коммит можно было зачекаутить и получить нормально работающее приложение. Вот в конце ветки да, обязательно.
V>Вы написали что все время косячите при создании комитов, я вам написал один из сценариев как сделать что бы все было железно.
Это не косяки, с чего ты взял-то. Важен момент мержа ветки, а не ее внутренние состояния. В околоисследовательских и научных проектах одно из этих состояний может вдруг резко понадобиться чтобы обкатать отброшенную ранее идейку на новых входных данных.
V>С какого перепугу что то поломается? V>Ну потянул ты мастер/дев, чего в друго в твоем бранче что то сломается? V>Ну сделал ты ребэйз поверх мастера, опять же ничего не поломается.
Ну ты почитай почему в dcvs считается табу history rewriting удаленного репозитория с которым синкаются другие. И зачем придумали команду revert
Здравствуйте, willie, Вы писали:
W>>>Весь этот тред сводится к спору пары человек которые видимо работают в распределенных командах. W>·>Даже в централизованной команде можно распределяться между собой — офисный десктоп/домашний десктоп/лаптоп/виртуалки. W>Это и без гита можно.
Можно, конечно. Но гит предоставляет удобные фичи для этого.
W>>>Я вот почитал и понял что все же выбор гита видимо был ошибкой предыдущей команды. Повелись на баззворды, послушались красноглазого тимлида и вот результат. Постоянно за кем=то разруливать косяки приходится из-за того что кто-то не осилил документацию гита в очередной раз W>·>Какие косяки приходится разруливать? Тем более в случае вашей централизованной разработки. W>Я ж написал. Прямо в предложении на которое ты отвечаешь.
Ты написал из-за чего косяки, а не какие косяки.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, willie, Вы писали:
W>>>Я вижу как минимум проблему найти удобно коммиты которые ревертить. W>·>Это никак не зависит от наличия/отсутствия перманентных бранчей. W>Бранчи удобнее.
Дело привычки.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, willie, Вы писали:
C>>Это извращение, а не фантастика. Примерно на том же уровне, что и "checkout" файлов из SourceSafe. W>Чушь несешь. W>Не знаю как ты, а я живу в 21 веке и ревью делаю с помощью более удобных тулзов чем веб-просмотрщик текста.
А оно работает с моим vim? Или обязательно в Ein Volk, ein Reich, ein Füh Визуальной Студии?
Здравствуйте, ·, Вы писали:
_>>Чтобы сделать частичную фиксацию эта сущность точно не нужна (hg commit -i тому доказательство). А какие ещё полезные сценарии могут быть? ) ·>commit -i заставляет сделать всё одной командой — выбирать сразу. серия команд "add", "add -p" упрощает жизнь. ·>Например, IDEA не поддерживает (интересно, а какие поддерживают?) интерактивный коммит, может добавлять только файлы. У меня есть возможность добавить какие-то файлы из UI, а какие-то по-hunk-ово из командной строки.
Хы, я то сам на практике даже commit -i не используют (всё через GUI), а ты говоришь про такие сложности. )))
_>>·>Все push можно сделать одной командой. Тогда и получится столько же или даже меньше. _>>·>Например можно сделать так так: _>>·>... _>>·>В итоге в начальном репозитории будет две ветки — одна master — с замерженным решением и вторая alternativeUnmergedSolution. _>>Да, но тогда во втором репозитории будет некая ересь. ) Причём степень её бредовости будет зависеть от выбранного варианта.) ·>Что значит ересь? Граф истории — идентичен. Только имена веток отличаться будут.
Ну да, только вот как отличаться... У тебя там во 2-ом репозитории при варианте "Б" будет в master храниться ревизия "А" (кстати, долго она там будет храниться? При следующем git pull то туда затянутся изменения из удалённого master или alternativeUnmergedSolution?), в changeB будет содержимое аналогичное master в удалённом. Короче бред и подобную ересь по любому пришлось бы потом ещё править. )
Здравствуйте, alex_public, Вы писали:
_>>>Чтобы сделать частичную фиксацию эта сущность точно не нужна (hg commit -i тому доказательство). А какие ещё полезные сценарии могут быть? ) _>·>commit -i заставляет сделать всё одной командой — выбирать сразу. серия команд "add", "add -p" упрощает жизнь. _>·>Например, IDEA не поддерживает (интересно, а какие поддерживают?) интерактивный коммит, может добавлять только файлы. У меня есть возможность добавить какие-то файлы из UI, а какие-то по-hunk-ово из командной строки. _>Хы, я то сам на практике даже commit -i не используют (всё через GUI), а ты говоришь про такие сложности. )))
Какой gui? Встроенный в IDE? Или отдельный?
_>>>Да, но тогда во втором репозитории будет некая ересь. ) Причём степень её бредовости будет зависеть от выбранного варианта.) _>·>Что значит ересь? Граф истории — идентичен. Только имена веток отличаться будут. _>Ну да, только вот как отличаться... У тебя там во 2-ом репозитории при варианте "Б" будет в master храниться ревизия "А" (кстати, долго она там будет храниться? При следующем git pull то туда затянутся изменения из удалённого master или alternativeUnmergedSolution?), в changeB будет содержимое аналогичное master в удалённом. Короче бред и подобную ересь по любому пришлось бы потом ещё править. )
Если будешь на master возвращаться, зарезеть его в начальный:
git checkout -B master origin/master
Всяко лучше чем голые номера ревизий безымянных голов использовать.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
_>>Хы, я то сам на практике даже commit -i не используют (всё через GUI), а ты говоришь про такие сложности. ))) ·>Какой gui? Встроенный в IDE? Или отдельный?
Смотря для каких действий. Скажем ветками порулить, синхронизироваться и т.п. я как-то привык из внешнего инструмента (TortoiseHg). А скажем посмотреть историю файла и т.п. вопросы связанные уже с контентом обычно из IDE делаются.
Здравствуйте, alex_public, Вы писали:
_>>>Хы, я то сам на практике даже commit -i не используют (всё через GUI), а ты говоришь про такие сложности. ))) _>·>Какой gui? Встроенный в IDE? Или отдельный?
_>Смотря для каких действий. Скажем ветками порулить, синхронизироваться и т.п. я как-то привык из внешнего инструмента (TortoiseHg). А скажем посмотреть историю файла и т.п. вопросы связанные уже с контентом обычно из IDE делаются.
Ну собственно вот... Плюс иногда требуется command line, для каких-то более сложных действий, например, какой-то хитрый скриптик можно написать.
Одного UI не всегда достаточно, приходится разные использовать. И staging в этом помогает.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, willie, Вы писали:
V>>Вы написали что все время косячите при создании комитов, я вам написал один из сценариев как сделать что бы все было железно. W>Это не косяки, с чего ты взял-то. Важен момент мержа ветки, а не ее внутренние состояния. В околоисследовательских и научных проектах одно из этих состояний может вдруг резко понадобиться чтобы обкатать отброшенную ранее идейку на новых входных данных.
Люди косячат. Если в результате peer review приходит замечание "ты ещё в паре мест забыл логику подправить", это достаточное основание модифицировать ранее предложенный коммит.
На исследовательскую идею состояние "исправил три места, про ещё два забыл" не тянет даже после ста грамм.
V>>С какого перепугу что то поломается? V>>Ну потянул ты мастер/дев, чего в друго в твоем бранче что то сломается? V>>Ну сделал ты ребэйз поверх мастера, опять же ничего не поломается.
W>Ну ты почитай почему в dcvs считается табу history rewriting удаленного репозитория с которым синкаются другие. И зачем придумали команду revert
При всём при этом ветки промежуточной подачи правок в Linux проходят такую переписку почти ежедневно, а в git help rebase есть глава, как работать, если в апстриме такое происходит.
Это, конечно, далеко не для рядового исполнителя. Но и показывает, что "табу" не существует, а вместо этого есть разумная экономия усилий для типичного случая.
Здравствуйте, willie, Вы писали:
N>>IDE не рассматриваем тут принципиально. W>А по-моему наоборот, dcvs без нормальной интеграции с IDE это меньше чем половина dcvs. W>Ковыряться в консоли в 99% случаев нафиг не упало.
Я не рассматривал IDE потому, что говорил о базовых тулзах, а не о том, как они сынтегрированы с конкретной версией конкретной IDE (не имея, например, опыта с VS больше двухстраничных поделок, я не хочу про неё говорить вообще).
W>У тебя просто юскейсы специфичные. Мне вот interactive-add ни разу не нужен был Даже без понятия был что это такое пока твое сообщение не прочитал.
Специфичные юзкейсы у всех, а начинают так говорить, когда не понимают обстановку собеседника.
Тем не менее, да, у меня требование аккуратного расщепления коммитов по сущности изменения и возможностью каких-то локальных правок дольше, чем на коммит, является обязательным для возможности адекватного сопровождения (и никак не связано с opensource, как тут ещё выдвигалось).
Здравствуйте, alex_public, Вы писали:
N>>А эти результаты в нормальном варианте строятся в цепочку изменений (в сложном — несколько цепочек, но каждая должна быть логически закончена), так, что каждое из них N>>* делает только одно из набора: стилевые правки, рефакторинг, функциональное изменение N>>* или сделано вручную, или автоматически (как автоформаттером), кроме случаев, когда за автоформаттером надо подчищать N>>* функциональное изменение по возможности максимально однородно по сути действий N>>и только такое заслуживает передачи в общее репо так, чтобы не было чего мучительно стыдиться.
_>Это похоже на какие-то опенсорсные заморочки. )))
Это базовая гигиена работы над действительно большим проектом, и мне крайне странно слышать подобные замечания в принципе. С open source это никак не связано, скорее наоборот — пока последний находился в основном в зачаточном состоянии, эти требования уже формулировались для промышленного программирования; и те проекты, на которых в моём случае это выдвигалось, не предполагались ни для какого публичного открытия.
N>>И реально сложное изменение такого рода не сделать без возможности разделения, перестановки, слияния коммитов, выбора нужного из локальных изменений. А если какое-то современное средство прячет эту функциональность поглубже (отдельные команды, выключенные по умолчанию расширения), то его авторы целенаправленно воспитывают ламеров и говнокодеров.
_>У меня противоположное мнение. )
Это я уже понял, и на это могу только предположить, что у тебя нет проектов, которые длятся более 10 лет с неоднократной сменой команды исполнителей, при одновременной работе 20-30 человек.
Если же такие есть, я могу только посочувствовать тем проблемам, которые они разгребают за предыдущими коллегами и которые создают на свои же головы и задницы на чуть позже.
_>Собственно hg record был в старых версиях Mercruial, а в новых просто hg commit -i. Так что всё становится до конца логично и понятно, и без всяких расширений.
Но в документации так и остаётся бред.
_>Похоже что ты забыл (или может вообще не знал?) один из главных научных принципов "отрицательный результат — тоже результат". ) Это же вполне касается и инженерной работы — надо документировать весь процесс разработки, в том числе и подробно описывать все тупики.
Если это тупик, полученный в результате конструктивного и ответственного применения того, что было известно до того — да, он должен быть документирован. Но не в коде (скорее всего, он должен остаться в немерженной ветке), а в сопроводительной документации и в историческом отчёте. Типа "для выбора варианта реализации структуры было измерено 4 версии (описание версий), тикет на измерение #143502, код и результаты измерений сложены в репо BigProject.aux".
Если же это, как в >90% случаев, недоработка вида "а тут не учтён ещё один случай", "изменено 3 места применения, а ещё про 2 тупо забыто" и ловится коллегами на peer review — никакой причины "документировать" это где-то кроме поточных отчётов о проделанной работе — нет, и тем более — вечно сохранять эти ляпы и тестовые версии в коде. Там и без того будет достаточно случаев недоработки и кривой оценки.
Твои лично-оценочные выпады типа "забыл", "вообще не знал" лучше спрятать подальше, раз ты не отличаешь действительно инженерные проблемы от проблем рабочего процесса.
N>>>>Она не базовая. Базовая это цепочки коммитов. А фиксация безымянных голов это уже расширение. И это ещё раз показывает следствия безумного бардака с терминологией. _>>>А как можно организовать цепочки без фиксации? ) N>>Ключевое слово было "безымянных". Не делай вид, что не понял этого. _>Ну так в Git же цепочки тоже внутри безымянные (у них есть только хэш, как и в Mercurial), а имена вешаются поверх (как закладки в Mercurial).
Сохраняются те, которым даны постоянные ссылки. И, как я уже кучу раз говорил, это правильно.
Я был бы не против видеть безымянные головы как расширение не только в Hg, но в любой системе, но только выключенным по умолчанию, и включаемым под личную ответственность пользователя.
Здравствуйте, willie, Вы писали:
V>>Не совсем понятно зачем, но да ладно. V>>При мерже обычно создается мерж комит в котором есть информаци какая ветка куда была замержена. W>Там нет информации что входило в эти ветки.
Есть id всех предковых коммитов, порядок id соответствует направлению мержа.
W>Да и сам ответ жесть какая-то. Такая куча буков и мешанина команд чтобы просто найти что Вася пилил в своей ветке месяц назад.
Здравствуйте, netch80, Вы писали:
_>>Это похоже на какие-то опенсорсные заморочки. ))) N>Это базовая гигиена работы над действительно большим проектом, и мне крайне странно слышать подобные замечания в принципе. С open source это никак не связано, скорее наоборот — пока последний находился в основном в зачаточном состоянии, эти требования уже формулировались для промышленного программирования; и те проекты, на которых в моём случае это выдвигалось, не предполагались ни для какого публичного открытия.
Когда опенсорс был зачаточном состояние, никаких git'ов ещё и в проекте не было, так что не очень понятно о каких базовых принципах ты говоришь. Если же ты имеешь ввиду системы контроля версий тех времён, то они как раз вообще не предполагали никакой возможности правки истории и т.п.
_>>У меня противоположное мнение. ) N>Это я уже понял, и на это могу только предположить, что у тебя нет проектов, которые длятся более 10 лет с неоднократной сменой команды исполнителей, при одновременной работе 20-30 человек. N>Если же такие есть, я могу только посочувствовать тем проблемам, которые они разгребают за предыдущими коллегами и которые создают на свои же головы и задницы на чуть позже.
И чем же более подробная (а не приглаженная искусственно) история способна помешать долговременной работе над проектом? )
_>>Собственно hg record был в старых версиях Mercruial, а в новых просто hg commit -i. Так что всё становится до конца логично и понятно, и без всяких расширений. N>Но в документации так и остаётся бред.
В документации указаны оба варианта (потому что не у всех стоит обязательно последняя версия Mercurial). В документации и такие https://www.mercurial-scm.org/wiki/BookmarksExtension вещи можно до сих пор увидеть, хотя они давно не актуальны (и это там тоже указано).
_>>Похоже что ты забыл (или может вообще не знал?) один из главных научных принципов "отрицательный результат — тоже результат". ) Это же вполне касается и инженерной работы — надо документировать весь процесс разработки, в том числе и подробно описывать все тупики. N>Если это тупик, полученный в результате конструктивного и ответственного применения того, что было известно до того — да, он должен быть документирован. Но не в коде (скорее всего, он должен остаться в немерженной ветке), а в сопроводительной документации и в историческом отчёте. Типа "для выбора варианта реализации структуры было измерено 4 версии (описание версий), тикет на измерение #143502, код и результаты измерений сложены в репо BigProject.aux".
Неудобный способ. Он подходит только в том случае, если в системе отслеживания задач есть только один способ её закрыть (типа удачно). Если же есть нормальный способ указать на неудачу в реализации данной задачки и на переход к альтернативному решению, то в сочетание со связью между соответствующими задачами и ревизиями в системе контроля версий, это даёт намного более качественный вариант документации. И главное что при этом ещё и автоматический (не надо никакие специальные левые отчёты плодить).
N>Если же это, как в >90% случаев, недоработка вида "а тут не учтён ещё один случай", "изменено 3 места применения, а ещё про 2 тупо забыто" и ловится коллегами на peer review — никакой причины "документировать" это где-то кроме поточных отчётов о проделанной работе — нет, и тем более — вечно сохранять эти ляпы и тестовые версии в коде. Там и без того будет достаточно случаев недоработки и кривой оценки.
А это тоже полезно сохранять, но уже для других целей. Так сказать административно-кадровых. )))
Здравствуйте, Vladek, Вы писали:
S>>После работы с такими коммерческими тулами как ClearCase, Synergy, Rational TeamConcert мне Git показался самым разумным что было изобретено в этой области. Особенно в плане написания интеграций с ним.
V>Единственная причина популярности Git — социальная сеть для миллионов разработчиков Github. Всё, никаких других причин использовать сложную утилиту для поддержки разработки ядра Linux за пределами разработки ядра Linux — нет.
C>А оно работает с моим vim? Или обязательно в Ein Volk, ein Reich, ein Füh Визуальной Студии?
"оно" писалось для студии и работает в студии. Аналоги думаю можно найти для всех нормальных ide.
Есть ли аналоги для твоего вим не знаю. Вимом пользуюсь только для commit -m
N>Есть id всех предковых коммитов, порядок id соответствует направлению мержа.
Знаю. Есть. Круто.
Я что ли ручками это смотреть должен?
Какая-то удобная тулза есть? В tortoise git я не нашел. Есть упоротый граф веток, который без пузыря хрен разберешь.
Здравствуйте, netch80, Вы писали: N>Люди косячат. Если в результате peer review приходит замечание "ты ещё в паре мест забыл логику подправить", это достаточное основание модифицировать ранее предложенный коммит. N>На исследовательскую идею состояние "исправил три места, про ещё два забыл" не тянет даже после ста грамм.
Ты только что напесал отсебятину полную. Нету у нас такого.
Ну или ты не так понял что я написал.
N>При всём при этом ветки промежуточной подачи правок в Linux проходят такую переписку почти ежедневно, а в git help rebase есть глава, как работать, если в апстриме такое происходит.
Т.е. они сами не соблюдают свои рекомендации. Быдлоразроботка, ясно-понятно
V>Изменение должно иметь смысл и фиксироваться комитом.
Да
V>Если ты изменил одно и тоже несколько раз в течении локальной истории, значит это должно быть объединено.
Здравствуйте, ·, Вы писали:
W>>·>Бранчи сами не удаляются. Если они тебе нужны — не удаляй. W>>И потом не сможешь создать второй такой же. ·>Я смогу. А тебе что мешает?
Создать несколько локальных веток с идентичными именами?
Здравствуйте, willie, Вы писали:
W>>>·>Бранчи сами не удаляются. Если они тебе нужны — не удаляй. W>>>И потом не сможешь создать второй такой же. W>·>Я смогу. А тебе что мешает? W>Создать несколько локальных веток с идентичными именами?
Да, их можно в разных префиксах (namespaces) разместить. Полное имя будет разным, конечно, но ты пока не объяснил необходимость неразличимых имён. "Сделать так как умеет hg" я как объяснение не приму. Ибо даже в оф доках так не рекомендуют делать.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·> W>>>·>Бранчи сами не удаляются. Если они тебе нужны — не удаляй.
·> W>>>И потом не сможешь создать второй такой же.
·> W>·>Я смогу. А тебе что мешает?
·> W>Создать несколько локальных веток с идентичными именами?
·> Да, их можно в разных префиксах (namespaces) разместить. Полное имя будет разным, конечно, но ты пока не объяснил необходимость неразличимых имён. "Сделать так как умеет hg" я как объяснение не приму. Ибо даже в оф доках так не рекомендуют делать.
С одинаковыми именами у меня вопрос: 2 дева работали над разными проблемами с базой данных и назвали свои ветки db_fix. Что получим на выходе? Как определить какая именно проблема решалась в какой ветке?
Здравствуйте, alex_public, Вы писали:
_>>>Это похоже на какие-то опенсорсные заморочки. ))) N>>Это базовая гигиена работы над действительно большим проектом, и мне крайне странно слышать подобные замечания в принципе. С open source это никак не связано, скорее наоборот — пока последний находился в основном в зачаточном состоянии, эти требования уже формулировались для промышленного программирования; и те проекты, на которых в моём случае это выдвигалось, не предполагались ни для какого публичного открытия. _>Когда опенсорс был зачаточном состояние, никаких git'ов ещё и в проекте не было, так что не очень понятно о каких базовых принципах ты говоришь.
Всё о тех же. Простые тупые системы уже были.
_> Если же ты имеешь ввиду системы контроля версий тех времён, то они как раз вообще не предполагали никакой возможности правки истории и т.п.
Именно так. И введение staging поэтому стало революционным расширением.
_>И чем же более подробная (а не приглаженная искусственно) история способна помешать долговременной работе над проектом? )
Бессмысленным мусором, который разбирать требуется на порядок-два больше усилий.
_>В документации указаны оба варианта (потому что не у всех стоит обязательно последняя версия Mercurial).
Ты даже не пытаешься понять, что я написал.
Мне пофиг, что что-то представлено ещё и в виде extension. Legacy — штука полезная (ограниченно во времени). Мне не пофиг, что вместо "закоммитить на выбор" команда описана как "сделать выбор, что коммитить", потому что последнее описание безусловно неадекватно.
N>>Если это тупик, полученный в результате конструктивного и ответственного применения того, что было известно до того — да, он должен быть документирован. Но не в коде (скорее всего, он должен остаться в немерженной ветке), а в сопроводительной документации и в историческом отчёте. Типа "для выбора варианта реализации структуры было измерено 4 версии (описание версий), тикет на измерение #143502, код и результаты измерений сложены в репо BigProject.aux". _>Неудобный способ. Он подходит только в том случае, если в системе отслеживания задач есть только один способ её закрыть (типа удачно).
Он подходит ко всем вариантам закрыть задачу.
_> Если же есть нормальный способ
Пропаганда.
_> указать на неудачу в реализации данной задачки и на переход к альтернативному решению, то в сочетание со связью между соответствующими задачами и ревизиями в системе контроля версий, это даёт намного более качественный вариант документации. И главное что при этом ещё и автоматический (не надо никакие специальные левые отчёты плодить).
Они не левые. Код не заменяет документацию.
Если решено код попытки сохранить, он идёт в experiments/ или аналогичную иерархию веток, может — в отдельное репо. Висеть безымянной независимой головой ему не надо.
Но такое решение сохранить — нетипично.
N>>Если же это, как в >90% случаев, недоработка вида "а тут не учтён ещё один случай", "изменено 3 места применения, а ещё про 2 тупо забыто" и ловится коллегами на peer review — никакой причины "документировать" это где-то кроме поточных отчётов о проделанной работе — нет, и тем более — вечно сохранять эти ляпы и тестовые версии в коде. Там и без того будет достаточно случаев недоработки и кривой оценки. _>А это тоже полезно сохранять, но уже для других целей. Так сказать административно-кадровых. )))
Это на уровне логов, кто сколько в туалет ходил. Уважающие себя программисты бьют начальство за такое.
Здравствуйте, Dziman, Вы писали:
D>·> Да, их можно в разных префиксах (namespaces) разместить. Полное имя будет разным, конечно, но ты пока не объяснил необходимость неразличимых имён. "Сделать так как умеет hg" я как объяснение не приму. Ибо даже в оф доках так не рекомендуют делать. D>С одинаковыми именами у меня вопрос: 2 дева работали над разными проблемами с базой данных и назвали свои ветки db_fix. Что получим на выходе? Как определить какая именно проблема решалась в какой ветке?
Их ветки будут иметь локальные названия db_fix, когда они решат обменяться коммитами, то чужие ветки появятся с префиксом remotes/ — их легко различить.
Из названия "db_fix" извлечь описание проблемы не выйдет никак, даже со всеми расширениями hg вместе взятыми.
Поэтому проблема должна быть описана в сообщениях коммитов или коммиты должны иметь линки в трекинговую систему. И hg тут не исключение.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
