Здравствуйте, Нахлобуч, Вы писали:
Н> A>проще — согласен, только откуда там больше возможностей?
Н> А вопросом на вопрос можно? Спасибо. Что такого умеет Git, что не умеет Mercurial?
Может я всего не знаю о hg, но мне кажется, что из этого точно много чего не умеет: octopus merge — слияние больше чем двух веток сразу.
subtree merge — каталог репозитория мержится туда-сюда с другим репозиторием
index — Очень полезно во время разрешения конфликтов. Супер вещь для любителей командной строки, для оформления аккуратных коммитов.
rerere — Reuse recorded resolution of conflicted merges
notes — добавление меток, аттачей поверх иммутабельной истории.
reflog — история истории.
gerrit — gated commits, peer review тулза с веб-интерфейсом, "submit over the web" фича. Идеальна для enterprise разработки.
orphan branch — отдельная история в том же репо. Польза: тут, тут, notes и gerrit настройки репо тоже сирот эксплуатируют.
author/committer — инфа в коммите — тот кто сделал изменение и тот кто его опубликовал — разные люди|даты.
filter-branch — хитровывернутое перелопачивание репозитория для очищения истории. Например, массово заменить табы-пробелы.
log pickaxe — массовый поиск по истории регекспами.
git annex — манипуляция массивными файлами.
tracking file permissions, symlinks
.gitattributes — кастомизация всяких свойств различных файлов. Например, указать специальный алгоритм мержа файлов в некотором каталоге или unix line endings для всех .sh файлов.
shared clone — легковесный клон, который использует данные из репо на том же диске.
grafts/replace — механизмы для рефакторинга истории.
Простой, но очень мощный и гибкий формат репозитория.
Ы?
Н> Наоборот -- это да. В Git'е даже близко нет аналога веток из Mercurial и поэтому, помимо всего прочего, история коммитов изобилует "merged remote tracking branch x/y from zzz".
И это правильно Как оно работает в mercurial — это противоречит духу DVCS совершенно, убогое наследие SVN. Вызывает трудности если требудется мержиться из многих репозиториев.
Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ> T>Ага только централизованная система у себя в серверной в прямой доступности, а распределенная на битбакете, появляется дополнительный канал Офис <-> репа, а его наличие и работоспособность зависит от провайдера и следующего аплинка(ов). Первоначально речь шла о билд сервере который делает сборки и ему надо обязательно выгребать изменения. Для разработчиков временная недоступность относительно безразлична. SVZ> Вах, а что, гит не ставится на локальном сервере?
Так там всё SVN-ом забито.
The Mozilla CVS repository was 2.7GB, imported to Subversion it grew to 8.2GB. Under Git, it shrunk to 450MB. Given that a Mozilla checkout is around 350MB, it's fairly nice to have the whole project history (from 1998) in only slightly more space.
Здравствуйте, ., Вы писали:
S>> Это только то, что я активно использую. .>Ужас. Убожество. Застряли в развитии лет на пять-семь по сравнению с IntelliJ.
Ну эт да, одна IntelliJ д'Артаньян, все остальные — микрософты
Всё вышеперечисленное (за исключением разве что истории произвольного блока кода, не попадалось) прикручивается расширениями студии.
Вот дифф (хотя для сложных случаев я бы предпочёл semantic merge).
Вот подсветка изменений.
Речь вообще-то шла только об одном из окон ankhsvn. Вот с ним — беда-беда, похожего для гита/hg в студии не попадалось.
Здравствуйте, Miroff, Вы писали:
M>Когда говорят про "легкий мержинг и меньше конфликтов" имеют в виду следующее: git позволяет переписывать историю коммитов. Это дает тебе возможность перед пушем ветки на сервер сделать rebase к текущему master, что в свою очередь приведет к тому что влитие этой ветки в master гарантированно будет fast-forward слиянием без конфликтов. Естественно при ребейзевозможны конфликты, но M>1) их будешь разрешать автор кода, а не его коллеги которые без понятия что он там написал
Как будто этого нельзя делать в svn? Автор ветки мержит мастер в свою ветку и разрешает конфликты. Далее мерж этой ветки в мастер совершенно механическая операция.
Здравствуйте, GarryIV, Вы писали:
GIV>Как будто этого нельзя делать в svn? Автор ветки мержит мастер в свою ветку и разрешает конфликты. Далее мерж этой ветки в мастер совершенно механическая операция.
И в результате получается неудобоваримая история.
Здравствуйте, Sinix, Вы писали:
.>>Ужас. Убожество. Застряли в развитии лет на пять-семь по сравнению с IntelliJ. S>Ну эт да, одна IntelliJ д'Артаньян, все остальные — микрософты
Именно так.
S>Всё вышеперечисленное (за исключением разве что истории произвольного блока кода, не попадалось) прикручивается расширениями студии.
Неа.
S>Вот дифф (хотя для сложных случаев я бы предпочёл semantic merge). S>Вот подсветка изменений.
Ужас. IntelliJ понимает именно семантику кода — используемые типы, может делать рефакторинг и т.д. Тут просто подсветка блоков по matching'у скобок + простая подсветка синтаксиса.
Разница как между VIM и MSVS.
S>Речь вообще-то шла только об одном из окон ankhsvn. Вот с ним — беда-беда, похожего для гита/hg в студии не попадалось.
ЩИТО?
Ну хоть на IntelliJ посмотри. Или на гитхабовский клиент.
Здравствуйте, Cyberax, Вы писали:
GIV>>Как будто этого нельзя делать в svn? Автор ветки мержит мастер в свою ветку и разрешает конфликты. Далее мерж этой ветки в мастер совершенно механическая операция. C>И в результате получается неудобоваримая история.
Здравствуйте, ., Вы писали:
.>octopus merge — слияние больше чем двух веток сразу.
Этого нет by design.
.>subtree merge — каталог репозитория мержится туда-сюда с другим репозиторием
Не совсем понял, что это.
.>index — Очень полезно во время разрешения конфликтов. Супер вещь для любителей командной строки, для оформления аккуратных коммитов.
Есть hg record, который так же позволят коммитить файлы по частям. Индекса нет, верно.
.>rerere — Reuse recorded resolution of conflicted merges .>notes — добавление меток, аттачей поверх иммутабельной истории.
Этого нет.
.>reflog — история истории.
Есть Changeset Evolution, который суть DVCS для DVCS (распределенный, коллективно редактируемый Reflog)
.>gerrit — gated commits, peer review тулза с веб-интерфейсом, "submit over the web" фича. Идеальна для enterprise разработки.
Это не совсем Git.
.>orphan branch — отдельная история в том же репо. Польза: тут, тут, notes и gerrit настройки репо тоже сирот эксплуатируют.
Такое может.
.>author/committer — инфа в коммите — тот кто сделал изменение и тот кто его опубликовал — разные люди|даты.
Такое нет.
.>filter-branch — хитровывернутое перелопачивание репозитория для очищения истории. Например, массово заменить табы-пробелы.
hg convert
.>log pickaxe — массовый поиск по истории регекспами.
hg revsets в разы мощнее.
.>git annex — манипуляция массивными файлами.
Этого не знаю.
.>.gitattributes — кастомизация всяких свойств различных файлов. Например, указать специальный алгоритм мержа файлов в некотором каталоге или unix line endings для всех .sh файлов. .>shared clone — легковесный клон, который использует данные из репо на том же диске.
Mercurial использует симлинки.
.>grafts/replace — механизмы для рефакторинга истории.
Всё это есть.
.>Простой, но очень мощный и гибкий формат репозитория.
Тут да.
HgLab: Mercurial Server and Repository Management for Windows
Здравствуйте, GarryIV, Вы писали:
GIV>>>Как будто этого нельзя делать в svn? Автор ветки мержит мастер в свою ветку и разрешает конфликты. Далее мерж этой ветки в мастер совершенно механическая операция. C>>И в результате получается неудобоваримая история. GIV>Где? Я как бы каждый день этим пользуюсь?
Это что-то меняет в том, что история получается жутко нелинейной, особенно при множественных merge'ах?
Здравствуйте, AndrewVK, Вы писали:
AVK>Гит, по секрету тебе скажу, сейчас для студии совсем не чужеродный, доступен искаропки и используется внутри МС в том числе и теми, кто пишет студию и инструменты для нее.
Эта интерграция какая-то малоюзабельная. Проще работать с гитом из Тортисы или вообще из консоли
Откуда же его [независимый суд] взять, если в нем такие же как мы? (c) VladD2
.>>subtree merge — каталог репозитория мержится туда-сюда с другим репозиторием
Н>Не совсем понял, что это.
На практике это значит, что можно импортировать другой репозиторй/каталог репозитория как подкаталог своего репозитория.
В дальнейшем с этим каталогом можно работать как со снапшотом исходного репозитория: git subtree pull, git subtree push, git subtree merge.
В остальном этот каталог ничем не отличается от других, в этом преимущество перед субмодулями.
.>>reflog — история истории.
Н>Есть Changeset Evolution, который суть DVCS для DVCS (распределенный, коллективно редактируемый Reflog)
Пришлось перейти на гит как раз когда эта штука появилась. На данный момент её уже используют?
.>>git annex — манипуляция массивными файлами.
Н>hg largefiles
Annex по сути отдельная программа. Умеет всё вплоть до работы с амазоновским хранилищем.
largefiles это костыль. Официально не рекомендован.
Откуда же его [независимый суд] взять, если в нем такие же как мы? (c) VladD2
Здравствуйте, Sinix, Вы писали:
S>Ну эт да, одна IntelliJ д'Артаньян, все остальные — микрософты
Так поделаешь-то, если оно так и получается. Вот допилят clion, и плюсовики со Студии соскочат. Зачем микрософту стараться, ведь у них родной шарп, и куда денешься с подводной лодки?
S>Всё вышеперечисленное (за исключением разве что истории произвольного блока кода, не попадалось) прикручивается расширениями студии. S>Вот дифф (хотя для сложных случаев я бы предпочёл semantic merge).
Если оно и правда работает и юзабельно, то уже хорошо, становится похоже на IDEA9 или 10 (версия <2010 года). Сейчас пилят IDEA14.
S>Вот подсветка изменений.
И что характерно — только для git (и вообще специфичный софт для каждой vcs). SVN как всегда, лесом.
S>Речь вообще-то шла только об одном из окон ankhsvn. Вот с ним — беда-беда, похожего для гита/hg в студии не попадалось.
В IntelliJ вшита обобщённая поддержка vcs, так что таких бед нет.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, neFormal, Вы писали:
F>товарищ не чтит доки. F>более того, он не чтит даже то, что git ему прямым текстом написал.
Надо признать, у git-а таки отвратительные доки.
Здравствуйте, Нахлобуч, Вы писали:
Н>Здравствуйте, ., Вы писали:
.>>octopus merge — слияние больше чем двух веток сразу. Н>Этого нет by design.
Почему? В смысле специально запрещено? Или неудачно выбранный формат репозитория?
.>>subtree merge — каталог репозитория мержится туда-сюда с другим репозиторием Н>Не совсем понял, что это.
Когда ты включаешь исходники 3rd party репо как обычный подкаталог в твой репо. Так можно делать и возможность обмена изменениями туда-сюда остаётся. http://git-scm.com/book/en/Git-Tools-Subtree-Merging
.>>index — Очень полезно во время разрешения конфликтов. Супер вещь для любителей командной строки, для оформления аккуратных коммитов. Н>Есть hg record, который так же позволят коммитить файлы по частям. Индекса нет, верно.
Тут не просто по частям коммитить, а выбрать точно что ты хочешь закоммитить и закоммитить. Скажем, "добавить пятый кусок файла qer/asdf.txt, добавить каталог abc, исключить подкаталоги abc/de, abc/fe/xy, смотрим получившийся дифф, добавить девятый блок, коммитим". И всё быстро, а не бешенно кликая мышкой по чекбоксам и деревьям, или сочиняя длиннющуу commandline которая пытается всё сделать одним махом. При конфликтах — неконфликтные файлы уже добавлены в индекс, видны конфликты, которые после разрешения можно ещё раз просмотреть, отфильтровав неконфликтные.
.>>reflog — история истории. Н>Есть Changeset Evolution, который суть DVCS для DVCS (распределенный, коллективно редактируемый Reflog)
Это не то. reflog показывает историю того, что ты делал — вот ты переключился на бранч, вот ты сделал cherry-pick, вот замержил, вот заребейзил, вот reset, вот stash и т.п.
.>>gerrit — gated commits, peer review тулза с веб-интерфейсом, "submit over the web" фича. Идеальна для enterprise разработки. Н>Это не совсем Git.
Однако архитектура git хорошо способствует этой тулзе. На hg такое реализовать было бы сложнее.
.>>log pickaxe — массовый поиск по истории регекспами. Н>hg revsets в разы мощнее.
Чем? git log, git rev-list тоже не лыком шиты.
.>>git annex — манипуляция массивными файлами. Н>hg largefiles
Может я что-то не понял, но оно какое-то примитивное, вроде. Например, подразумевает "The central store". Какой же это DVCS? annex поддерживает реальные distributed workflow для больших файлов.
.>>grafts/replace — механизмы для рефакторинга истории. Н>Всё это есть.
А подробнее? Поменять родителей коммита? Соединить две независимые истории в одну линию?
.>>Простой, но очень мощный и гибкий формат репозитория. Н>Тут да.
И благодаря этому получается много плюшек и при этом всё очень просто.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, BRAhMS, Вы писали:
F>>товарищ не чтит доки. F>>более того, он не чтит даже то, что git ему прямым текстом написал. BRA>Надо признать, у git-а таки отвратительные доки.
хз, ProGit обычно хватает.
а в man я лезу только за флажками.
Здравствуйте, neFormal, Вы писали:
F>хз, ProGit обычно хватает. F>а в man я лезу только за флажками.
Я, в основном. тоже. Но попервах очень трудно пользоваться их доками.
К примеру вот дока по push: git push
Имеется минимум познаний гита и требуется удалить ремоутный бранч. Найти для этого способ будет непросто, хотя операция должна быть элементарной.
Здравствуйте, BRAhMS, Вы писали:
F>>товарищ не чтит доки. F>>более того, он не чтит даже то, что git ему прямым текстом написал. BRA>Надо признать, у git-а таки отвратительные доки.
Они своеобразные (git help я имею в виду, книги и прочее обычно гораздо дружелюбнее). Они подразумевают понимание происходящего. А новички лезут со своим привычным пониманием, вот я делал "svn add", давай-ка посмотрю ключики "git add" — ой а что это??!
Когда вникаешь в суть, то доки воспринимаются очень хорошо — точно, аккуратно, всё по делу. Просто справочник. Для обучения есть другие материалы.
steep learning curve, как говорится.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, AndrewVK, Вы писали:
Pzz>>Нет. В репозитории не делается ничего. Репозиторий только хранит информацию. Все остальное делается локально.
AVK>Но локально у гита весь репозиторий.
По контексту я предполагаю, что народ репозиторием назвал сервер. Могу, конечно, ошибаться.
Здравствуйте, Cyberax, Вы писали:
C>>>И в результате получается неудобоваримая история. GIV>>Где? Я как бы каждый день этим пользуюсь? C>Это что-то меняет в том, что история получается жутко нелинейной, особенно при множественных merge'ах?
Никак не пойму твоих проблем. Что такое нелинейная история?
