Comments 425
echo $'USER vasya\nPASS qwerty\nPASV\nSTOR...' >/dev/tcp/$host/21
тогда уже, господа извращенцы.1) Положить файл на какую-либо шару, а в каком-либо сборочном скрипте указать где его брать
2) Положить непосредственно в CVS
Второй способ лучше:
1) Знаете какой из «умных людей» удалил столь нужный файл!
2) Нет такой ситуации, когда Вы не знаете при решении какой задачи потребовался этот файл?
3) Админам, как правило проще бэкапить
Банально: about.png это текстовой файл? ;)
А кроме того, никто не умеет нормально мержить бинарники, да и возможность вытащить часть репозитория очень полезна бывает.
Так что код — в git (или hg), а данные -в svn!
Конечно есть там чексуммы.
Битый файл мог быть у вас потому что вы его туда отправили битым (битая память?). В противном случае можно было с нескольких попыток получить целый файл.
А поповоду надёжности — попробуйте забэкапить git репозиторий в файлы, инкрементальным бэкапом, все бранчи.
(в файлы — это в смысле — при условии что целевой бэкап будет где-нибудь на S3 храниться, и прав на удаление/изменение файлов не будет, только на добавление — ведь именно так нужно настраивать права чтобы какой-нибудь злоумышленник не стёр и бэкап при компрометации машины)
Пруф что не проверяет?
Ну да, проект был задеплоен год назад с битыми файлами. Если бы это был единичный случай, то ладно. С гитом за 4 года таких проблем не было.
Любой клон гита — это уже бекап. Для того, чтобы забекапить на том же S3 достаточно синхронизировать все ветки. И если история не будет переписываться, то файлы будут только добавляться.
Любой клон гита — да тоже бэкап.
А вот бэкап копированием папки git — после git gc всё будет перезаписываться. К тому же чтобы он был в 100% случаев консистентным тоже нужно постараться вроде как.
Сделать такой бэкап с помощью git bundle — это нужно постараться. И писать это не на bash. И желательно с unit тестами. При этом метки бранчей-тэгов не будут «инкрементальными» (впрочем они не много места занимают)
Бренчи и теги практически ничего не весят, это метаданные. А инкрементальными бекап можно получить если, например, пушить на север бекапа по крону (или наоборот пулить с сервера бекапа). Причем без параметра --force он ничего не перезапишет. И еще советую почитать про параметр --mirror.
git bundle удобен для разового переноса. В принципе это создание данных для push перед отправкой на сервер.
Если же вы хотите бекапить просто набор файлов некоторого снапшота: git archive --help
Git bundle же может делать аналогичное только если 1 бранч. (если много бранчей то это очень сложно).
p.s.
про другие способы бэкапов git'а я знаю, спасибо.
Git bundle же может делать аналогичное только если 1 бранч. (если много бранчей то это очень сложно).
Поищите в справке параметр --all и сложность отпадет.
Другие способы бекапа — pull/push в удаленный bare репозиторий. Если на удаленном сервере не стоит git, то папку с репозиториями можно монтировать в файловую систему с помощью fuse и запускать нужную операцию гита на локальном сервере.
stackoverflow.com/questions/12129148/incremental-backups-with-git-bundle-for-all-branches
правильный ответ описан рядом с этой строчкой
git bundle create newbackup.bundle ^backup/A ^backup/B A B C
1) Открыть в TaskCoach docs\projects.tsk
2) Добавить задачу
3) Cохранить
4) В виду того что файл docs\projects.tsk изменился выполняем команду в консоли: hg ci -m «added new task»
Если закрываем задачу, тоже самое. Если изменяем приоритеты — тоже самое.
Я бы хотел что-нибудь похожее на такой use-case:
1) hg task-add «Зарефактори ClassName.super_method()»
2) hg ci -m «added new task»
еще лучше чтобы п.1 и п.2 в одном.
Если надо посмотреть что есть:
hg task-list
выводится список имеющихся не закрытых задач
Если надо закрыть задачу, то:
hg task-close номер_задачи
Это пример того что я хочу.
Не хватало ещё и холивара по поводу Git VS Mercurial :D
Для проектов на C++, где время сборки может быть большим это иногда важно.
Ну а дальше git checkout ваш_бранч, или использовать тот же самый бранч, это уже как нравится
Тем не менее, при работе склоном нужно будет делать push в оригинал, и потом с оригинала на сервер, конечно мы так же можем поправить и конфиг, но тогда надо будет кидать комиты через сервер, что нам точно не нужно.
С симлинком, можно работать даже с одной версией и отправлять на сервер из любой папки. И Stage файлы будут видны в обоих, так же как и комиты, без лишних pull/push, но с checkout и ресет…
Тут уж очень сильно зависит от того что нужно делать. А там хоть клон, хоть симлинк, да хоть полная копия .git
> hg up <branch-name>
посмотреть бранчи:
> hg branches
дать имя бранчу:
> hg branch <new-branch-name>
закрыть бранч:
> hg ci --close-branch -m «branch is close»
мержим текущий бранч с другим:
> hg merge <branch-name>
не забудем тут же закомитить мерж:
> hg ci -m «branches merge»
тута:
-m «это указание сообщения коммита»
В случае же, если проект на столько критичен, что нужно волноваться об одной опечатке в описании, возможно есть смысл иметь модерацию комитов перед мержем в основную ветку. Это так же позволить повысить качество кода, и иметь комиты только по делу.
Предположим что это не критично, как это сделать? Просто когда я искал способ это сделать, то единственным рабочим решением оказалось использовать git filter-branch, в котором проверять хеш коммита и заменять текст. Буду рад увидеть лучшее решение :)
Вот тут подробнее: git-scm.com/book/ch6-4.html
У git нет огромного количества хуков (например, preoutgoing, все pre-{command}, …).
У git нелогичное распределение функциональность по командам: checkout создаёт ветки или обновляет дерево, push отправляет изменения или удаляет их на том конце, diff может показывать изменения между ревизиями, а может — status, причём сам status этого не умеет…
У git иногда плохая обработка аргументов командной строки (pull принимает сначала аргументы для merge, затем для fetch).
У git плохая документация — она настолько подробна, что отыскать нужное зачастую не представляется возможным. Вместе с неочевидным распределением функциональности по командам это создаёт проблемы.
Аналог revsets у git обладает куда как меньшими возможностями.
Многие команды git, показывающие список ревизий, не имеют возможности настройки формата вывода.
У часто используемых команд вроде push/pull есть ненужные обязательные аргументы: «git push origin :branch».
У git нет аналога «hg incoming».
У git нет удобного аналога «hg grep».
Большую часть претензий можно игнорировать или терпеть. Но не первые две.
Кроме того, это независимый проект. Если человек использует git, то консольный клиент у него окажется почти наверняка, а вот libgit2 — нет. А вот с mercurial и bazaar не так — если он есть, то почти наверняка установлен «нормально», т.е. доступен для импорта в python. К subversion тоже зачастую прилагается C‐шная библиотека (официальная!). К git не прилагается ничего.
У часто используемых команд вроде push/pull есть ненужные обязательные аргументы: «git push origin :branch»
SYNOPSIS
git push [--all | --mirror | --tags] [-n | --dry-run] [--receive-pack=<git-receive-pack>]
[--repo=<repository>] [-f | --force] [--prune] [-v | --verbose] [-u | --set-upstream]
[<repository> [<refspec>...]]
У меня работает именно так, как в описании, то есть ни repository, ни refspec не являются обязательными, у них есть значения по умолчанию.
Но лично я их чаще всего в явном виде прописываю, чтобы самому себе точно показать что и куда я push'у, например.
Но потом заметил, что перестал случайно добавлять всякую ерунду в коммиты, и плеваться закончил.
pqr7.wordpress.com/2011/01/07/a-git-users-guide-to-mercurial-queues/
Или имеется в виду python-hglib, который запускает в фоне процесс hg и парсит его текстовый вывод?
А cli для hg — точно так же плохо, как для git. Те, кому надо написать интеграцию с mercurial просто забивают на совет его не использовать.
Никто не занимается сломом API «из любви к исскусству», поэтому просто не лезьте в дебри, следите за изменениями и получите нормальную поддержку всех версий, в том числе тех, когда Command Server не существовал. С бонусом в виде отсутствия затрат на IPC или даже жутких затрат на fork/exec.
На самом деле, расширения ломаются даже чаще — им нужны бо́льшие дебри.
git push отправляет/обновляет только состояние веток (указатель) в remote. Удаление указателя — это тоже обновление.
git status — (из мана) Displays paths that have differences between the index file and the current HEAD commit. Никто и не говорил, что должны показываться изменения в файлах, только изменённые файлы. И это ожидаемо: «Гит, скажи мне какие файлы поменялись»
git diff — как и ожидается из названия показывает эту самую разницу. «Гит, покажи мне сделанные изменения»
про push/pull и необязательные аргументы вам ответили. Git децентрализованная система, стало быть remotes у вас может быть несколько. Если вы делаете форк на гитхабе, потом локально редактируете, то наверняка захотите добавить upstream репозиторий для подтягивания изменений к себе. указывать явно репозитоий (origin) — это уже хорошая привычка.
hg incoming — честно, не работал с mercurial, но полагаю что речь идёт про git fetch.
Каждый будет хвалить тот инструмент, в котором он лучше разобрался. Это и закономерно, чем лучше разбираешься — тем более успешный опыт, тем круче кажется сам инструмент.
Единственная проблема (проблема ли?) git — он не поощраяет и не прощает работу по принципу «ну я ща начну работать, мне вот срочно надо, а потом как-нибудь выучу». Разберись, а потом пользуйся и радуйся. Кстати, с линуксами то же самое.
ПС. Фраза на проекте была: «я уже всё запушил, а потом закоммитал то, что нужно. Забирайте».
git checkout -b
ветки, вызывает для этого git branch
или скачивает vim (с +python), python, pygit2 и libgit2 и по этой цепочке делает своё дело. Вызовом git checkout -b
создаются ветки? Да. Значит git checkout
создаёт ветки.git status
не умеет --name-status
. В особенности для произвольных ревизий. Хотя, если подумать, то с разницей в информации и формате в выводе, он и не должен уметь. Просто status
в git объединяет hg resolve --list
и hg status
. В mercurial hg status
от diff --name-status
ушёл недалеко и то только для текущего дерева (для двух ревизий — фактически полные аналоги).Обычно у меня одно место куда я делаю push. И другое одно, откуда делаю pull.
git
— не единственная система, имеющая remotes или аналог. Мне удобно не писать куда я хочу сделать push/pull. С mercurial я не пишу. Что‐то мне подсказывает, что, используй я bazaar, я бы тоже не писал. Почему вообще в git так радикально не любят -o/--option в нескольких ключевых местах? hg push origin --bookmark upstream
сразу даёт понятие о том, что и куда вы толкаете. git push origin upstream
— нет. Насколько мне известно, mercurial использует только однотипные аргументы без -o/--option: два файла тут встретиться могут, ревизия и файл — никогда.hg incoming
ничего не загружает в репозиторий. Это не git fetch
. При этом коммиты можно просмотреть полностью, вплоть до diff’ов. Конечно, в последнем случае они физически загружаются (и ещё раз при hg pull
). Но в репозиторий не попадают. Если я сделаю git fetch
, то мне придётся думать, как удалить ненужные изменения. А потом ещё придётся самостоятельно делать fast‐forward для нужных. Может здесь и есть команда вроде hg rollback
, но я её не знаю.А про линуксы мне говорить не надо. Я просто ничего не уча установил себе Ubuntu. Именно по этому принципу¹. Потом почти так же² пересел на Gentoo, в процессе правда читая handbook.
Кроме того, как я сказал, замечания не фатальные. За исключение API и hook’ов. А также справки для инопланетян и необходимости знания кишок. Подтянется libgit2, будет гораздо лучше, я и сейчас её начинаю использовать.
Проблемы из третьего предложения (справка и кишки) меня уже слабо волнуют. Но это причина, по которой я не буду советовать
git
ни одному из новичков. Тем более, что git позволяет новичку отстрелить себе ногу с максимальной эффективностью: удалить всё и у себя, и на том конце. Неизменяемая история после git меня уже слегка раздражает, но 1. над этим работают и 2. это давало уверенность в том, что фатально я ничего не напорчу. (Давало: сейчас такую уверенность даёт опыт работы с обеими системами.)¹ В Windows по совершенно непонятным причинам через несколько дней после установки начинал тормозить интернет. В Ubuntu он не тормозил. Вторая часть мотивации: linux — это не так как у всех, а потому круто (как несложно догадаться, решение принималось ещё в школе). Ни одного linux‐гуру вокруг не было, только такие же разговоры от других школьников, которые его где‐то видели. «Совершенно непонятные причины» также замечательно характеризуют уровень компьютерного знания.
² Только на этот раз было не «надо», а «интересно». И вторая часть ещё никуда не делась. Ну и проблемы от неопытности я себе тоже создал. Не такие большие, как были в Windows, и не причина перейти на что‐то радикально новое, но тоже не сахар.
Мода/популярность
Между прочим при прочих равных это не такой плохой аргумент в IT
Git не нужен UI как таковой, потому что все делается достаточно просто, быстро, удобно и безопасно из консоли.
UI может требоваться в двух случаях merge/diff — для этого есть миллион утиит которые прекрасно подключаются к Git и Mercurial впрочем тоже.
И чтобы посмотреть/поискать по дереву, с этим отлично справляется gitk (хотя есть еще десяток проектов разнйо степени стрёмности)
А «внутренности наружу» — скорее всего имеются ввиду огромное число команд вроде «git unpack-file», предназначенных исключительно для использования их в скриптах.
Удивительно, как похожи контр-аргументы гитфанов :).
Ну и вот, собсна, проблема нормального GUI не решена. Ближе всего SmartGit, но он платный, а никто им покупать его не стремится. Бесплатных GUI, хотя бы близко приближающихся к Mac'овскому SourceTree походу в природе не существует. (Тут должна быть вставлена картинка «WHY?»)
Под маком есть прекрасный Tower (если денег не жалко) и чуть менее прекрасный SourceTree. А вот под линуксом меня от имеющихся интерфейсов аж передёргивает.
cit config alias.tree = log --graph --pretty=format:'%C(bold yellow)%h%Creset %s %C(bold blue) %an%C(bold cyan)%d %C(bold black)-> %cr%Cgreen'
и отсутствие необходимость смотреть дерево. :-)
![](https://habrastorage.org/storage2/4b1/366/1b2/4b13661b2ec4cfb986f96773c7de8b15.png)
Одна длинная строка — и все отображение развалилось…
![](https://habrastorage.org/storage2/602/8fa/e36/6028fae36c63a5cbb9f5ca36533d51bc.png)
Но мне как-то хватало, уж не знаю почему. Возможно из-за того, что у меня нет таких ветвлений. Или я не говорю --all. :-)
Но вот оказывается, что нельзя достаточно полно посмотреть на обычном экране дерево в хоть сколько-то сравнимой с гуи форме.
Вот как оно выглядит в gitg:
![](https://habrastorage.org/storage2/e6a/aa6/194/e6aaa61940af34aaf8fc3a3ead036da0.png)
Куда делись остальные ветви? понятия не имею. Может их там и не было или где-то далеко вверхе и внизу у них стоят красивые цветные стрелочки, чтобы было понятно в каком столбце и чего ждать
насчет all — тупо скопировал команду из вашего альяса.
Я не спорю, что красивый gui полезен для просмотра и повседневной работы разработчика/менеджера, но для меня он не очень важен, а вот многие вещи, которые есть в командной строке (filter-branch например) я использую относительно часто. Так что так выходит, что мне GUI не нужен.
один из коллег любит делать пространные комментарии к коммитам, за что его уж совсем никак винить нельзяПосоветуйте своему коллеге в первой строке комментария писать очень коротко о чём этот коммит вообще, а пространный комментарий начинать со второй строки.
Git не нужен UI как таковой, потому что все делается достаточно просто, быстро, удобно и безопасно из консоли.
Являсь сторонником git и достаточно ярым почитателем консоли (мержу, например, исключительно с использованием vim), отмечу, что следующие вещи делать без GUI жутко неудобно:
1. Рассматривать дерево истории
2. Брать в commit лишь часть локальных изменений файла
3. Просматривать аннотацию (кто, какие изменения и в каких версиях внес)
4. Смотреть дифф при большом количестве изменений или когда необходимо знать контекст изменения в широком смысле (то бишь полазить по файлу, чтобы понять, а что тут что)
капелька оффтопа: а вы можете на толковые гайды для совсем ничего не знающих о виме ссылки дать? Гуглом пользоваться умею, но хочется именно правильный материал — сам, ввиду отсутствия знаний, оценить адекватность не смогу.
Это по сути запущенный vim с текстовым файлом (правда, на английском, надеюсь, что не проблема), в котором тебе рассказывают, что к чему, и ставят задания, которые в нем же и выполняешь.
Базовые навыки осваиваются на ура.
Еще есть вот это: www.google.ru/search?q=vim+graphical+cheat+sheet&hl=ru&newwindow=1&client=safari&tbo=u&rls=en&tbm=isch&source=univ&sa=X&ei=69kUUY-kL-Gq4ASd3YCIAw&ved=0CDwQsAQ&biw=1279&bih=904
А потом уже хелп самого vim для более тонкой настройки.
Прошу учитывать, что я не гуру vim, я не пишу для него плагины, например, и не делаю из него ide, как некоторые.
Для меня это просто достаточно удобный текстовый редактор — не более.
Хотя код под линуксом я пишу исключительно в нем.
Он как раз решает все проблемы перечисленные вами :)
Попробую при случае.
Переносите изменения налево, сохраняете и получаете это в staging.
- Показывает состояние рабочей копии и какие файлы будут включены в изменение (первая колонка: не включён/включён частично/включён полностью/не включён, но редактировался для частичного включения)
- Позволяет выбрать файлы для полного включения (в т.ч. неизвестные и удалённые, они будут добавлены или забыты). Причём выбрать скопом
- Позволяет отменить изменения, предназначенные для частичного внесения или переоткрыть их заново
- Хранит всю историю включений/изменений текущей сессии. То есть, делая undo/redo в окне состояния вы можете отменить или восстановить сделанные частичные изменения (правда гранулярность пока ниже: сохраняется только последнее состояние перед следующим изменением, произведённым в окне состояния; история правок внутри файла не сохраняется).
Можно узнать, как со всем этим справиться в fugitive?
Хотя кое‐что прояснилось: 1, 2, 3 есть (хотя и с замечаниями). 4 нету. Похоже, если есть staging area, то fugitive удобнее (4 не особо нужно) в этом отношении.
Кроме того, одним из основных предназначений дополнения является унификация работы в различных системах контроля версий.
Вот здесь думаю вы не правы:
у каждой системы контроля версий свои особенности и свой «дзен». Пытаясь унифицировать их все к одному интерфейсу вы тем самым ограничиваете их функционал, кроме того в отдельных случаях это может быть не возможно, либо ввести пользователя в заблуждение
(к примеру команда pull в Git и Hg делает разные вещи).
Поэтому я считаю что стоит придерживаться юникс подхода к таким плагинам — Write programs that do one thing and do it well.
Я лучше поставлю 3 отдельных плагина для разных систем контроля версий для того чтобы максимально использовать возможности каждой.
(к примеру команда pull в Git и Hg делает разные вещи).Ага. Поэтому AuPull делает «hg pull --update», «svn update», «bzr pull» и до сих пор проваливается на некоторых реальных репозиториях git, так как я не знаю, как это правильно починить — ещё один пункт, из‐за которого я не люблю git.
Впрочем, pull/push (в основном только pull) — это единственные команды, которые доставляют мне проблемы при таком подходе, и то проблемы только с git — здесь он слишком не похож на остальных. log, commit, status, record, diff, annotate, hyperlink (:Gbrowse!), junk (remove/forget), track (add), name (tag/bookmark/branch), update, vimdiff, file (cat-file) проблем не доставляют абсолютно, а разница между VCS обычно не слишком значительна. Ещё есть grep, который имеет разное значение у mercurial и у всех остальных, но он не доставляет проблем, а только делает :AuGrep несколько несогласованной.
Всё это не идёт ни в какое сравнение с AuRecord.
Не плохой. Будь у git ещё, к примеру, нормальный UI, а не просто внутренности наружу — этот аргумент можно было бы даже воспринимать всерьёз.
Ммм… Отличный плагин для Идеи и ГитХаб — что ещё нужно?)
А так же есть SmartGit, и многие ide могут делать все операции прямо из себя.
Зато под OSX — вагон.
Посмотрите на Git Tower (http://www.git-tower.com/) — он прекрасен
Но если сложно — то есть GitBox (http://gitboxapp.com/) — он простой как почтовый клиент
Не хочется платить? Есть бесплатный SourceTree (http://www.sourcetreeapp.com/) — который выглядит похуже, но возможностей имеет больше всех
И это еще не считая всяких опенсорсных GitX, GitY — простенькие и со вкусом.
Лучшее что удалось найти под Windows — Git Extensions и SmartGit — мягко говоря странны и неудобны.
Если точнее — у git нет нормального UI под Windows или LinuxЯ готов согласиться с тем, что в сыром виде Git for Windows несколько страшен среднему пользователю Windows.
Однако вообще-то под Windows есть TortoiseGit.
А это ужé совсем другое дело: настолько приятный UI для Git, что другого и не надо.
Может сейчас уже и возможно, полгода назад приходилось расчехлять консоль
Еще раз и медленно — вы думаете что это приятный UI потому что просто не видели нормального UI для Git. Но по какой-то странной причине удобные и продуманные интерфейсы для GIT есть только для OSX
Удобность и продуманность — субъективные метрики. Мне tortoisegit кажется достаточно удобным и достаточно продуманным, потому как он позволяет мне выполнять то, что мне нужно без каких бы то ни было затруднений :-)
А затем я попробовал Git Tower на маке. Ощущения — как будто сел в новенькую иномарку с автоматом и просто получаю удовольствие. Кликов — меньше, наглядности — больше, автоматизации — тоже.
А опенсорс это опенсорс.
Но почему-то они делают ее только для OSX
Шок!
Посмотрите как ветки переключаются в Git Extensions, SmartGit
У TourtoiseHG — какие-то списки или меню.
В SourceTree/Git Tower — все ветки видны в левой панели, переключиться дело одного клика.
— gitorious
— gitlab
— gitblit
Плюс тьма приложений для веток, которые локальные.
Или что вы имели в виду?
Зачем мне как пользователю использовать что то, что пытается угнаться за гитом и его функциональностью?
Гит вполне себе проверен на огромных проектах (linux, android и тд) и по нему легко можно найти ответы.
В гите большинство фич были заложены изначально, кому как не Линусу знать что может потребоваться и как будет лучше.
В итоге другие DVCS, выступают в роли догоняющих.
This feature is experimental! Do not try it unless you are an experienced Mercurial user.
nice
p.s. как по мне, любая переделка истории — зло. (реверт тут не рассматриваем)
Все что попало в паблик, уже меняться не должно.
В Mercurial уже появились все необходимые средства для изменения локальной истории. Теперь появляется возможность спрятать изменения с помощью changeset obsolescence. Но удалить их по‐прежнему нельзя.
ps: лично мне ни разу такого не нужно было и я не совсем уверен, что это именно «киллерфича», просто это единственное, что придумывается
Вот например мне надо залить пару комитов из какой то ветки:
git checkout master
git cherrypick commit1
git cherrypick commit2
git push
Вроде тоже не сильно сложно, или я что то упускаю в commit phases
Т.е. я не говорю, что сделать в гите это будет сложно, я говорю, что оно защитит вас от ненарочного пуша.
Уйдет только то что вы сами лично добавили, только подготовленные комиты.
Фичабранч легко может жить в удалённом репозитории и быть апстримом для локальной ветки.
Для случаев, когда вы из локальной ветки не хотите что-то случайно запушить — есть phase secret.
Я понимаю как то так:
локальная — это ветка без апстрима, этой ветки больше нет ни у кого кроме вас
удаленная — это либо tracking branch либо remote, не важно, важно что все что вы пушите уходит на сервер.
В таком виде проще общаться, если вы знаете более удобные названия, я буду не против выслушать.
Так вот, для каждой фичи всегда создается отдельная локальная ветка, в которой вы работаете и подготавливаете комит, затем мержите уже в ветку из которой будет происходить пуш. Таким образом, что либо не так запушить становится ну очень проблематично.
Зачем? В чём смысл держать 2 фичабренча (общий и локальный)?
А если вы работаете не один, то тут уже все тоже самое что с любой другой веткой. Нужна временная ветка для работы. Хотя бы для того что бы держать историю «чистой».
Принцип один и тот же для всех удаленных веток, так что тут ничего нового.
Просто надо привыкнуть делать правильно, потом руки будут сами тянуться к git checkout -b… ;)
p.s. Интересно, как вы решаете проблему с автомержем при pull?
Как мне кажется, фичи должны быть атомарными — так чтобы каждый человек мог сделать кусок.
На крайняк можно сделать так
master — feature_1 — feature_1_subtask_1 — feature_1 — master \ feature_1_subtask_2 /
Практика (несколько тысяч бренчей и куча девелоперов) показывает, что подход работает (хотя я о своём опыте в данном тредике вообще не говорил, я лишь попытался придумать практическое применение mercurial phases, о чём и сказал в самом начале)
мне сложно представить зачем столько вообще может понадобится(особенности mercurial?). В том же ядре линукса одна ветка и куча тегов. Но теги то понятно почему куча, это просто указатели.
репозиторий на гите
> Но теги то понятно почему куча, это просто указатели.
Бренчи в гите это точно такие же указатели. Их единственное различие, что они с HEAD двигаются вместе.
Зачем вам 1000 веток с историей, вот в чем вопрос?
Они не мешают, потому особенно никого это не волнует.
> а ветки — это именно ветки с историей.
Ммммм, не хочется спорить, но я не согласен. В гите бренч это лишь указатель на конкретный ченджсет.
А если вспомнить, что ринадлежность ченджсета тому или иному бренчу в гите происходит в рантайме, то удаление бренча это скорее зло, чем добро. Потому что после удаления бренча невозможно сказать, в каком бренче это изменение было добавлено (если только не оставлять это же имя в комментариях специально для этого)
выглядит это именно так :)
> В гите бренч это лишь указатель на конкретный ченджсет.
который держит целую цепь комитов, и чем более ветвистое это дерево тем сложнее с ним работать. Тег тоже может держать цепь комитов, если скажем ветку удалить, но добавить новый вы не сможете пока заново не создадите ветку. То есть да, это все указатели, только свойства у них разные.
> Потому что после удаления бренча невозможно сказать, в каком бренче это изменение было добавлено
Ни разу не сталкивался с этим, можете пояснить зачем может понадобится знать откуда пришел комит? Ну например, о, этот комит пришел из ветка_супер_фича, что дальше?
Так или иначе, я здесь не для того, чтобы вас переубедить. Для вас работает один способ, для меня другой. Не убедил — окей.
1. а сколько информации можно вместить в имя ветки, о, или вы еще документ сохраняете с комитом?
2. на этот случай обычно указывается номер тикета и краткое описание. По номеру тикета легко находится полное описание.
> Так или иначе, я здесь не для того, чтобы вас переубедить
я с вами согласен, я тоже не для того что бы переубеждать вас, но когда вы говорите что для нормальной работы на большом проекте нужно 1000 веток я просто ну ни как не могу согласится, к тому же я не видел ни одного опен сорс проекта с таким количеством веток. Тот же андроид и линукс как то же живут и проблем не знают, и там разработчиков, я думаю, будет по более чем в вашем проекте.
Да, т.е. техническая проблема «получить название ветки» вы предлагаете решать организационно «давайте не будем забывать добавлять номер тикета». А чтобы по-настоящему не забывать — давайте добавим хуки, которые нам помогут это не забыть.
Итого — у вас 1 организационный инструмент и 1 технический, у меня — 1 технический, при том же результате.
> говорите что для нормальной работы на большом проекте нужно 1000 веток
Это исторические ветки, которые после решения задачи просто напросто не были удалены. Понимаете, проект живёт долго, потому фич было больше 1000. А бренчи удалены не были. И они никому не мешают, они где-то там вверху графа, и их никто даже не видит. Есть они не просят, для анализа графа и решения текущих задач не мешают. В чём проблема-то? :-)
Давайте еще в теле комита писать
— комит
— тест комит
— ку-ку
все равно в ветке лежит документ с описанием, так? :)
Я считаю это обязанность любого разработчика написать нормальное описание комита, включающее туда всю необходимую информацию, как минимум, к какому тикету принадлежит и что именно патч делает.
В этом случае отпадает необходимость в долго живущих фиче ветках и остальных костылях, в виде сохранения документа с описанием.
Удаление имени бренча «проблему» с ветвистым DAG никуда не убирает. Просто из этого дерева пропадают метки (бренчи) напротив некоторых ченджсетов, а дерево остаётся тем же самым, с которым «сложно работать» :-)
Как то вы не так работаете с ветками. Ну есть у нас 5-6 веток на все случаи жизни. Все остальное это временные ветки, которые по завершению ребэйзятся по верх одной из 5. Ни каких ветвлений и срача в истории.
У вас свой опыт, у меня свой. У меня он работает. Прекращайте считать свой опыт единственно верным.
>> Ни каких ветвлений и срача в истории
Удаление веток вообще никак со «срачем» (спасибо за характеристику репозитория, который вы даже и не видели) и ветвлением не связано.
Объём ветвлений зависит ТОЛЬКО от числа разрабатываемых фич. Вне зависимости от подхода граф будет ветвиться только по числу фич, и ваше решение даст ту же самую картинку, что и моё. Разве что вы удалите потом названия бренчей из графа, а я нет.
Вы с этим хоть согласны?
Судя по вашему же описанию, у вас создается одновременно огромное количество веток для каждой фичи, мало того эти все ветки потом еще и живут. Вот после такого дерево очень красивое, ветвистое получается — это и называется срач, его нужно прибирать через rebase и удаление старых веток.
Прошло полдня, но так и не понял, почему удаление старых веток что-то должно менять. Дерево то же, визуально выглядит так же, нет только меток.
> Дерево то же, визуально выглядит так же, нет только меток.
Либо у вас не так много людей одновременно работает, либо ветвистость у вас не считается какой то проблемой. Тут два программиста работают и ветвистость есть, а когда их скажем 300, и вы говорите что проблемы нету, тем более что вы ветки мержите а не rebase делаете? :)
Вот оно наконец то. Ветвистость легко обходится при желании, когда его нету можно и 1000 веток оставить.
Мердж вместо ребейза — более удобный (субъективно, для меня и проекта) способ управления проектом и организацией репозитория.
Я надеюсь вам никогда не придется накатывать комиты на копию проекта один за одним.
Каждый разработчик работает со своей веткой исключительно.
То, что где-то когда-то были созданы бренчи никому не мешает (и я не могу представить, как оно в принципе может как-то кому-то мешать).
Складывается ощущение что в виду не правильной работы с ветками, приходится использовать защитные костыли.
Бегло погуглил, найти эту ссылку не смог, сорри, но история была.
Phases не запрещают стрелять себе в ногу. Они только усложняют нажатие на курок.
но что то я не вижу кучи проектов, макс для контроля версий используют: git, svn или mercurial (коммерческие рассматривать нет смысла).
Согласно википедии: en.wikipedia.org/wiki/Mercurial
Mackall decided to write a distributed version control system as a replacement for use with the Linux kernel. This project started a few days after another project called Git, initiated by Linus Torvalds with similar aims.
В двух словах: Линус не найдя ничего подходящего, начал писать сам. Несколько дней позже аналогичный проект затеял Mackall.
Ну серьёзно, за пару дней ещё не было ничего даже близко рабочего и отражающего суть будущего проекта. Не говоря уже о том, что они могли не знать о намерениях друг друга, или знать не всё.
На самом деле ничего не подошло и меркуриала еще не было. Линусу нужно было сидеть и ждать с моря погоды, пока кто то догадается написать нужную для него dvcs?
Вот он начал писать сам, откуда он знает что какой то Mackall начал писать чуть позже тоже, к тому же свою dvcs он может контролировать как угодно и ни под кого не подстраиваться.
В общем все как написал выше, не было ничего подходящего и он начал писать сам, в чем я не прав?
Это было насчёт вашего
> Ну не совсем так.
В мире ПО, в особенности такого сложного, два дня это таки «одновременно»
Вы правы, что не было и что он сам начал писать. Более того, вы правы буквально насчёт «не одновременно», но фактически — одновременно :)
Да вы правы. Но если у Линуса ничего нету и у Mackall ничего нету, почему Линус должен выбрать версию Mackall, которой нету? Конечно он будет писать свою :)
Как говорил Фредерик Брукс в своей бессмертной книге: «No silver bullet ©»
А чем hg bookmark не замена git branch — там еще не сделали управление правами?
А чем hg bookmark не замена git branch — там еще не сделали управление правами?
Где? Насколько я понимаю, это вопрос к реализации сервера. И ни у git, ни у mercurial в стандартной поставке хорошего сервера нет, максимум что‐то для быстрого расшаривания в доверенной сети.
А относительно практически любых технических преимуществ git я напомню, что в mercurial вы можете взять и написать расширение. Что закладки, что фазы, что изменение истории, что поддержка больших файлов — всё это изначально жило (а иногда и сейчас живёт) в виде расширений. А в git ничего заранее непредусмотренного нельзя добавить — я как‐то не припомню, чтобы к коммиту в git хоть кто‐то добавил хоть какие‐то метаданные, которые хотя бы не мозолили глаза пользователю, не говоря уже о том, чтобы не участвовали в создании хэша. Для тех же фаз это обязательное требование.
А еще? (Я не ради подколки спрашиваю, мне действительно интересно, может, я чего-то не учел и в других workflow что-то вылазит.)
«теги-рефы» — что это и зачем нужно?
Staging area для работы нужно всего две возможности: фиксация состояния не с файловой системы¹ и перехват команды фиксации изменений. Если бы кому‐то staging area была действительно нужна в mercurial, такое дополнение давно бы сделали.
Теги, создающие коммит — это однозначно сознательный выбор разработчиков. Добавить теги, не создающие коммит, было бы сложнее, чем добавить закладки — они отличаются только тем, что hg commit
двигает закладку, но не двигал бы тег (и в git отличия на том по сути и заканчиваются, формат хранения у них одинаковый (если не трогать annotated теги)). Тем не менее, закладки есть, а тегов хотя бы на их основе (думаю легко было бы сделать так, чтобы, к примеру, переход на закладку tag-{name}
не активировал бы её) — нет.
Странно, что никто не вспомнил частичные (без истории и/или без каких‐то файлов) клоны — их вроде сами разработчики mercurial хотят (когда‐нибудь) добавить, но пока не сделали.
¹ С точки зрения пользователя — последний раз, когда я смотрел код какого‐то hg *record
он просто переписывал файлы на диске, фиксировал изменения и переписывал их обратно. На этой основе я делал свой AuRecord
(часть дополнения aurum для Vim).
У него достаточно приятный интерфейс, довольно удобная система обработки merge request, CI. Встроенным трекером не пользуемся, так как есть Jira.
VCS — это лишь базовый функционал, а для удобства команды требуются более высокоуровневые вещи.
не, вообще, в идеале VCS должна, конечно, давать пользователю записывать такую информацию. но не обязательно сразу, должно быть можно создавать такие хинты позже (без изменения хешей ревизий/коммитов). а не так, что один раз забыл / неправильно записал — и уже все.
а так как сейчас оно реализовано в Mercurial — то, по-моему, лучше б его уже вообще не было (как git'е) — а потом бы допилили отдельно хранимые (но push'аемые между репозиториями) хинты (что стало чем в какой ревизии/коммите).
«неправильно как записать?» Та стандартно. Все, что делается вручную, может быть сделано с ошибкой. Классика — это когда сначала все делается без регистрации в hg, а потом наскоро (если вообще делается) делается
hg rm/cp -A
(и указать не тот файл или забыть указать — немудрено). А уж про неидеальность hg addremove --similarity XX
я вообще молчу.Он не пытается сохранять эту информацию вообще. Лучше уж так, чем пытаться сохранять ее неправильно (вынуждая юзера захардкоживать ее прямо в коммит). Возможно, позже добавят лайт-способ сохранять эту информацию (в смысле — не в коммитах) и тогда пусть сохраняет, а пока лучше уж так.
Хотя в целом в git'е на данный момент я вижу скорее минусы, чем плюсы. Множественный мердж и отсутствие (некорректно реализованного) сохранения информации про копирование/переименование — пока единственные плюсы, которые я вижу.
Все основное стараются запилить на Python и только то что действительно имеет смысл оптимизировать пишут на си. Более того расширения к «ртути» пишутся на Python и если чего из мануала непонятна на Pythonе прочитаешь. Ведь сейчас многие современные девелоперы или Ruby или Python «как орешки щелкают», т.е. легко код читают\пишут на этих языках.
Да, и как описал Джоэл Спольски(на хабре есть перевод на русский из 6 статей) наименование команд в SVN почти один в один в Mercurial. Примеры: hg rename, hg add, hg remove, etc. А в виду популярности этой SVN переход на Mercurial за счет знакомых имен команд как-то проще осуществляется.
Приведу пример на Mercurial:
Я хочу попробовать запилить фичу. Для этого делаю новый бранч, девелопю, комичу и вдруг на каком-то этапе я вдруг прихожу к выводу «да это же гуанкод, это нельзя никому показывать». Что я делаю? Я просто удаляю папку!!! Все. Никто никогда и не узнает, что я написал какой-то бред. А в SVN если вы уже создали бранч, то он там будет на вечно!
А в случае с дизайнером такого нельзя допускать! Потому что одному дизайнеру может показаться «бредом», а другой дизайнер в этом «бреде» может увидеть что-то что приведет к красивому решению. Поэтому все дизайнерские наработки, какими бредовыми они не были должны быть собственностью компании.
Первый аргумент мне совершенно непонятен — в чём преимущество octopus merge перед двумя merge? Только количеством ревизий?
А вот второй аргумент меня зачастую весьма достаёт.
«Ветки» Git'a, это, скорее, heads — соответствуют heads в Mercurial. Одна ветка в Mercurial может иметь несколько голов, хотя обычно этим не злоупотребляют.
Там еще много интересных отличий. Например, изменение тэгов в Mercurial входит в коммит и отслеживается в дереве истории, тогда как в Git'е для сохранения информации о дате и авторе ярлыка надо сделать tag c описанием (annotated и/или signed), но в граф истории создание/изменение тэга не включается.
Ветки в Hg предназначены и используются для тех же целей, что и в Git'e, причем Hg-коммит привязан к конкретной ветке. Видимо, это часть того, что автор статьи назвал строгой работой с историей.
Закладки Hg более легковесны чем ветки, при этом активные закладки ведут себя как heads в Git'е. Так что — Вы правы — их удобно использовать с той же целью.
Например, для целей ведения коммерческого программного проекта мне больше импонирует Mercurial.
Строгая работа с историей в Mercurial гарантирует возможность учёта и поиска первоначального источника ошибки.
Три раза «ха»!
И чтобы, не быть голословным я просто приложу картинку, на ней изображен маленький кусочек дерева одного проекта в Mercurial, по понятным причинам без лишних подробностей.
И каждый, кто скажет, что по такой полной истории удобно ходить и что-то там искать, пусть кинет мне в карму.
![](https://habrastorage.org/storage2/0c6/889/1db/0c68891db43194240a35b42246d145f0.png)
Про которую я слышу каждый раз когда кто-то хвалит Меркуриал.
Насколько я знаю букмарки локальны и не идут в дерево.
Т.е. все преимущества мимо.
Вам не кажется смешным, что сначала придумываются букмарки, которые как бранчи, только локальные, чтобы не срать в историю, а потом букмаркам делается возможность срать в историю, в результате мы получаем бранчи, которые срут в историю, и букмарки которые срут в историю. Что-то мне теперь не понятно, а где разница то?
закладки же фактически создают ветвление в пределах одного бренча. Будет ли меркуриал ругаться о новых головах в этом случае? По идее должен.
Как эту проблему пользующиеся букмарками решают?
Потому что оно и есть дестркутивное. Вместе с безобидными букмарками вы можете на центральный репозиторий отправить что-то ещё, сами того не подозревая об этом.
Примера назвать не смогу, но вы не можете быть уверены, что ваши изменения не сломают что-нибудь, просто потому что вы уже сняли предохранитель и не узнаете о возможных проблемах.
Бывает, перед push переписываю локальную историю: часть коммитов объединяю/разъединяю, меняю местами, обновляю комментарии. Опять же, могу всё выделить в ветку и запушить в общедоступное место. Из того, что я понял про MQ, это возможность относительно удобной перегруппировки изменений. В git для этого традиционно используется переписывание истории (interactive rebase). Разве что в hg MQ — это именованная сущность со своим набором команд, а в git всё те же ветки + продвинутый rebase.
В git можно свернуть горы научившись работать с ветками: джентельменский набор — commit / push / pull / rebase / interactive rebase, понять что такое коммит и ветка. С помощью этого можно сделать очень много. Пока этого мне хватало для эффективной работы над несколькими релизами одновременно с разнородными активностями (коротокоживущие / долгие фичи / хотфиксы / перенос функциональности из релиза в релиз).
Что касается mercurial, нужно научиться commit / push / pull / rebase / mq / histedit чтобы научиться делать сравнимые вещи (хотя возможно даже более мощные, этого я не знаю). То есть нужно освоить в дополнение ещё несколько понятий, выучить несколько комманд.
В общем любую современную систему контроля версий на базовом уровне освоить легко, большинству больше этого и не нужно, а в умелых руках, что git, что mercurial способны творить чудеса.
* Во‐первых, понятные имена ключей. Во‐вторых, указывается, что перемещать, а не последнее из перемещающихся изменений. Для тех, кому проще git’овское поведение у mercurial есть «--base». У git же нет «--source».
![image](https://habrastorage.org/getpro/habr/comment_images/be1/973/acd/be1973acd81d74ea8deb23d3c4c03d6c.png)
На гите все что выше будет:
git commit -m «foo»
git checkout -b branch2 HEAD^
git commit -m «bar»
nvie.com/posts/a-successful-git-branching-model/
www.infoq.com/articles/agile-version-control
Сами методики не навязывают никакую из конкретных систем контроля версий, а лишь описывают способы организации процесса.
Или показывать начальнику, смотрите как все у нас серьезно, работа кипит :)
А так же можно попробовать рисовать картинки…
Комментарий Линуса на эту тему:
…
I still think you can go a bit too far on your branch usage (ie Jeff), but
hey, what's the difference between three branches and fifty, really?
(I'm kidding. The difference between three and fifty is how well you can
keep track of them in your head, but maybe Jeff just has a bigger head
than most people do. Jeff, do people go «Boy, you've got a big head» the
first time they meet you?)
Linus
lkml.org/lkml/2005/6/24/187
[alias]
g = log --graph --rev '..(head()-closed())'
Имена веток публикуются среди всех участников, поэтому в качестве имен обычно используют устойчивые во времени номера версий.
Если в проекте одновременно поддерживается столько версий, то мне искренне жаль его менеджера.
Если хочется порядка в «большом» хранилище, то локальную историю можно сжимать, прежде чем пересылать на сборку. Но если вы перешлете на сборку гига-патч, то в результате бисекции вы получите «ищите иголку где-то в этом стоге».
blog.deliciousrobots.com/2011/3/27/no-git-really-is-much-better-than-mercurial/
Если нужно изменить самую последнюю фиксацию, например, добавить что-нибудь забытое или изменить комментарий...
hg rollback
… добавить забытое
hg commit с новым комментарием
зачем в этом случае queue и импорт?
Вот смотрите, у push есть ключ --new-branch,
у commit есть ключ --close-branch
так какого черта у rebase ключ --keepbranches???
Где дефис?
MQ behaves very much like a souped-up version of git‘s index.
Попользовавшись субмодулями в Гите, понял, что они — говно. Привязка из репозитоия — только к конкретной ревизии. Спулил у кого-нибудь во внешний репозиторий, не спулив субмодуль — сослалось на дырку от бублика. Были свои пуши в субмодуле — они улетели в тартарары. Сослаться на «последнюю версию в ветке» — нельзя. И так далее. Для пущей радости гитовый плагин для VS ни черта не поддерживает субмодули, в результате привычное управление проектом исключительно из VS невозможно. Шаг в сторону — TortoiseGit тоже становится бесполезным. Уж молчу про его совершенно невменяемый интерфейс, который без полбутылки не понять.
Как ссылки на другие репозитории реализованы в Меркуриале? Они сравнимы по функционалу с SVN externals, или такое же кривое убожество, как Git submodules?
Сейчас Git'ом пользоваться модно, и его выбрал как раз исходя из этого. Если куча опенсорсников сидит на гитхабе, то имеет смысл не идти против моды. Но такие вот «нюансы» печалят. Ну и, как сказано в топике, невозможность полноценного отслеживания веток исключительно по репозиторию несколько огорчает. Хотя это не так критично, как субмодули.
Поддерживается чекаут из hg, git и subversion.
Офигительно. Уже хочу. Не подскажете, с меркуриалом проблемы со ссылками, как в гите? Ну, скажем, один разраб пушнул локально коммиты в основной репозиторий и вложенный, а другой аналогично пушнул, а потом пульнул основной репозиторий с первого разраба — что увидит второй? :)
Ну и отлично.
Решает одну проблему (негарантированное воспроизведение репозитория), добавляет другую (головная боль при регулярных коммитах в основной и вложенный репозитории). Я скорее готов мириться в первым, потому что сталкиваться приходится чаще со вторым.
Не понял что значит спулил во внешний репозиторий. Если вы про рекурсивный апдейт сабмодулей — то там всё хорошо.
Если у вас были свои пуши в сабмодуле — никуда они не улетят, только если вы специально им это скоммандуете.
Пользуйтесь git bash — всё работает как надо.
Привязка репозитория к конкретной ревизии — это благо. Вы не обнаружите случайно свой код сломанным изменениями в каком-то удаленном репозитории.
А также не обнаружу, что некий корпоративный «фреймворк» уже трижды обновился, и я использую устаревшую версию, то есть в релиз мой «стабильно неломающийся» код пойти не может. Если реально нужна конкретная ревизия (например, фиксируется релизнутая версия), то в SVN ревизию указать можно.
Не понял что значит спулил во внешний репозиторий. Если вы про рекурсивный апдейт сабмодулей — то там всё хорошо.
Конкретный пример: первый разраб закоммитил в субмодуль, потом в содержащий его основной репозиторий (включая обновлённую ссылку на субмодуль); второй разраб аналогично закоммитил в основной репозиторий и субмодуль свои изменения, а потом пульнул изменения из основного репозитория с первого разраба — что увидит второй разраб?
У меня есть сомнения, ибо не далее чем сегодня на безобидную команду словил вот это:
git diff
0 [main] us 0 init_cheap: VirtualAlloc pointer is null, Win32
error 487
AllocationBase 0x0, BaseAddress 0x68560000, RegionSize 0x260000, State 0x10000
C:\Program Files (x86)\Git\bin\less.exe: *** Couldn't reserve space
for cygwin's heap, Win32 error 0
Git SVN very slow comparative to the Linux version — Closed, Status: WontFix.
Git под Windows вообще похоже развивают по остаточному принципу. Точнее даже не развивают, а так, пытаются сделать вид, что под Windows им тоже можно пользоваться.
/e/src/Osmand (master)$ git status # On branch master # Your branch is behind 'origin/master' by 103 commits, and can be fast-forwarded. # (use "git pull" to update your local branch) # # Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: .gitignore # modified: OsmAnd/.settings/org.eclipse.jdt.core.prefs # modified: OsmAnd/assets/bundled_assets.xml # modified: OsmAnd/jni/Android.mk # modified: OsmAnd/jni/Application.mk # modified: OsmAnd/jni/cpufeatures_proxy/Android.mk # modified: OsmAnd/jni/cpufeatures_proxy/cpuCheck.cpp # modified: OsmAnd/proguard-project.txt # modified: OsmAnd/scripts/generate.sh # no changes added to commit (use "git add" and/or "git commit -a") /e/src/Osmand (master) $ git checkout -- OsmAnd/assets/bundled_assets.xml /e/src/Osmand (master) $ git status # On branch master # Your branch is behind 'origin/master' by 103 commits, and can be fast-forwarded. # (use "git pull" to update your local branch) # # Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: .gitignore # modified: OsmAnd/.settings/org.eclipse.jdt.core.prefs # modified: OsmAnd/assets/bundled_assets.xml # modified: OsmAnd/jni/Android.mk # modified: OsmAnd/jni/Application.mk # modified: OsmAnd/jni/cpufeatures_proxy/Android.mk # modified: OsmAnd/jni/cpufeatures_proxy/cpuCheck.cpp # modified: OsmAnd/proguard-project.txt # modified: OsmAnd/scripts/generate.sh # no changes added to commit (use "git add" and/or "git commit -a") /e/src/Osmand (master)$ git reset --hard HEAD is now at 362fd88 Translated using Weblate. /e/src/Osmand (master)$ git status # On branch master # Your branch is behind 'origin/master' by 103 commits, and can be fast-forwarded. # (use "git pull" to update your local branch) # # Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: .gitignore # modified: OsmAnd/.settings/org.eclipse.jdt.core.prefs # modified: OsmAnd/assets/bundled_assets.xml # modified: OsmAnd/jni/Android.mk # modified: OsmAnd/jni/Application.mk # modified: OsmAnd/jni/cpufeatures_proxy/Android.mk # modified: OsmAnd/jni/cpufeatures_proxy/cpuCheck.cpp # modified: OsmAnd/proguard-project.txt # modified: OsmAnd/scripts/generate.sh # no changes added to commit (use "git add" and/or "git commit -a") /e/src/Osmand (master)$
Решается это установкой core.filemode в false. Но об этом надо знать. А когда этого не знаешь, а пытаешься просто делать то, что тебе говорит гит, такое поведение мягко говоря вводит в ступор.
core.fileMode… useful on broken filesystems like FAT
Кстати, у вас msysgit или cygwin git?
— Производительность. git намного быстрее!
— Авторизация. Я использую Mercurial keyrings, этот способ, на мой взгляд, самый лучший среди возможных для Mercurial, но, тем не менее, он создает гораздо больше проблем, чем SSH-авторизация git.
Еще менее важное и наиболее субъективное отличие — интерфейс. По моему мнению, на котором я, повторюсь, не настаиваю, git более интуитивен и прост в использовании.
А некоммерческий проект? А непрограммный проект, но из текстовых файлов?
> После слияния с веткой в Git мы рискуем получить гига-патч, в котором где-то будет скрываться ошибка
это вообще о чём? о мердже со squash? Так это не единственный метод, читаем хабр
Очень странные выводы.
На самом деле ответ есть, он очень простой.
Вот, например, есть github, где лежит несколько миллиардов строк разного кода в открытом доступе для всех, иногда весьма неплохого. А hghub как-то не наблюдается. Ну и какая разница, что вам кажется лучше, а что хуже. Дома можно хоть на голове ходить. На работе уже выбирать особо не приходится!
Сходство и различие между Mercurial и Git