Комментарии 425
Так что же всё-таки лучше? :)
НЛО прилетело и опубликовало эту надпись здесь
А чего не CVS?
НЛО прилетело и опубликовало эту надпись здесь
accurev наше всё Ж)
Если бинарные файлы хранить, то про SVN согласен, а если текстовые, то нет. Для текстовых все же Hg, Git лучше )
А зачем бинарные в СВН хранить?
К примеру MP3, они редко меняются и не компилируются. При таких ситуациях можно поступить двумя способами:
1) Положить файл на какую-либо шару, а в каком-либо сборочном скрипте указать где его брать
2) Положить непосредственно в CVS
Второй способ лучше:
1) Знаете какой из «умных людей» удалил столь нужный файл!
2) Нет такой ситуации, когда Вы не знаете при решении какой задачи потребовался этот файл?
3) Админам, как правило проще бэкапить
Банально: about.png это текстовой файл? ;)
1) Положить файл на какую-либо шару, а в каком-либо сборочном скрипте указать где его брать
2) Положить непосредственно в CVS
Второй способ лучше:
1) Знаете какой из «умных людей» удалил столь нужный файл!
2) Нет такой ситуации, когда Вы не знаете при решении какой задачи потребовался этот файл?
3) Админам, как правило проще бэкапить
Банально: about.png это текстовой файл? ;)
Нет, вы не поняли. Зачем в Svn, а не в Git?
А вы работали с большими репозиториями git? :-) Гит не тянет больших репозиториев, зачастую просто падает или дико тормозит. Большие — это в несколько гигов на самом деле.
А кроме того, никто не умеет нормально мержить бинарники, да и возможность вытащить часть репозитория очень полезна бывает.
Так что код — в git (или hg), а данные -в svn!
А кроме того, никто не умеет нормально мержить бинарники, да и возможность вытащить часть репозитория очень полезна бывает.
Так что код — в git (или hg), а данные -в svn!
Потому-что GIT будет локально хранить весь репозиторий, что увеличивает необходимое пространство минимум вдвое.
Да ладна! Бинарники в SVN? Почитайте, SVN не следит за целостностью данных. Вы можете положить туда бинарник, а через год вытащить его оттуда битым. У меня на практике бились картинки и шрифты. Так что бинарные файлы так же лучше хранить в Git или Hg.
Пруф?
Конечно есть там чексуммы.
Конечно есть там чексуммы.
Не пользуюсь SVN уже года три-четыре. Чексуммы есть, однако он их не проверяет, когда выгружает файлы. О том что файл битый узнаешь позже. Да и стоит ли сравнивать надежность хранения данных у централизованной и децентрализованной системы?
Пруф что не проверяет?
Битый файл мог быть у вас потому что вы его туда отправили битым (битая память?). В противном случае можно было с нескольких попыток получить целый файл.
А поповоду надёжности — попробуйте забэкапить git репозиторий в файлы, инкрементальным бэкапом, все бранчи.
(в файлы — это в смысле — при условии что целевой бэкап будет где-нибудь на S3 храниться, и прав на удаление/изменение файлов не будет, только на добавление — ведь именно так нужно настраивать права чтобы какой-нибудь злоумышленник не стёр и бэкап при компрометации машины)
Битый файл мог быть у вас потому что вы его туда отправили битым (битая память?). В противном случае можно было с нескольких попыток получить целый файл.
А поповоду надёжности — попробуйте забэкапить git репозиторий в файлы, инкрементальным бэкапом, все бранчи.
(в файлы — это в смысле — при условии что целевой бэкап будет где-нибудь на S3 храниться, и прав на удаление/изменение файлов не будет, только на добавление — ведь именно так нужно настраивать права чтобы какой-нибудь злоумышленник не стёр и бэкап при компрометации машины)
Пруф что не проверяет?
Ну да, проект был задеплоен год назад с битыми файлами. Если бы это был единичный случай, то ладно. С гитом за 4 года таких проблем не было.
Любой клон гита — это уже бекап. Для того, чтобы забекапить на том же S3 достаточно синхронизировать все ветки. И если история не будет переписываться, то файлы будут только добавляться.
Ну это не показатель что файлы были битые, может баг в svn в вашей ОС/версии, может проблема с железом.
Любой клон гита — да тоже бэкап.
А вот бэкап копированием папки git — после git gc всё будет перезаписываться. К тому же чтобы он был в 100% случаев консистентным тоже нужно постараться вроде как.
Сделать такой бэкап с помощью git bundle — это нужно постараться. И писать это не на bash. И желательно с unit тестами. При этом метки бранчей-тэгов не будут «инкрементальными» (впрочем они не много места занимают)
Любой клон гита — да тоже бэкап.
А вот бэкап копированием папки git — после git gc всё будет перезаписываться. К тому же чтобы он был в 100% случаев консистентным тоже нужно постараться вроде как.
Сделать такой бэкап с помощью git bundle — это нужно постараться. И писать это не на bash. И желательно с unit тестами. При этом метки бранчей-тэгов не будут «инкрементальными» (впрочем они не много места занимают)
Гит крякает, если файл поврежден. У него механизм хранения данных такой. Он файлы внутри папки .git называет согласно их контрольной суммы.
Бренчи и теги практически ничего не весят, это метаданные. А инкрементальными бекап можно получить если, например, пушить на север бекапа по крону (или наоборот пулить с сервера бекапа). Причем без параметра --force он ничего не перезапишет. И еще советую почитать про параметр --mirror.
git bundle удобен для разового переноса. В принципе это создание данных для push перед отправкой на сервер.
Бренчи и теги практически ничего не весят, это метаданные. А инкрементальными бекап можно получить если, например, пушить на север бекапа по крону (или наоборот пулить с сервера бекапа). Причем без параметра --force он ничего не перезапишет. И еще советую почитать про параметр --mirror.
git bundle удобен для разового переноса. В принципе это создание данных для push перед отправкой на сервер.
Бекап на самом деле запросто реализуется — открываете архивируемый репозиторий наружу и делаете на другом конце git clone --mirror --bare — и потом только фетчите ветки.
В принципе я это и пытался объяснить :)
В условиях было — бэкап в файлы. На другом конце пассивная информация, в ней нельзя запустить гит.
Если есть способ примонтировать с помощью fuse, то как раз по теме. Выполняйте пуш.
Не совсем понял, видимо, что вы хотите бэкапить? Репозиторий с версиями? Тогда используйте описанный способ. Как вы хотите сохранять версионность, не запуская систему контроля версий-загадка для меня.
Если же вы хотите бекапить просто набор файлов некоторого снапшота: git archive --help
Если же вы хотите бекапить просто набор файлов некоторого снапшота: git archive --help
Point был в том что в SVN — svndump может делать инкрементальные бэкапы, который можно восстановть в полноценный репозиторий, причём место назначение бэкапов может быть что угодно — лента, флэшка, Amazon Glacier, медленный FTP, удалённый сервер (доступный по протоколам передачи файлов) без права стирания/перезаписи файлов.
Git bundle же может делать аналогичное только если 1 бранч. (если много бранчей то это очень сложно).
p.s.
про другие способы бэкапов git'а я знаю, спасибо.
Git bundle же может делать аналогичное только если 1 бранч. (если много бранчей то это очень сложно).
p.s.
про другие способы бэкапов git'а я знаю, спасибо.
Git bundle же может делать аналогичное только если 1 бранч. (если много бранчей то это очень сложно).
Поищите в справке параметр --all и сложность отпадет.
Другие способы бекапа — pull/push в удаленный bare репозиторий. Если на удаленном сервере не стоит git, то папку с репозиториями можно монтировать в файловую систему с помощью fuse и запускать нужную операцию гита на локальном сервере.
--all не сделает инкрементальный бэкап
stackoverflow.com/questions/12129148/incremental-backups-with-git-bundle-for-all-branches
правильный ответ описан рядом с этой строчкой
stackoverflow.com/questions/12129148/incremental-backups-with-git-bundle-for-all-branches
правильный ответ описан рядом с этой строчкой
git bundle create newbackup.bundle ^backup/A ^backup/B A B C
Для примера, у меня есть реп, которые я таскаю на galaxy s3. Ничего сверхважного, скрипты, но храню я их там в гите. Хоть на андроид и есть клиенты и серверы гита, но я их не использую. Данные вынимаю и сохраняю с помощью стационарного гит клиента.
И, кстати, если при работе крона будет ошибка (не может выполнить push/pull), это будет означать, что коммиты переписывались. И либо это ошибка фс, либо кто-то намеренно их переписал. В любом случае факт модификации будет отловлен.
Про проверку целостности — где то читал, где уже не помню. Про битые файлы — реальный факт, проблема была с очень большим репозиторием (4 гигобайта). И в сети тоже это обсуждалось. Быстрый поиск в гугле результатов не дал.
Спасибо, не знал! ;) А еще можете посоветовать нормальный не монстроподобный issue-трекер из тех что пробовали(если пробовали) и который понравился?
А issue-трекер у bitbucket пробовали?) Он даже слишком простой.
Извините что не уточнил нюанс. Мне нужно на локальной папки, т.к. проект веду без использования внешнего интернет-сервиса. Обхожусь только локальной папкой ".hg" расположенной в TrueCrypt контейнере :) Устал использовать TaskCoach. Пока у меня все выглядит так: после удаления\дабавления\изменения задач я делаю hg ci -m «added new task». Это как-то уже напрягает (
Если под винду, посмотрите ToDoList.
Чем от будет отличаться от упомянутого мною TaskCoach? Ответ: Ничем!
Ну я же не знаю, что именно вас утомило в использовании TaskCoach. Вы бы описали, чем вас TaskCoach не устраивает и какие у вас требования к issue-трекеру вообще.
Ок. Опишу один use-case по добавлению задачи, как это сейчас выглядит у меня:
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 номер_задачи
Это пример того что я хочу.
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 номер_задачи
Это пример того что я хочу.
Может это подойдет.
BugsEverywhere попробуйте. Интересная штука.
redmine
Лично я в свое время выбрал для себя Git, так как он более распространен. Хотя на всякий пожарный и Mercurial освоил.
Ничего не лучше, кому что нравится то и используют.
Не хватало ещё и холивара по поводу Git VS Mercurial :D
Не хватало ещё и холивара по поводу Git VS Mercurial :D
Интересно, возможно ли в Mercurial переключать ветки в рамках одной рабочей копии репозитория?
Для проектов на C++, где время сборки может быть большим это иногда важно.
Для проектов на C++, где время сборки может быть большим это иногда важно.
Если я вас правильно понял, то можно просто создать новую директорию и в ней симлинк на ваш .git
Ну а дальше git checkout ваш_бранч, или использовать тот же самый бранч, это уже как нравится
Ну а дальше git checkout ваш_бранч, или использовать тот же самый бранч, это уже как нравится
С git как раз пониматно. Сделал git checkout, пофиксил/смёрджил/запушил, сделал назад checkout. Интересно, можно ли так в mercurial, или там обязательно клонировать в отдельный каталог.
Зачем такие сложности? Достаточно сделать клон из уже имеющейся папке. В файловых системах, где поддерживаются жесткие ссылки (ntfs, ext) — будут задействованы именно они, при дублировании папки .git. По окончанию работы — удалить клон.
Если мне нужно исправить пару файлов в большом проекте (и ветки близки, как в случае hotfix и new feature development), то клон в новое место приведёт к тому, что бинарники «протухнут», и придётся делать полную пересборку. Переключение в одной копии позволит сделать быструю инкрементальную досборку.
Можно сделать и клон, но на сколько я понял как раз не хотелось делать клон. Возможно я что то не так понял.
Тем не менее, при работе склоном нужно будет делать push в оригинал, и потом с оригинала на сервер, конечно мы так же можем поправить и конфиг, но тогда надо будет кидать комиты через сервер, что нам точно не нужно.
С симлинком, можно работать даже с одной версией и отправлять на сервер из любой папки. И Stage файлы будут видны в обоих, так же как и комиты, без лишних pull/push, но с checkout и ресет…
Тут уж очень сильно зависит от того что нужно делать. А там хоть клон, хоть симлинк, да хоть полная копия .git
Тем не менее, при работе склоном нужно будет делать push в оригинал, и потом с оригинала на сервер, конечно мы так же можем поправить и конфиг, но тогда надо будет кидать комиты через сервер, что нам точно не нужно.
С симлинком, можно работать даже с одной версией и отправлять на сервер из любой папки. И Stage файлы будут видны в обоих, так же как и комиты, без лишних pull/push, но с checkout и ресет…
Тут уж очень сильно зависит от того что нужно делать. А там хоть клон, хоть симлинк, да хоть полная копия .git
НЛО прилетело и опубликовало эту надпись здесь
hg update {revision} (он же hg up, hg checkout, hg co); где {revision} может быть в том числе и веткой.
А можете немного поподробнее объяснить, что вы имели в виду?
Думаю мне уже ответили. Имелось ввиду возможность параллельной работы над разными ветками в одной рабочей копии. Если две ветки не сильно разошлись, то переключение из одной в другую изменит только малое количество файлов (важно чтобы timestamps при этом не менялись), и инкрементальная сборка проекта останется быстрой.Похоже это можно сделать и в git, и в mercurial.
переключиться на другую
> 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 «это указание сообщения коммита»
> 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 написал лично Линус Торвальдс!
Не понимаю чем может не устраивать git. Единственное объяснение выбора в пользу другой CVS я вижу только в незнании git
А как в нем изменить сообщение (например, исправить очепятку в тексте) у древнего коммита, который был давным давно запушен? ;)
Это киллер-фича mercurial?
НЛО прилетело и опубликовало эту надпись здесь
rebase — не катит, так как все комиты буду заново пересозданы.
В случае же, если проект на столько критичен, что нужно волноваться об одной опечатке в описании, возможно есть смысл иметь модерацию комитов перед мержем в основную ветку. Это так же позволить повысить качество кода, и иметь комиты только по делу.
В случае же, если проект на столько критичен, что нужно волноваться об одной опечатке в описании, возможно есть смысл иметь модерацию комитов перед мержем в основную ветку. Это так же позволить повысить качество кода, и иметь комиты только по делу.
НЛО прилетело и опубликовало эту надпись здесь
То есть вы готовы запороть всю историю и иерархию комитов, ради одной опечатки?
НЛО прилетело и опубликовало эту надпись здесь
Описание изменения и его родители используются для вычисления хэша что в git, что в mercurial. Соответственно изменить сообщение, не «запоров» историю (точнее, не пересчитав хэши всех потомков) невозможно.
vovkab, а что, rebase действительно запорет всю историю и патриархию? Свят-свят.
> rebase — не катит, так как все комиты буду заново пересозданы.
Предположим что это не критично, как это сделать? Просто когда я искал способ это сделать, то единственным рабочим решением оказалось использовать git filter-branch, в котором проверять хеш коммита и заменять текст. Буду рад увидеть лучшее решение :)
Предположим что это не критично, как это сделать? Просто когда я искал способ это сделать, то единственным рабочим решением оказалось использовать git filter-branch, в котором проверять хеш коммита и заменять текст. Буду рад увидеть лучшее решение :)
Если это локальная ветка и данные еще не в паблике, то конечно же через rebase.
Вот тут подробнее: git-scm.com/book/ch6-4.html
Вот тут подробнее: git-scm.com/book/ch6-4.html
Создать ещё один коммит, это ж система контроля версий ёбанаврот!
НЛО прилетело и опубликовало эту надпись здесь
А в пользу Mercurial только один (и кстати вы не первый кто в этом признается): «Не осилил Git»
НЛО прилетело и опубликовало эту надпись здесь
Нет. У git нет API, позволяющего нормальную интеграцию с чем‐либо (делать каждый раз fork-exec и читать выхлоп из pipe — это очень медленно, как в смысле скорости разработки так и скорости исполнения. Даже несмотря на то, что интеграция пишется на языке, который успешно прячет fork-exec).
У 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 нет огромного количества хуков (например, 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».
Большую часть претензий можно игнорировать или терпеть. Но не первые две.
НЛО прилетело и опубликовало эту надпись здесь
Ещё и dulwich. Я знаю и использую libgit2. Но стабильного релиза ещё нет (правда, обещали, что следующий релиз — 1.* и со стабильным API, но сроки неизвестны), а binding’и к python (pygit2) не обладают всеми возможностями даже libgit2, сама libgit2 не обладает всеми возможностями git.
Кроме того, это независимый проект. Если человек использует git, то консольный клиент у него окажется почти наверняка, а вот libgit2 — нет. А вот с mercurial и bazaar не так — если он есть, то почти наверняка установлен «нормально», т.е. доступен для импорта в python. К subversion тоже зачастую прилагается C‐шная библиотека (официальная!). К git не прилагается ничего.
Кроме того, это независимый проект. Если человек использует git, то консольный клиент у него окажется почти наверняка, а вот libgit2 — нет. А вот с mercurial и bazaar не так — если он есть, то почти наверняка установлен «нормально», т.е. доступен для импорта в python. К subversion тоже зачастую прилагается C‐шная библиотека (официальная!). К git не прилагается ничего.
А еще есть JGit (дада, на Java).
У часто используемых команд вроде 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'у, например.
НЛО прилетело и опубликовало эту надпись здесь
Ага, я тоже после ртути поначалу плевался. А еще staging считал жутко неудобной никому не нужной хренью. :)
Но потом заметил, что перестал случайно добавлять всякую ерунду в коммиты, и плеваться закончил.
Но потом заметил, что перестал случайно добавлять всякую ерунду в коммиты, и плеваться закончил.
НЛО прилетело и опубликовало эту надпись здесь
Неудобно и ненужно. У меня просто vim открывает diff при фиксации изменений в соседнем окне и я делаю review. Никакая staging area никак не повлияет на возможность добавить скопом все изменения без review и тестирования, она только раздражает необходимостью писать на одну команду больше.
я может что-то не понимаю, но почему не использовать git commit -a
«git commit -a» не делает addremove. Но это не важно. «Неудобно» относится к тому, что возможность наличия чего‐то в staging area необходимо учитывать. Например, при добавлении нового файла в репозиторий с помощью «git add» «git diff» не покажет никаких изменений. Причина мне понятна, но необходимость помнить о ней неудобна.
Концепции staging в ядре меркуриал нет, но из коробки есть расширение mq, которое даёт вам staging и даже более крутой (многослойный)!
pqr7.wordpress.com/2011/01/07/a-git-users-guide-to-mercurial-queues/
pqr7.wordpress.com/2011/01/07/a-git-users-guide-to-mercurial-queues/
А теперь удалите ветку, не указав, откуда вы её хотите удалить. Я не про возможность не указать оба или последний из этих аргументов. Я про невозможность не указать только первый, указав второй.
А вот интересно, у hg есть API?
Или имеется в виду python-hglib, который запускает в фоне процесс hg и парсит его текстовый вывод?
Или имеется в виду python-hglib, который запускает в фоне процесс hg и парсит его текстовый вывод?
НЛО прилетело и опубликовало эту надпись здесь
API официально нет, но на самом деле оно есть. На нём пишутся расширения, и оно на самом деле достаточно стабильно, чтобы его использовать. Просто не забывайте следить за изменениями и прогонять тесты после релиза.
А cli для hg — точно так же плохо, как для git. Те, кому надо написать интеграцию с mercurial просто забивают на совет его не использовать.
А cli для hg — точно так же плохо, как для git. Те, кому надо написать интеграцию с mercurial просто забивают на совет его не использовать.
Правда, я начал писать эту интеграцию когда command server ещё не было. Если бы он уже был, решение было бы, возможно, иным.
API расширений — это одно, API для внешнего использования (из IDE например) — это другое.
Первое прекрасно служит в качестве второго. Замечу, что нужная мне часть почти не менялась с mercurial-1.3. Предположительно и с mercurial-1.2, но в Vim нет sys.stdout.closed, поэтому я всегда получаю AttributeError, когда пытаюсь использовать последний.
Никто не занимается сломом API «из любви к исскусству», поэтому просто не лезьте в дебри, следите за изменениями и получите нормальную поддержку всех версий, в том числе тех, когда Command Server не существовал. С бонусом в виде отсутствия затрат на IPC или даже жутких затрат на fork/exec.
На самом деле, расширения ломаются даже чаще — им нужны бо́льшие дебри.
Никто не занимается сломом API «из любви к исскусству», поэтому просто не лезьте в дебри, следите за изменениями и получите нормальную поддержку всех версий, в том числе тех, когда Command Server не существовал. С бонусом в виде отсутствия затрат на IPC или даже жутких затрат на fork/exec.
На самом деле, расширения ломаются даже чаще — им нужны бо́льшие дебри.
git checkout не создаёт ветки. git checkout -b — это всего лишь shortcut на несколько команд.
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 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 — он не поощраяет и не прощает работу по принципу «ну я ща начну работать, мне вот срочно надо, а потом как-нибудь выучу». Разберись, а потом пользуйся и радуйся. Кстати, с линуксами то же самое.
ПС. Фраза на проекте была: «я уже всё запушил, а потом закоммитал то, что нужно. Забирайте».
Никого не волнует, создаёт ли
Обычно у меня одно место куда я делаю push. И другое одно, откуда делаю pull.
А про линуксы мне говорить не надо. Я просто ничего не уча установил себе Ubuntu. Именно по этому принципу¹. Потом почти так же² пересел на Gentoo, в процессе правда читая handbook.
Кроме того, как я сказал, замечания не фатальные. За исключение API и hook’ов. А также справки для инопланетян и необходимости знания кишок. Подтянется libgit2, будет гораздо лучше, я и сейчас её начинаю использовать.
Проблемы из третьего предложения (справка и кишки) меня уже слабо волнуют. Но это причина, по которой я не буду советовать
¹ В Windows по совершенно непонятным причинам через несколько дней после установки начинал тормозить интернет. В Ubuntu он не тормозил. Вторая часть мотивации: linux — это не так как у всех, а потому круто (как несложно догадаться, решение принималось ещё в школе). Ни одного linux‐гуру вокруг не было, только такие же разговоры от других школьников, которые его где‐то видели. «Совершенно непонятные причины» также замечательно характеризуют уровень компьютерного знания.
² Только на этот раз было не «надо», а «интересно». И вторая часть ещё никуда не делась. Ну и проблемы от неопытности я себе тоже создал. Не такие большие, как были в Windows, и не причина перейти на что‐то радикально новое, но тоже не сахар.
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
НЛО прилетело и опубликовало эту надпись здесь
О теперь про UI, удивительно как похожи все аргументы приверженцев Hg :)
Git не нужен UI как таковой, потому что все делается достаточно просто, быстро, удобно и безопасно из консоли.
UI может требоваться в двух случаях merge/diff — для этого есть миллион утиит которые прекрасно подключаются к Git и Mercurial впрочем тоже.
И чтобы посмотреть/поискать по дереву, с этим отлично справляется gitk (хотя есть еще десяток проектов разнйо степени стрёмности)
Git не нужен UI как таковой, потому что все делается достаточно просто, быстро, удобно и безопасно из консоли.
UI может требоваться в двух случаях merge/diff — для этого есть миллион утиит которые прекрасно подключаются к Git и Mercurial впрочем тоже.
И чтобы посмотреть/поискать по дереву, с этим отлично справляется gitk (хотя есть еще десяток проектов разнйо степени стрёмности)
НЛО прилетело и опубликовало эту надпись здесь
С каких это пор «command-line interface» перестал быть «user interface»? Спрашивали же не «graphical user interface» (aka GUI). Хотя претензии мне здесь не совсем понятны: CLI, конечно, местами нелогичен, но не настолько, чтобы это было проблемой. Если бы была нормальная документация конечно.
А «внутренности наружу» — скорее всего имеются ввиду огромное число команд вроде «git unpack-file», предназначенных исключительно для использования их в скриптах.
А «внутренности наружу» — скорее всего имеются ввиду огромное число команд вроде «git unpack-file», предназначенных исключительно для использования их в скриптах.
Мы на работе уже сколько лет как работаем на гите и есть два человека в команде, которые терпеть не могут вид консоли, не хотят запоминать команды и вообще.
Удивительно, как похожи контр-аргументы гитфанов :).
Удивительно, как похожи контр-аргументы гитфанов :).
Пользователи windows? Я бы тоже не смог терпеть вид консоли.
Ага, лично я плохо понимаю, почему они не могут перейти на линупс как уже давно сделала вся остальная команда, но это их личное дело.
Ну и вот, собсна, проблема нормального GUI не решена. Ближе всего SmartGit, но он платный, а никто им покупать его не стремится. Бесплатных GUI, хотя бы близко приближающихся к Mac'овскому SourceTree походу в природе не существует. (Тут должна быть вставлена картинка «WHY?»)
Ну и вот, собсна, проблема нормального GUI не решена. Ближе всего SmartGit, но он платный, а никто им покупать его не стремится. Бесплатных GUI, хотя бы близко приближающихся к Mac'овскому SourceTree походу в природе не существует. (Тут должна быть вставлена картинка «WHY?»)
Раз уж пошло обсуждение гитовских GUI, а вы пользуетесь линуксом, то чем вы в нём пользуетесь?
Под маком есть прекрасный Tower (если денег не жалко) и чуть менее прекрасный SourceTree. А вот под линуксом меня от имеющихся интерфейсов аж передёргивает.
Под маком есть прекрасный Tower (если денег не жалко) и чуть менее прекрасный SourceTree. А вот под линуксом меня от имеющихся интерфейсов аж передёргивает.
Лично я на коммерческих проектах пользуюсь то gitg то rabbitvcs. Убоги оба, но как-то юзабельны. На бесплатных — SmartGit — он чуть лучше, но до SourceTree все равно не дотягивает. Ну и лично у меня нет проблем с консолью :).
Я, если честно, не представляю человека, который пользуется линуксом и обламывается работать с git через консоль :-)
Как бы там ни было, я тоже человек и хочу sourcetree под линукс.
Спору нет, смотреть дерево удобнее в красивом gui. Меня спасают две вещи:
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'
и отсутствие необходимость смотреть дерево. :-)
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'
и отсутствие необходимость смотреть дерево. :-)
Ну так в гуях много чего приятно делать — например выбирать файлы для коммита, ревертить случайно поменянные файлы… Не поймите меня неправильно — это умеют все клиенты. Но SourceTree пользоваться удобно, а другими — нет.
Фиговатый у вас пример-то :)
Одна длинная строка — и все отображение развалилось…
Одна длинная строка — и все отображение развалилось…
У меня эран широкий и хук на длину сообщения. Но вообще да, надо поправить как-нибудь.
А еще видите там вон такую горизонтальную псевдографическую полоску? Она вообще к чему? Это и без разрыва-то небось неочевидно… Ну и главное — такую сложную алхимию я бы не написал — а в гуях это сделано за меня…
А еще вот вообще трэш и угар:
Да, похоже вам мой конфиг не подойдет :)
Но мне как-то хватало, уж не знаю почему. Возможно из-за того, что у меня нет таких ветвлений. Или я не говорю --all. :-)
Но мне как-то хватало, уж не знаю почему. Возможно из-за того, что у меня нет таких ветвлений. Или я не говорю --all. :-)
Да тут на самом деле интересная штука — один из коллег любит делать пространные комментарии к коммитам, за что его уж совсем никак винить нельзя, кроме того так получалось, что на последнем рассмотренном куске не было еще фичебранчей — он тупо раз за разом коммитил все в одну ветку. Причем коммитил он чаще других — у него были десятки относительно небольших задач. Вот и получается — одна ветка только изкоммитов, все остальные — просто прямые (их не так уж много — мастер плюс еще какие-то побочные).
Но вот оказывается, что нельзя достаточно полно посмотреть на обычном экране дерево в хоть сколько-то сравнимой с гуи форме.
Вот как оно выглядит в gitg:
Куда делись остальные ветви? понятия не имею. Может их там и не было или где-то далеко вверхе и внизу у них стоят красивые цветные стрелочки, чтобы было понятно в каком столбце и чего ждать
насчет all — тупо скопировал команду из вашего альяса.
Но вот оказывается, что нельзя достаточно полно посмотреть на обычном экране дерево в хоть сколько-то сравнимой с гуи форме.
Вот как оно выглядит в gitg:
Куда делись остальные ветви? понятия не имею. Может их там и не было или где-то далеко вверхе и внизу у них стоят красивые цветные стрелочки, чтобы было понятно в каком столбце и чего ждать
насчет all — тупо скопировал команду из вашего альяса.
Я имел в виду, что либо у вас много длинных параллельных веток в локальном репозитории, либо вы добавили git tree --all. С ветками прояснилось, так что извините.
Я не спорю, что красивый gui полезен для просмотра и повседневной работы разработчика/менеджера, но для меня он не очень важен, а вот многие вещи, которые есть в командной строке (filter-branch например) я использую относительно часто. Так что так выходит, что мне GUI не нужен.
Я не спорю, что красивый gui полезен для просмотра и повседневной работы разработчика/менеджера, но для меня он не очень важен, а вот многие вещи, которые есть в командной строке (filter-branch например) я использую относительно часто. Так что так выходит, что мне GUI не нужен.
один из коллег любит делать пространные комментарии к коммитам, за что его уж совсем никак винить нельзяПосоветуйте своему коллеге в первой строке комментария писать очень коротко о чём этот коммит вообще, а пространный комментарий начинать со второй строки.
Напишите в atlassian. :-)
Ну, вот я такой, например. Собственно, под линуксом я и пользуюсь консолью (и немного gitg), но после работы с хорошим GUI обратно в консоль не хочется. Возможно, вы просто не пробовали.
Именно консольный UI у git ужасен.
Git не нужен UI как таковой, потому что все делается достаточно просто, быстро, удобно и безопасно из консоли.
Являсь сторонником git и достаточно ярым почитателем консоли (мержу, например, исключительно с использованием vim), отмечу, что следующие вещи делать без GUI жутко неудобно:
1. Рассматривать дерево истории
2. Брать в commit лишь часть локальных изменений файла
3. Просматривать аннотацию (кто, какие изменения и в каких версиях внес)
4. Смотреть дифф при большом количестве изменений или когда необходимо знать контекст изменения в широком смысле (то бишь полазить по файлу, чтобы понять, а что тут что)
> мержу, например, исключительно с использованием vim
капелька оффтопа: а вы можете на толковые гайды для совсем ничего не знающих о виме ссылки дать? Гуглом пользоваться умею, но хочется именно правильный материал — сам, ввиду отсутствия знаний, оценить адекватность не смогу.
капелька оффтопа: а вы можете на толковые гайды для совсем ничего не знающих о виме ссылки дать? Гуглом пользоваться умею, но хочется именно правильный материал — сам, ввиду отсутствия знаний, оценить адекватность не смогу.
С самим vim идет vimtutor, для начала — прекрасная вещь.
Это по сути запущенный 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, как некоторые.
Для меня это просто достаточно удобный текстовый редактор — не более.
Хотя код под линуксом я пишу исключительно в нем.
Это по сути запущенный 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, как некоторые.
Для меня это просто достаточно удобный текстовый редактор — не более.
Хотя код под линуксом я пишу исключительно в нем.
Попробуйте плагин для вим — github.com/tpope/vim-fugitive
Он как раз решает все проблемы перечисленные вами :)
Он как раз решает все проблемы перечисленные вами :)
Спасибо! Посмотрел видео о нем (не все, обрывками) — работа с аннотацией очень понравилась.
Попробую при случае.
Попробую при случае.
А как он решает задачу «Брать в commit лишь часть локальных изменений файла»? Насколько я знаю, AuRecord всё ещё не имеет аналогов. Fugitive, правда, позволяет писать в staging area, но я слабо представляю, насколько это удобно использовать для данной задачи.
Очень удобно — тоже через diffsplit справа открывается рабочая копия, слева оригинал.
Переносите изменения налево, сохраняете и получаете это в staging.
Переносите изменения налево, сохраняете и получаете это в staging.
А можно конкретные команды? Пока это выглядит как AuRecord, но без окна с состоянием внизу. Окно же нужно:
Можно узнать, как со всем этим справиться в fugitive?
- Показывает состояние рабочей копии и какие файлы будут включены в изменение (первая колонка: не включён/включён частично/включён полностью/не включён, но редактировался для частичного включения)
- Позволяет выбрать файлы для полного включения (в т.ч. неизвестные и удалённые, они будут добавлены или забыты). Причём выбрать скопом
- Позволяет отменить изменения, предназначенные для частичного внесения или переоткрыть их заново
- Хранит всю историю включений/изменений текущей сессии. То есть, делая undo/redo в окне состояния вы можете отменить или восстановить сделанные частичные изменения (правда гранулярность пока ниже: сохраняется только последнее состояние перед следующим изменением, произведённым в окне состояния; история правок внутри файла не сохраняется).
Можно узнать, как со всем этим справиться в fugitive?
Окно с состоянием тоже есть, но для того чтобы не отвечать на все вопросы по отдельности советую таки сходить по ссылке и посмотреть скринкасты. В них показан весь основной функционал
Видео традиционно не работает (зато работает звук, что странно). Английскую речь без субтитров, как всегда, сложнее понять. Скачанный OGV в mplayer не работает также (QT работает). Ненавижу скринкасты, хотя этот неплох, если вы смогли его запустить.
Хотя кое‐что прояснилось: 1, 2, 3 есть (хотя и с замечаниями). 4 нету. Похоже, если есть staging area, то fugitive удобнее (4 не особо нужно) в этом отношении.
Хотя кое‐что прояснилось: 1, 2, 3 есть (хотя и с замечаниями). 4 нету. Похоже, если есть staging area, то fugitive удобнее (4 не особо нужно) в этом отношении.
Если соблазнились, то сразу предупреждаю: дополнение предназначено в первую очередь для работы с mercurial. Всё остальное протестировано хуже. Кроме того, одним из основных предназначений дополнения является унификация работы в различных системах контроля версий. Т.е. в aurum вы работаете так, как будто staging area не существует, а все состояния файлов приводятся к 8 состояниям, используемым mercurial.
Кроме того, одним из основных предназначений дополнения является унификация работы в различных системах контроля версий.
Вот здесь думаю вы не правы:
у каждой системы контроля версий свои особенности и свой «дзен». Пытаясь унифицировать их все к одному интерфейсу вы тем самым ограничиваете их функционал, кроме того в отдельных случаях это может быть не возможно, либо ввести пользователя в заблуждение
(к примеру команда 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 несколько несогласованной.
В mercurial есть crecord для таких финтов. Только вроде бы он отдельно идёт, не в поставке.
Последний (и единственный) раз, когда я его смотрел, у него были проблемы с русским языком в файлах. Русский у меня сейчас только на моих старых проектах, но и на новых часто встречаются юникодные символы (в основном апострофы, кавычки (а не ASCII‐убожество), маркеры для складок (использую «▶,▲» вместо «{{{,}}}»)). И ещё мне чего‐то не понравилось в интерфейсе (не помню, что именно). Напомните, в Crecord можно работать с изменениями в произвольном порядке?
Да, с юникодом проблемы были, а может и есть — я уже с год не обновлялся. А что значит в произвольном порядке? Что попросите, то и коммитнет. Порядка там вообще нет :)
Я имею ввиду, можно ли сначала посмотреть (и отметить) изменения в одном файле из конца списка, потом в другом из начала, потом отметить полностью какие‐то файлы в середине, затем вернуться к первому, и, возможно, переотметить.
Эмм. Такое ощущение, что вы его не видели вовсе. Конечно же можно, я же говорю, что выберете, то и коммитнется.
Это было очень давно, а я не помню, в чём были проблемы (старое ощущение — «ужас, ужас, ужас» и всё). Сейчас опять запустил, вижу проблему с границами выделений (на русском тексте) и замечательный текст «изменено поло�~A: 5, �~A�~B�~@ок: 165». Если что, это не часть изменений. Также вижу отсутствие возможности изменять текст внутри линии. Вижу замечательное поведение PageUp/PageDown (внутри длинного hunk прокручивает на одну строку). Вижу , двойное нажатие на который не ведёт к возвращению отметки к неотмеченным изменениям добавленного файла, а нажатие на единственный внутренний hunk (но не линию) убирает отметку со всех линий и самого hunk’а, но не с имени файла. При «review and edit» (единственный способ всё‐таки изменить текст внутри линии), а также при обычном commit не виден diff (мне он нужен, чтобы всё‐таки составить сообщение), и нельзя вернуться назад, если при просмотре diff’а обнаружилось что‐то не то. Подозреваю, что посмотреть diff можно, настроив mercurial засовывать его в комментарий (вроде где‐то пробегало что‐то такое, работающее для и «hg commit», и для всего остального).
Всё это не идёт ни в какое сравнение с AuRecord.
Всё это не идёт ни в какое сравнение с AuRecord.
Брать в commit лишь часть локальных изменений файлаПосмотрите на aurum. AuRecord позволяет брать часть изменений, используя обычный vim’овский diffsplit.
Вообще для всех остальных задач, по‐моему, достаточно нормально написанного дополнения к vim.
Не плохой. Будь у git ещё, к примеру, нормальный UI, а не просто внутренности наружу — этот аргумент можно было бы даже воспринимать всерьёз.
Ммм… Отличный плагин для Идеи и ГитХаб — что ещё нужно?)
Из стандартных есть gitk и git gui.
А так же есть SmartGit, и многие ide могут делать все операции прямо из себя.
А так же есть SmartGit, и многие ide могут делать все операции прямо из себя.
git extensions — кроссплатформенный бесплатный UI для git. Удобный и мощный, можно никогда не пользоваться командной строкой (да простит меня Линус).
Если точнее — у git нет нормального UI по Windows или Linux
Зато под OSX — вагон.
Посмотрите на Git Tower (http://www.git-tower.com/) — он прекрасен
Но если сложно — то есть GitBox (http://gitboxapp.com/) — он простой как почтовый клиент
Не хочется платить? Есть бесплатный SourceTree (http://www.sourcetreeapp.com/) — который выглядит похуже, но возможностей имеет больше всех
И это еще не считая всяких опенсорсных GitX, GitY — простенькие и со вкусом.
Лучшее что удалось найти под Windows — Git Extensions и SmartGit — мягко говоря странны и неудобны.
Зато под 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, что другого и не надо.
Угу, но не все ежедневные проблемы он может решать — stackoverflow.com/q/12528854/251311
Может сейчас уже и возможно, полгода назад приходилось расчехлять консоль
Может сейчас уже и возможно, полгода назад приходилось расчехлять консоль
TortoiseSVN ужасен, а TortoiseGIT, который пытается быть его клоном, еще хуже.
Еще раз и медленно — вы думаете что это приятный UI потому что просто не видели нормального UI для Git. Но по какой-то странной причине удобные и продуманные интерфейсы для GIT есть только для OSX
Еще раз и медленно — вы думаете что это приятный UI потому что просто не видели нормального UI для Git. Но по какой-то странной причине удобные и продуманные интерфейсы для GIT есть только для OSX
Дело привычки. Лично мне пары tortoisegit + gitk хватает для 99% ежедневных задач.
Удобность и продуманность — субъективные метрики. Мне tortoisegit кажется достаточно удобным и достаточно продуманным, потому как он позволяет мне выполнять то, что мне нужно без каких бы то ни было затруднений :-)
Удобность и продуманность — субъективные метрики. Мне tortoisegit кажется достаточно удобным и достаточно продуманным, потому как он позволяет мне выполнять то, что мне нужно без каких бы то ни было затруднений :-)
Я юзал под виндами tortoisegit + gitk — и это было — ну как первые Жигули. Ну т.е. ездит, выглядит страшно, тарахтит и постоянно что-то не так — то ошибку выдаст какую-нить, то еще что-то.
А затем я попробовал Git Tower на маке. Ощущения — как будто сел в новенькую иномарку с автоматом и просто получаю удовольствие. Кликов — меньше, наглядности — больше, автоматизации — тоже.
А затем я попробовал Git Tower на маке. Ощущения — как будто сел в новенькую иномарку с автоматом и просто получаю удовольствие. Кликов — меньше, наглядности — больше, автоматизации — тоже.
Возможно, одна из причин качества утилиты — её платность $59 это совсем не шуточная цена.
А опенсорс это опенсорс.
А опенсорс это опенсорс.
Дык это, SourceTree бесплатен и тоже очень крут. И ни одна линуксовая/виндовая бесплатная утилита и рядом не валялась.
Есть чуть менее красивая, но даже более удобная — SourceTree — совершенно бесплатная. И разработчик ее — именитый Atlassian — собственно владелец BitBucket
Но почему-то они делают ее только для OSX
Но почему-то они делают ее только для OSX
По скринам — *очень* похоже на TortoiseHG :-)
О_о
Шок!
Шок!
Похоже, да не то. У всех виндовых утилит проблема одна — они написаны как будто для SVN, без внимания к веткам.
Посмотрите как ветки переключаются в Git Extensions, SmartGit
У TourtoiseHG — какие-то списки или меню.
В SourceTree/Git Tower — все ветки видны в левой панели, переключиться дело одного клика.
Посмотрите как ветки переключаются в Git Extensions, SmartGit
У TourtoiseHG — какие-то списки или меню.
В SourceTree/Git Tower — все ветки видны в левой панели, переключиться дело одного клика.
В нашей компании единицы способны сделать что-либо из командной строки git, ибо хватает UI клиента. И на мой взгляд, это хорошо. Кому нужно, давно освоил командную строку. Используется в основном git extensions и интеграцией в Visual Studio. Отдельные люди, которых я не понимаю, используют TortoiseGit. Термины blob и им подобные тоже большинству не знаком.
Вроде нормальные UI
— gitorious
— gitlab
— gitblit
Плюс тьма приложений для веток, которые локальные.
Или что вы имели в виду?
— gitorious
— gitlab
— gitblit
Плюс тьма приложений для веток, которые локальные.
Или что вы имели в виду?
А почему бы и нет.
Зачем мне как пользователю использовать что то, что пытается угнаться за гитом и его функциональностью?
Гит вполне себе проверен на огромных проектах (linux, android и тд) и по нему легко можно найти ответы.
В гите большинство фич были заложены изначально, кому как не Линусу знать что может потребоваться и как будет лучше.
В итоге другие DVCS, выступают в роли догоняющих.
Зачем мне как пользователю использовать что то, что пытается угнаться за гитом и его функциональностью?
Гит вполне себе проверен на огромных проектах (linux, android и тд) и по нему легко можно найти ответы.
В гите большинство фич были заложены изначально, кому как не Линусу знать что может потребоваться и как будет лучше.
В итоге другие DVCS, выступают в роли догоняющих.
НЛО прилетело и опубликовало эту надпись здесь
changeset obsolence:
This feature is experimental! Do not try it unless you are an experienced Mercurial user.
nice
p.s. как по мне, любая переделка истории — зло. (реверт тут не рассматриваем)
This feature is experimental! Do not try it unless you are an experienced Mercurial user.
nice
p.s. как по мне, любая переделка истории — зло. (реверт тут не рассматриваем)
Так ВЕСЬ гит про переделку истории — реверты, ребэйзы, скваши…
ТОЛЬКО локальные изменения, пока они еще не попали на сервер.
Все что попало в паблик, уже меняться не должно.
Все что попало в паблик, уже меняться не должно.
А, понял о чем вы говорите. А черепикать мы разве можем только локальное?
Ага. Только меняться оно может. Mercurial просто не имеет возможности указать другому концу, что надо удалить некоторое изменение. С git вам достаточно изменить всё локально, удалить на том конце изменённые ссылки и сделать push. Больше старых измений никто не увидит, а первая же сборка мусора удалит их окончательно.
В Mercurial уже появились все необходимые средства для изменения локальной истории. Теперь появляется возможность спрятать изменения с помощью changeset obsolescence. Но удалить их по‐прежнему нельзя.
В Mercurial уже появились все необходимые средства для изменения локальной истории. Теперь появляется возможность спрятать изменения с помощью changeset obsolescence. Но удалить их по‐прежнему нельзя.
Подскажите, что такого в commit phases, чего нельзя сделать в git с ветками, желательно с нормальным примером?
Если фазу поставить secret, то с пушем ченджсет не уйдёт
ps: лично мне ни разу такого не нужно было и я не совсем уверен, что это именно «киллерфича», просто это единственное, что придумывается
ps: лично мне ни разу такого не нужно было и я не совсем уверен, что это именно «киллерфича», просто это единственное, что придумывается
Если я правильно понял, то это тоже самое что выбрать через cherrypick и запушить только нужные комиты? Оставив при это все остальное в локальной ветке, и merge/rebase/cherrypick это все так же когда потребуется?
Самое главное, что в случае с phase secret исключается человеческий фактор в этом непростом процессе. Т.е. это скорее решение не технической проблемы, а людской
Пока не совсем вижу как облегчается.
Вот например мне надо залить пару комитов из какой то ветки:
git checkout master
git cherrypick commit1
git cherrypick commit2
git push
Вроде тоже не сильно сложно, или я что то упускаю в commit phases
Вот например мне надо залить пару комитов из какой то ветки:
git checkout master
git cherrypick commit1
git cherrypick commit2
git push
Вроде тоже не сильно сложно, или я что то упускаю в commit phases
Облегчается в том, что вы всю вашу магию можете забыть выполнить и по случайному `git push` уедет ченджсет, который не должен был ещё уезжать.
Т.е. я не говорю, что сделать в гите это будет сложно, я говорю, что оно защитит вас от ненарочного пуша.
Т.е. я не говорю, что сделать в гите это будет сложно, я говорю, что оно защитит вас от ненарочного пуша.
Почему он должен уйти куда, если вы все готовите в локальной ветке и мержете в ту которую нужно будет пушить?
Уйдет только то что вы сами лично добавили, только подготовленные комиты.
Уйдет только то что вы сами лично добавили, только подготовленные комиты.
Потому что даже у локальной ветки может быть апстрим из origin. И в неё все ченджсеты отправляются при пуше
Как у локальной ветки которая создавалась локально специально для данной фичи может быть какой то апстрим? Давайте не путать, если у ветки прописан remote, то она уже никакая не локальная.
Я термин «локальная» ветка определяю как ветка, которая показывается в `git branch`, вне зависимости от того, есть у неё апстрим, или нет.
Фичабранч легко может жить в удалённом репозитории и быть апстримом для локальной ветки.
Для случаев, когда вы из локальной ветки не хотите что-то случайно запушить — есть phase secret.
Фичабранч легко может жить в удалённом репозитории и быть апстримом для локальной ветки.
Для случаев, когда вы из локальной ветки не хотите что-то случайно запушить — есть phase secret.
Да с терминологией тяжковато тут.
Я понимаю как то так:
локальная — это ветка без апстрима, этой ветки больше нет ни у кого кроме вас
удаленная — это либо tracking branch либо remote, не важно, важно что все что вы пушите уходит на сервер.
В таком виде проще общаться, если вы знаете более удобные названия, я буду не против выслушать.
Так вот, для каждой фичи всегда создается отдельная локальная ветка, в которой вы работаете и подготавливаете комит, затем мержите уже в ветку из которой будет происходить пуш. Таким образом, что либо не так запушить становится ну очень проблематично.
Я понимаю как то так:
локальная — это ветка без апстрима, этой ветки больше нет ни у кого кроме вас
удаленная — это либо tracking branch либо remote, не важно, важно что все что вы пушите уходит на сервер.
В таком виде проще общаться, если вы знаете более удобные названия, я буду не против выслушать.
Так вот, для каждой фичи всегда создается отдельная локальная ветка, в которой вы работаете и подготавливаете комит, затем мержите уже в ветку из которой будет происходить пуш. Таким образом, что либо не так запушить становится ну очень проблематично.
> для каждой фичи всегда создается отдельная локальная ветка
Зачем? В чём смысл держать 2 фичабренча (общий и локальный)?
Зачем? В чём смысл держать 2 фичабренча (общий и локальный)?
Если вы работает один над фичей, то публиковать ветку смысла нет, хватит одной локальной, которую в конце сольете с основной.
А если вы работаете не один, то тут уже все тоже самое что с любой другой веткой. Нужна временная ветка для работы. Хотя бы для того что бы держать историю «чистой».
Принцип один и тот же для всех удаленных веток, так что тут ничего нового.
А если вы работаете не один, то тут уже все тоже самое что с любой другой веткой. Нужна временная ветка для работы. Хотя бы для того что бы держать историю «чистой».
Принцип один и тот же для всех удаленных веток, так что тут ничего нового.
Занятно :-) Логика в ваших словах есть, но на практике я просто ребейзю свои коммиты до тех пор, пока они не готовы, а потом по результатам сквашу, если нужно и пушу.
От того у вас и эти проблемы с push, костыли в виде commit phases, когда все работает с ветками просто замечательно и поломать довольно сложно.
Просто надо привыкнуть делать правильно, потом руки будут сами тянуться к git checkout -b… ;)
p.s. Интересно, как вы решаете проблему с автомержем при pull?
Просто надо привыкнуть делать правильно, потом руки будут сами тянуться к git checkout -b… ;)
p.s. Интересно, как вы решаете проблему с автомержем при pull?
Мне кажется, что если вы работаете не один над фичей, то это неправильные фичи.
Как мне кажется, фичи должны быть атомарными — так чтобы каждый человек мог сделать кусок.
На крайняк можно сделать так
Как мне кажется, фичи должны быть атомарными — так чтобы каждый человек мог сделать кусок.
На крайняк можно сделать так
master — feature_1 — feature_1_subtask_1 — feature_1 — master
\ feature_1_subtask_2 /
Ну это субъективно.
Практика (несколько тысяч бренчей и куча девелоперов) показывает, что подход работает (хотя я о своём опыте в данном тредике вообще не говорил, я лишь попытался придумать практическое применение mercurial phases, о чём и сказал в самом начале)
Практика (несколько тысяч бренчей и куча девелоперов) показывает, что подход работает (хотя я о своём опыте в данном тредике вообще не говорил, я лишь попытался придумать практическое применение mercurial phases, о чём и сказал в самом начале)
Не, это все понятно — я просто говорю о том, что так что в гите, что в меркуриале по моему мнению работать неправильно. Ну точнее что значит неправильно — лишает строгости и лаконичности, которую нам дарует successful branching model и построенный на ней git flow.
> несколько тысяч бренчей и куча девелоперов
мне сложно представить зачем столько вообще может понадобится(особенности mercurial?). В том же ядре линукса одна ветка и куча тегов. Но теги то понятно почему куча, это просто указатели.
мне сложно представить зачем столько вообще может понадобится(особенности mercurial?). В том же ядре линукса одна ветка и куча тегов. Но теги то понятно почему куча, это просто указатели.
фичабренчи, особенность проекта :-)
репозиторий на гите
> Но теги то понятно почему куча, это просто указатели.
Бренчи в гите это точно такие же указатели. Их единственное различие, что они с HEAD двигаются вместе.
репозиторий на гите
> Но теги то понятно почему куча, это просто указатели.
Бренчи в гите это точно такие же указатели. Их единственное различие, что они с HEAD двигаются вместе.
Это понятно, что это всего лишь указатели, но теги -это именно теги, а ветки — это именно ветки с историей.
Зачем вам 1000 веток с историей, вот в чем вопрос?
Зачем вам 1000 веток с историей, вот в чем вопрос?
А это проблема скорее организационная :-)
Они не мешают, потому особенно никого это не волнует.
> а ветки — это именно ветки с историей.
Ммммм, не хочется спорить, но я не согласен. В гите бренч это лишь указатель на конкретный ченджсет.
А если вспомнить, что ринадлежность ченджсета тому или иному бренчу в гите происходит в рантайме, то удаление бренча это скорее зло, чем добро. Потому что после удаления бренча невозможно сказать, в каком бренче это изменение было добавлено (если только не оставлять это же имя в комментариях специально для этого)
Они не мешают, потому особенно никого это не волнует.
> а ветки — это именно ветки с историей.
Ммммм, не хочется спорить, но я не согласен. В гите бренч это лишь указатель на конкретный ченджсет.
А если вспомнить, что ринадлежность ченджсета тому или иному бренчу в гите происходит в рантайме, то удаление бренча это скорее зло, чем добро. Потому что после удаления бренча невозможно сказать, в каком бренче это изменение было добавлено (если только не оставлять это же имя в комментариях специально для этого)
> А это проблема скорее организационная :-)
выглядит это именно так :)
> В гите бренч это лишь указатель на конкретный ченджсет.
который держит целую цепь комитов, и чем более ветвистое это дерево тем сложнее с ним работать. Тег тоже может держать цепь комитов, если скажем ветку удалить, но добавить новый вы не сможете пока заново не создадите ветку. То есть да, это все указатели, только свойства у них разные.
> Потому что после удаления бренча невозможно сказать, в каком бренче это изменение было добавлено
Ни разу не сталкивался с этим, можете пояснить зачем может понадобится знать откуда пришел комит? Ну например, о, этот комит пришел из ветка_супер_фича, что дальше?
выглядит это именно так :)
> В гите бренч это лишь указатель на конкретный ченджсет.
который держит целую цепь комитов, и чем более ветвистое это дерево тем сложнее с ним работать. Тег тоже может держать цепь комитов, если скажем ветку удалить, но добавить новый вы не сможете пока заново не создадите ветку. То есть да, это все указатели, только свойства у них разные.
> Потому что после удаления бренча невозможно сказать, в каком бренче это изменение было добавлено
Ни разу не сталкивался с этим, можете пояснить зачем может понадобится знать откуда пришел комит? Ну например, о, этот комит пришел из ветка_супер_фича, что дальше?
Например, это позволит узнать цель тех или иных модификаций
Для этого обычно используется описание комита. Не убедили.
В комит не вместишь столько, сколько можно вместить в документе, который описывал фичу. Я не понимаю, почему вы принципиально хотите ограничить себя в объёме доступной информации.
Так или иначе, я здесь не для того, чтобы вас переубедить. Для вас работает один способ, для меня другой. Не убедил — окей.
Так или иначе, я здесь не для того, чтобы вас переубедить. Для вас работает один способ, для меня другой. Не убедил — окей.
> В комит не вместишь столько, сколько можно вместить в документе, который описывал фичу.
1. а сколько информации можно вместить в имя ветки, о, или вы еще документ сохраняете с комитом?
2. на этот случай обычно указывается номер тикета и краткое описание. По номеру тикета легко находится полное описание.
> Так или иначе, я здесь не для того, чтобы вас переубедить
я с вами согласен, я тоже не для того что бы переубеждать вас, но когда вы говорите что для нормальной работы на большом проекте нужно 1000 веток я просто ну ни как не могу согласится, к тому же я не видел ни одного опен сорс проекта с таким количеством веток. Тот же андроид и линукс как то же живут и проблем не знают, и там разработчиков, я думаю, будет по более чем в вашем проекте.
1. а сколько информации можно вместить в имя ветки, о, или вы еще документ сохраняете с комитом?
2. на этот случай обычно указывается номер тикета и краткое описание. По номеру тикета легко находится полное описание.
> Так или иначе, я здесь не для того, чтобы вас переубедить
я с вами согласен, я тоже не для того что бы переубеждать вас, но когда вы говорите что для нормальной работы на большом проекте нужно 1000 веток я просто ну ни как не могу согласится, к тому же я не видел ни одного опен сорс проекта с таким количеством веток. Тот же андроид и линукс как то же живут и проблем не знают, и там разработчиков, я думаю, будет по более чем в вашем проекте.
> 2. на этот случай обычно указывается номер тикета и краткое описание. По номеру тикета легко находится полное описание.
Да, т.е. техническая проблема «получить название ветки» вы предлагаете решать организационно «давайте не будем забывать добавлять номер тикета». А чтобы по-настоящему не забывать — давайте добавим хуки, которые нам помогут это не забыть.
Итого — у вас 1 организационный инструмент и 1 технический, у меня — 1 технический, при том же результате.
> говорите что для нормальной работы на большом проекте нужно 1000 веток
Это исторические ветки, которые после решения задачи просто напросто не были удалены. Понимаете, проект живёт долго, потому фич было больше 1000. А бренчи удалены не были. И они никому не мешают, они где-то там вверху графа, и их никто даже не видит. Есть они не просят, для анализа графа и решения текущих задач не мешают. В чём проблема-то? :-)
Да, т.е. техническая проблема «получить название ветки» вы предлагаете решать организационно «давайте не будем забывать добавлять номер тикета». А чтобы по-настоящему не забывать — давайте добавим хуки, которые нам помогут это не забыть.
Итого — у вас 1 организационный инструмент и 1 технический, у меня — 1 технический, при том же результате.
> говорите что для нормальной работы на большом проекте нужно 1000 веток
Это исторические ветки, которые после решения задачи просто напросто не были удалены. Понимаете, проект живёт долго, потому фич было больше 1000. А бренчи удалены не были. И они никому не мешают, они где-то там вверху графа, и их никто даже не видит. Есть они не просят, для анализа графа и решения текущих задач не мешают. В чём проблема-то? :-)
У вас случайно написание текста комита не является организационным моментом?
Давайте еще в теле комита писать
— комит
— тест комит
— ку-ку
все равно в ветке лежит документ с описанием, так? :)
Я считаю это обязанность любого разработчика написать нормальное описание комита, включающее туда всю необходимую информацию, как минимум, к какому тикету принадлежит и что именно патч делает.
В этом случае отпадает необходимость в долго живущих фиче ветках и остальных костылях, в виде сохранения документа с описанием.
Давайте еще в теле комита писать
— комит
— тест комит
— ку-ку
все равно в ветке лежит документ с описанием, так? :)
Я считаю это обязанность любого разработчика написать нормальное описание комита, включающее туда всю необходимую информацию, как минимум, к какому тикету принадлежит и что именно патч делает.
В этом случае отпадает необходимость в долго живущих фиче ветках и остальных костылях, в виде сохранения документа с описанием.
> и чем более ветвистое это дерево тем сложнее с ним работать
Удаление имени бренча «проблему» с ветвистым DAG никуда не убирает. Просто из этого дерева пропадают метки (бренчи) напротив некоторых ченджсетов, а дерево остаётся тем же самым, с которым «сложно работать» :-)
Удаление имени бренча «проблему» с ветвистым DAG никуда не убирает. Просто из этого дерева пропадают метки (бренчи) напротив некоторых ченджсетов, а дерево остаётся тем же самым, с которым «сложно работать» :-)
> Просто из этого дерева пропадают метки (бренчи) напротив некоторых ченджсетов, а дерево остаётся тем же самым, с которым «сложно работать»
Как то вы не так работаете с ветками. Ну есть у нас 5-6 веток на все случаи жизни. Все остальное это временные ветки, которые по завершению ребэйзятся по верх одной из 5. Ни каких ветвлений и срача в истории.
Как то вы не так работаете с ветками. Ну есть у нас 5-6 веток на все случаи жизни. Все остальное это временные ветки, которые по завершению ребэйзятся по верх одной из 5. Ни каких ветвлений и срача в истории.
>> Как то вы не так работаете с ветками
У вас свой опыт, у меня свой. У меня он работает. Прекращайте считать свой опыт единственно верным.
>> Ни каких ветвлений и срача в истории
Удаление веток вообще никак со «срачем» (спасибо за характеристику репозитория, который вы даже и не видели) и ветвлением не связано.
Объём ветвлений зависит ТОЛЬКО от числа разрабатываемых фич. Вне зависимости от подхода граф будет ветвиться только по числу фич, и ваше решение даст ту же самую картинку, что и моё. Разве что вы удалите потом названия бренчей из графа, а я нет.
Вы с этим хоть согласны?
У вас свой опыт, у меня свой. У меня он работает. Прекращайте считать свой опыт единственно верным.
>> Ни каких ветвлений и срача в истории
Удаление веток вообще никак со «срачем» (спасибо за характеристику репозитория, который вы даже и не видели) и ветвлением не связано.
Объём ветвлений зависит ТОЛЬКО от числа разрабатываемых фич. Вне зависимости от подхода граф будет ветвиться только по числу фич, и ваше решение даст ту же самую картинку, что и моё. Разве что вы удалите потом названия бренчей из графа, а я нет.
Вы с этим хоть согласны?
> Удаление веток вообще никак со «срачем» (спасибо за характеристику репозитория, который вы даже и не видели) и ветвлением не связано. Вы с этим хоть согласны?
Судя по вашему же описанию, у вас создается одновременно огромное количество веток для каждой фичи, мало того эти все ветки потом еще и живут. Вот после такого дерево очень красивое, ветвистое получается — это и называется срач, его нужно прибирать через rebase и удаление старых веток.
Судя по вашему же описанию, у вас создается одновременно огромное количество веток для каждой фичи, мало того эти все ветки потом еще и живут. Вот после такого дерево очень красивое, ветвистое получается — это и называется срач, его нужно прибирать через rebase и удаление старых веток.
Нет, эти ветки исторические, они создаются в момент решения задачи, потом по завершению задачи мерджатся куда нужно и просто остаются в истории, без удаления (потому что зачем их удалять?)).
Прошло полдня, но так и не понял, почему удаление старых веток что-то должно менять. Дерево то же, визуально выглядит так же, нет только меток.
Прошло полдня, но так и не понял, почему удаление старых веток что-то должно менять. Дерево то же, визуально выглядит так же, нет только меток.
> завершению задачи мерджатся куда нужно
> Дерево то же, визуально выглядит так же, нет только меток.
Либо у вас не так много людей одновременно работает, либо ветвистость у вас не считается какой то проблемой. Тут два программиста работают и ветвистость есть, а когда их скажем 300, и вы говорите что проблемы нету, тем более что вы ветки мержите а не rebase делаете? :)
> Дерево то же, визуально выглядит так же, нет только меток.
Либо у вас не так много людей одновременно работает, либо ветвистость у вас не считается какой то проблемой. Тут два программиста работают и ветвистость есть, а когда их скажем 300, и вы говорите что проблемы нету, тем более что вы ветки мержите а не rebase делаете? :)
Проблем нет, делаются мерджи :-) Ветвистость есть, но от неё не уйдёшь
> Ветвистость есть, но от неё не уйдёшь
Вот оно наконец то. Ветвистость легко обходится при желании, когда его нету можно и 1000 веток оставить.
Вот оно наконец то. Ветвистость легко обходится при желании, когда его нету можно и 1000 веток оставить.
Желания нет, потому что проблемы нет.
Мердж вместо ребейза — более удобный (субъективно, для меня и проекта) способ управления проектом и организацией репозитория.
Мердж вместо ребейза — более удобный (субъективно, для меня и проекта) способ управления проектом и организацией репозитория.
Работа с одновременно активными даже 5-6 веток, то еще удовольствие, а у вас их >1k
Я надеюсь вам никогда не придется накатывать комиты на копию проекта один за одним.
Я надеюсь вам никогда не придется накатывать комиты на копию проекта один за одним.
Мы не работаем с > 1000 веток одновременно. Я уже дважды сказал, что эти ветки исторические, в них работа велась, скажем, два года назад. С тех пор ветку вмерджили в релиз и оставили на память. Есть она не просит.
Каждый разработчик работает со своей веткой исключительно.
То, что где-то когда-то были созданы бренчи никому не мешает (и я не могу представить, как оно в принципе может как-то кому-то мешать).
Каждый разработчик работает со своей веткой исключительно.
То, что где-то когда-то были созданы бренчи никому не мешает (и я не могу представить, как оно в принципе может как-то кому-то мешать).
НЛО прилетело и опубликовало эту надпись здесь
А почему вы вообще должны даже начать думать о ребейзе паблик ветки?
Складывается ощущение что в виду не правильной работы с ветками, приходится использовать защитные костыли.
Складывается ощущение что в виду не правильной работы с ветками, приходится использовать защитные костыли.
НЛО прилетело и опубликовало эту надпись здесь
Когда phases только появились, читал где-то в wiki mercurial или в чьём-то блоге историю и предпосылки появления этой функции. Так вот, это именно защитный механизм от ребейза ченджестов (и других изменений истории), которые уже были запушены в удалённый репозиторий. Для иллюстрации проблемы приводилось письмо Линуса в мейл листе, в котором он сокрушался на одного из контрибьюторов ядра, что тот опять сделал ребейз публичной ветки поверх своих комитов. Так что проблема не надумана, а очень даже насущна.
Бегло погуглил, найти эту ссылку не смог, сорри, но история была.
Бегло погуглил, найти эту ссылку не смог, сорри, но история была.
Спасибо за внятный ответ. А как именно работает phases, его нужно предварительно настроить или оно само работает, и какова вероятность что пользователь не сделает force уже существующей ветки при пуше?
Для того, чтобы оно работало, нужно только обновиться. «Сделать force существующей ветки» так же, как в git, невозможно — из истории на удалённом сервере нельзя удалить ничего, если только у вас нет там доступа к shell. Сделать rebase, «проигнорировав» фазы можно — сначала помечаете изменения как черновики («phase --force --draft»), затем делаете rebase, затем push (опять с ключом --force). Правда всё, чего вы добьётесь, — это появления новой головы в репозитории. При следующем pull изменения, которые вы якобы переместили, опять у вас появятся. Перемещённые версии, впрочем, тоже сохраняться.
Phases не запрещают стрелять себе в ногу. Они только усложняют нажатие на курок.
Phases не запрещают стрелять себе в ногу. Они только усложняют нажатие на курок.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
imho, если бы они были на столько круты и удобны, Линус бы не стал писать велосипед и ядро было бы уже под ним.
но что то я не вижу кучи проектов, макс для контроля версий используют: git, svn или mercurial (коммерческие рассматривать нет смысла).
но что то я не вижу кучи проектов, макс для контроля версий используют: 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.
Согласно википедии: 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.
Пара дней что-то решают? :-)
Ну серьёзно, за пару дней ещё не было ничего даже близко рабочего и отражающего суть будущего проекта. Не говоря уже о том, что они могли не знать о намерениях друг друга, или знать не всё.
Ну серьёзно, за пару дней ещё не было ничего даже близко рабочего и отражающего суть будущего проекта. Не говоря уже о том, что они могли не знать о намерениях друг друга, или знать не всё.
Вы так говорите, как будто Линусу нужно было подождать 2 дня и начать использовать Mercurial?
На самом деле ничего не подошло и меркуриала еще не было. Линусу нужно было сидеть и ждать с моря погоды, пока кто то догадается написать нужную для него dvcs?
Вот он начал писать сам, откуда он знает что какой то Mackall начал писать чуть позже тоже, к тому же свою dvcs он может контролировать как угодно и ни под кого не подстраиваться.
В общем все как написал выше, не было ничего подходящего и он начал писать сам, в чем я не прав?
На самом деле ничего не подошло и меркуриала еще не было. Линусу нужно было сидеть и ждать с моря погоды, пока кто то догадается написать нужную для него dvcs?
Вот он начал писать сам, откуда он знает что какой то Mackall начал писать чуть позже тоже, к тому же свою dvcs он может контролировать как угодно и ни под кого не подстраиваться.
В общем все как написал выше, не было ничего подходящего и он начал писать сам, в чем я не прав?
Нет, не говорю.
Это было насчёт вашего
> Ну не совсем так.
В мире ПО, в особенности такого сложного, два дня это таки «одновременно»
Вы правы, что не было и что он сам начал писать. Более того, вы правы буквально насчёт «не одновременно», но фактически — одновременно :)
Это было насчёт вашего
> Ну не совсем так.
В мире ПО, в особенности такого сложного, два дня это таки «одновременно»
Вы правы, что не было и что он сам начал писать. Более того, вы правы буквально насчёт «не одновременно», но фактически — одновременно :)
Увы, люди любят следовать моде. PHP, MySQL, а теперь вот git — часто самым популярным становится отнюдь не самое технически лучшее решение.
Понятие «лучшее» очень сильно субъективировано и зависит от конкретного варианта использования. Без сомнения у Mercurial гораздо более низкий порог старта и для маленькой команды он проще. Но в большой команде, где активно используются временные ветки и управление правами на основе шаблонов имен веток, Git даёт преимущества.
Как говорил Фредерик Брукс в своей бессмертной книге: «No silver bullet ©»
Как говорил Фредерик Брукс в своей бессмертной книге: «No silver bullet ©»
Я исповедую такую философию, что «серебряная пуля» всегда «есть». На любые два решения, имеющие преимущества и недостатки, всегда можно найти третье решение, которое соединяет их преимущества. Другое дело, что на это нужно время. Т.е. в какой-то конкретный момент времени ее могли еще не сделать. Но это не значит, что она технически невозможна и ее не сделают никогда.
А чем hg bookmark не замена git branch — там еще не сделали управление правами?
А чем hg bookmark не замена git branch — там еще не сделали управление правами?
А чем hg bookmark не замена git branch — там еще не сделали управление правами?
Где? Насколько я понимаю, это вопрос к реализации сервера. И ни у git, ни у mercurial в стандартной поставке хорошего сервера нет, максимум что‐то для быстрого расшаривания в доверенной сети.
А относительно практически любых технических преимуществ git я напомню, что в mercurial вы можете взять и написать расширение. Что закладки, что фазы, что изменение истории, что поддержка больших файлов — всё это изначально жило (а иногда и сейчас живёт) в виде расширений. А в git ничего заранее непредусмотренного нельзя добавить — я как‐то не припомню, чтобы к коммиту в git хоть кто‐то добавил хоть какие‐то метаданные, которые хотя бы не мозолили глаза пользователю, не говоря уже о том, чтобы не участвовали в создании хэша. Для тех же фаз это обязательное требование.
НЛО прилетело и опубликовало эту надпись здесь
Ну, вот собственно, мой вопрос актуален — какой хоть один реальный плюс git, кроме «о нем все знают»?
НЛО прилетело и опубликовало эту надпись здесь
Point.
А еще? (Я не ради подколки спрашиваю, мне действительно интересно, может, я чего-то не учел и в других workflow что-то вылазит.)
А еще? (Я не ради подколки спрашиваю, мне действительно интересно, может, я чего-то не учел и в других workflow что-то вылазит.)
НЛО прилетело и опубликовало эту надпись здесь
«staging area» — ну, это скорее минус, чем плюс. в смысле неоправданное переусложнение дизайна. staging area, stash и пр. — зачем дублировать сущности, если можно сделать просто «secret» commit?
«теги-рефы» — что это и зачем нужно?
«теги-рефы» — что это и зачем нужно?
Staging area для работы нужно всего две возможности: фиксация состояния не с файловой системы¹ и перехват команды фиксации изменений. Если бы кому‐то staging area была действительно нужна в mercurial, такое дополнение давно бы сделали.
Теги, создающие коммит — это однозначно сознательный выбор разработчиков. Добавить теги, не создающие коммит, было бы сложнее, чем добавить закладки — они отличаются только тем, что hg commit двигает закладку, но не двигал бы тег (и в git отличия на том по сути и заканчиваются, формат хранения у них одинаковый (если не трогать annotated теги)). Тем не менее, закладки есть, а тегов хотя бы на их основе (думаю легко было бы сделать так, чтобы, к примеру, переход на закладку tag-{name} не активировал бы её) — нет.
Странно, что никто не вспомнил частичные (без истории и/или без каких‐то файлов) клоны — их вроде сами разработчики mercurial хотят (когда‐нибудь) добавить, но пока не сделали.
¹ С точки зрения пользователя — последний раз, когда я смотрел код какого‐то hg *record он просто переписывал файлы на диске, фиксировал изменения и переписывал их обратно. На этой основе я делал свой AuRecord (часть дополнения aurum для Vim).
НЛО прилетело и опубликовало эту надпись здесь
Мы в своей работе используем не голый VCS, а с web-оболочкой. В нашем случае, это GitLab.
У него достаточно приятный интерфейс, довольно удобная система обработки merge request, CI. Встроенным трекером не пользуемся, так как есть Jira.
VCS — это лишь базовый функционал, а для удобства команды требуются более высокоуровневые вещи.
У него достаточно приятный интерфейс, довольно удобная система обработки merge request, CI. Встроенным трекером не пользуемся, так как есть Jira.
VCS — это лишь базовый функционал, а для удобства команды требуются более высокоуровневые вещи.
«не записывает переименование/копирование» — а вот это я на данный момент запишу скорее в плюсы git.
не, вообще, в идеале VCS должна, конечно, давать пользователю записывать такую информацию. но не обязательно сразу, должно быть можно создавать такие хинты позже (без изменения хешей ревизий/коммитов). а не так, что один раз забыл / неправильно записал — и уже все.
а так как сейчас оно реализовано в Mercurial — то, по-моему, лучше б его уже вообще не было (как git'е) — а потом бы допилили отдельно хранимые (но push'аемые между репозиториями) хинты (что стало чем в какой ревизии/коммите).
не, вообще, в идеале VCS должна, конечно, давать пользователю записывать такую информацию. но не обязательно сразу, должно быть можно создавать такие хинты позже (без изменения хешей ревизий/коммитов). а не так, что один раз забыл / неправильно записал — и уже все.
а так как сейчас оно реализовано в Mercurial — то, по-моему, лучше б его уже вообще не было (как git'е) — а потом бы допилили отдельно хранимые (но push'аемые между репозиториями) хинты (что стало чем в какой ревизии/коммите).
НЛО прилетело и опубликовало эту надпись здесь
А Вы копируете/переименовываете файлы в IDE? И Ваша IDE понимает mercurial? Ну, не спорю, так удобно, но это не всегда так (не для всего есть IDE и не каждая IDE понимает mercurial).
«неправильно как записать?» Та стандартно. Все, что делается вручную, может быть сделано с ошибкой. Классика — это когда сначала все делается без регистрации в hg, а потом наскоро (если вообще делается) делается
«неправильно как записать?» Та стандартно. Все, что делается вручную, может быть сделано с ошибкой. Классика — это когда сначала все делается без регистрации в hg, а потом наскоро (если вообще делается) делается
hg rm/cp -A (и указать не тот файл или забыть указать — немудрено). А уж про неидеальность hg addremove --similarity XX я вообще молчу.НЛО прилетело и опубликовало эту надпись здесь
Git в данном случае, я считаю, делает гораздо ближе к идеалу.
Он не пытается сохранять эту информацию вообще. Лучше уж так, чем пытаться сохранять ее неправильно (вынуждая юзера захардкоживать ее прямо в коммит). Возможно, позже добавят лайт-способ сохранять эту информацию (в смысле — не в коммитах) и тогда пусть сохраняет, а пока лучше уж так.
Хотя в целом в git'е на данный момент я вижу скорее минусы, чем плюсы. Множественный мердж и отсутствие (некорректно реализованного) сохранения информации про копирование/переименование — пока единственные плюсы, которые я вижу.
Он не пытается сохранять эту информацию вообще. Лучше уж так, чем пытаться сохранять ее неправильно (вынуждая юзера захардкоживать ее прямо в коммит). Возможно, позже добавят лайт-способ сохранять эту информацию (в смысле — не в коммитах) и тогда пусть сохраняет, а пока лучше уж так.
Хотя в целом в git'е на данный момент я вижу скорее минусы, чем плюсы. Множественный мердж и отсутствие (некорректно реализованного) сохранения информации про копирование/переименование — пока единственные плюсы, которые я вижу.
Ну к примеру «Ртуть» девелопят более прагматичные люди.
Все основное стараются запилить на Python и только то что действительно имеет смысл оптимизировать пишут на си. Более того расширения к «ртути» пишутся на Python и если чего из мануала непонятна на Pythonе прочитаешь. Ведь сейчас многие современные девелоперы или Ruby или Python «как орешки щелкают», т.е. легко код читают\пишут на этих языках.
Да, и как описал Джоэл Спольски(на хабре есть перевод на русский из 6 статей) наименование команд в SVN почти один в один в Mercurial. Примеры: hg rename, hg add, hg remove, etc. А в виду популярности этой SVN переход на Mercurial за счет знакомых имен команд как-то проще осуществляется.
Все основное стараются запилить на Python и только то что действительно имеет смысл оптимизировать пишут на си. Более того расширения к «ртути» пишутся на Python и если чего из мануала непонятна на Pythonе прочитаешь. Ведь сейчас многие современные девелоперы или Ruby или Python «как орешки щелкают», т.е. легко код читают\пишут на этих языках.
Да, и как описал Джоэл Спольски(на хабре есть перевод на русский из 6 статей) наименование команд в SVN почти один в один в Mercurial. Примеры: hg rename, hg add, hg remove, etc. А в виду популярности этой SVN переход на Mercurial за счет знакомых имен команд как-то проще осуществляется.
НЛО прилетело и опубликовало эту надпись здесь
Вполне себе дизайнеры пользуются SmartGit и достаточно успешно.
SVN для дизайнера самое — то. Да и правильно это! А вот разработчику SVN уже «тесно». Все эти Git, Mercurial они поощряют экспериментирование без которого ни обходится ни одна разработка.
Приведу пример на Mercurial:
Я хочу попробовать запилить фичу. Для этого делаю новый бранч, девелопю, комичу и вдруг на каком-то этапе я вдруг прихожу к выводу «да это же гуанкод, это нельзя никому показывать». Что я делаю? Я просто удаляю папку!!! Все. Никто никогда и не узнает, что я написал какой-то бред. А в SVN если вы уже создали бранч, то он там будет на вечно!
А в случае с дизайнером такого нельзя допускать! Потому что одному дизайнеру может показаться «бредом», а другой дизайнер в этом «бреде» может увидеть что-то что приведет к красивому решению. Поэтому все дизайнерские наработки, какими бредовыми они не были должны быть собственностью компании.
Приведу пример на Mercurial:
Я хочу попробовать запилить фичу. Для этого делаю новый бранч, девелопю, комичу и вдруг на каком-то этапе я вдруг прихожу к выводу «да это же гуанкод, это нельзя никому показывать». Что я делаю? Я просто удаляю папку!!! Все. Никто никогда и не узнает, что я написал какой-то бред. А в SVN если вы уже создали бранч, то он там будет на вечно!
А в случае с дизайнером такого нельзя допускать! Потому что одному дизайнеру может показаться «бредом», а другой дизайнер в этом «бреде» может увидеть что-то что приведет к красивому решению. Поэтому все дизайнерские наработки, какими бредовыми они не были должны быть собственностью компании.
Github for Windows?
Ну допустим у вас есть репозиторий с данными. И куча приложений, работающих с разными папочками в этом репозитории. Представьте оверхед по сравнению с svn.
НЛО прилетело и опубликовало эту надпись здесь
AuRecord тоже умеет распиливать hunk’и, даже и для subversion, если надо. И для mercurial. Третий аргумент исчезает, если правильно выбрать UI, потому что идея, используемая hg record универсальна и работает для любой VCS, умеющей status и cat-file.
Первый аргумент мне совершенно непонятен — в чём преимущество octopus merge перед двумя merge? Только количеством ревизий?
А вот второй аргумент меня зачастую весьма достаёт.
Первый аргумент мне совершенно непонятен — в чём преимущество octopus merge перед двумя merge? Только количеством ревизий?
А вот второй аргумент меня зачастую весьма достаёт.
НЛО прилетело и опубликовало эту надпись здесь
Bookmarks в Mercurial это lightweight-tag в Git'е: оба содержат только имя для коммита и ничего больше.
«Ветки» Git'a, это, скорее, heads — соответствуют heads в Mercurial. Одна ветка в Mercurial может иметь несколько голов, хотя обычно этим не злоупотребляют.
Там еще много интересных отличий. Например, изменение тэгов в Mercurial входит в коммит и отслеживается в дереве истории, тогда как в Git'е для сохранения информации о дате и авторе ярлыка надо сделать tag c описанием (annotated и/или signed), но в граф истории создание/изменение тэга не включается.
«Ветки» Git'a, это, скорее, heads — соответствуют heads в Mercurial. Одна ветка в Mercurial может иметь несколько голов, хотя обычно этим не злоупотребляют.
Там еще много интересных отличий. Например, изменение тэгов в Mercurial входит в коммит и отслеживается в дереве истории, тогда как в Git'е для сохранения информации о дате и авторе ярлыка надо сделать tag c описанием (annotated и/или signed), но в граф истории создание/изменение тэга не включается.
НЛО прилетело и опубликовало эту надпись здесь
Да, точно. Я, похоже, погряз в деталях внутреннего устройства Git'a и Mercurial'а и не сразу понял что Вы хотели сказать.
Ветки в Hg предназначены и используются для тех же целей, что и в Git'e, причем Hg-коммит привязан к конкретной ветке. Видимо, это часть того, что автор статьи назвал строгой работой с историей.
Закладки Hg более легковесны чем ветки, при этом активные закладки ведут себя как heads в Git'е. Так что — Вы правы — их удобно использовать с той же целью.
Ветки в Hg предназначены и используются для тех же целей, что и в Git'e, причем Hg-коммит привязан к конкретной ветке. Видимо, это часть того, что автор статьи назвал строгой работой с историей.
Закладки Hg более легковесны чем ветки, при этом активные закладки ведут себя как heads в Git'е. Так что — Вы правы — их удобно использовать с той же целью.
Я бы переименовал эту статью так: «Подробное объяснение, почему Mercurial — говно.»
Три раза «ха»!
И чтобы, не быть голословным я просто приложу картинку, на ней изображен маленький кусочек дерева одного проекта в Mercurial, по понятным причинам без лишних подробностей.
И каждый, кто скажет, что по такой полной истории удобно ходить и что-то там искать, пусть кинет мне в карму.
Например, для целей ведения коммерческого программного проекта мне больше импонирует Mercurial.
Строгая работа с историей в Mercurial гарантирует возможность учёта и поиска первоначального источника ошибки.
Три раза «ха»!
И чтобы, не быть голословным я просто приложу картинку, на ней изображен маленький кусочек дерева одного проекта в Mercurial, по понятным причинам без лишних подробностей.
И каждый, кто скажет, что по такой полной истории удобно ходить и что-то там искать, пусть кинет мне в карму.
НЛО прилетело и опубликовало эту надпись здесь
А как же тогда полная история?
Про которую я слышу каждый раз когда кто-то хвалит Меркуриал.
Насколько я знаю букмарки локальны и не идут в дерево.
Т.е. все преимущества мимо.
Про которую я слышу каждый раз когда кто-то хвалит Меркуриал.
Насколько я знаю букмарки локальны и не идут в дерево.
Т.е. все преимущества мимо.
Они уже умеют синхронизироваться с сервером.
НЛО прилетело и опубликовало эту надпись здесь
Ок вы не поняли над чем я смеюсь, я поясню.
Вам не кажется смешным, что сначала придумываются букмарки, которые как бранчи, только локальные, чтобы не срать в историю, а потом букмаркам делается возможность срать в историю, в результате мы получаем бранчи, которые срут в историю, и букмарки которые срут в историю. Что-то мне теперь не понятно, а где разница то?
Вам не кажется смешным, что сначала придумываются букмарки, которые как бранчи, только локальные, чтобы не срать в историю, а потом букмаркам делается возможность срать в историю, в результате мы получаем бранчи, которые срут в историю, и букмарки которые срут в историю. Что-то мне теперь не понятно, а где разница то?
НЛО прилетело и опубликовало эту надпись здесь
А что мне это дает как пользователю?
Возможно я ошибаюсь, но у меня сложилось впечатление, что MQ/branch/bookmark в mercurial представляют из себя разные паттерны использования веток в git. Если так, то не очень понятно, зачем изучать несколько механизмов, чем разобраться с одним (branches & rebase).
НЛО прилетело и опубликовало эту надпись здесь
Я так понял, что собственно ветки нужны для долгоживущих вещей вроде release-2.7, current-development, …, а закладки — для feature branches, чтобы исчезнуть после слияния. Во всяком случае, это кажется логичным.
НЛО прилетело и опубликовало эту надпись здесь
Правильно. В git для и для того, и для другого используются ветки. Достаточно хорошо освоить один механизм. Тем более, что бывает, что некоторые feature branches начинают жить долго :)
Закладки — это полный аналог веток в git. Нет никаких проблем иметь долгоживущие закладки вместе с долгоживущими ветками или использовать только их. А вот если вам важно сохранять информацию о том, к какой ветке принадлежит изменение, то в git ничего для этого нет.
Не пользовался, но давно мучит такой вот вопрос:
закладки же фактически создают ветвление в пределах одного бренча. Будет ли меркуриал ругаться о новых головах в этом случае? По идее должен.
Как эту проблему пользующиеся букмарками решают?
закладки же фактически создают ветвление в пределах одного бренча. Будет ли меркуриал ругаться о новых головах в этом случае? По идее должен.
Как эту проблему пользующиеся букмарками решают?
Он же сам подсказывает — «push -f».
Ну так вы же мержитесь по имени конкретной закладки. Если попробовать влить в ветку где есть несколько голов с закладками то разумеется оно ругнется.
Мой вопрос был скорее о том, что вся реализация букмарков в меркуриале обязывает юзать -f при пуше, что чревато проблемами
По-моему, вы субъективно воспринимаете «ключ силы» -f как что-то деструктивное. В данном контексте он означает «да, я прочитал предупреждение».
> как что-то деструктивное
Потому что оно и есть дестркутивное. Вместе с безобидными букмарками вы можете на центральный репозиторий отправить что-то ещё, сами того не подозревая об этом.
Примера назвать не смогу, но вы не можете быть уверены, что ваши изменения не сломают что-нибудь, просто потому что вы уже сняли предохранитель и не узнаете о возможных проблемах.
Потому что оно и есть дестркутивное. Вместе с безобидными букмарками вы можете на центральный репозиторий отправить что-то ещё, сами того не подозревая об этом.
Примера назвать не смогу, но вы не можете быть уверены, что ваши изменения не сломают что-нибудь, просто потому что вы уже сняли предохранитель и не узнаете о возможных проблемах.
Предохранитель — это хуки. Всё, что можно сломать push’ем — это добавить ненужные изменения, которые сможет удалить только администратор. Возможно что при «pull --update» пользователи в результате окажутся на каком‐то не том изменении. Если пользователи — не боты, то в этом ничего страшного нет. Если боты — всегда используйте только «push -f -B {name}»/«push -f -r {rev}», чтобы не отправить что‐то не то (эти команды отправляют только те изменения, которые им указали и их предков, больше ничего).
Пока мне видится MQ как прямой аналог использования interactive rebase, а не staging area. Staging area — удобный быстрый способ сформировать коммит включив туда только нужные изменения, для долгосрочной же деятельности используются ветки.
Бывает, перед push переписываю локальную историю: часть коммитов объединяю/разъединяю, меняю местами, обновляю комментарии. Опять же, могу всё выделить в ветку и запушить в общедоступное место. Из того, что я понял про MQ, это возможность относительно удобной перегруппировки изменений. В git для этого традиционно используется переписывание истории (interactive rebase). Разве что в hg MQ — это именованная сущность со своим набором команд, а в git всё те же ветки + продвинутый rebase.
Бывает, перед push переписываю локальную историю: часть коммитов объединяю/разъединяю, меняю местами, обновляю комментарии. Опять же, могу всё выделить в ветку и запушить в общедоступное место. Из того, что я понял про MQ, это возможность относительно удобной перегруппировки изменений. В git для этого традиционно используется переписывание истории (interactive rebase). Разве что в hg MQ — это именованная сущность со своим набором команд, а в git всё те же ветки + продвинутый rebase.
НЛО прилетело и опубликовало эту надпись здесь
Да, это, видимо прямой аналог. Моя проблема с mercurial в том, что он мне кажется сложней.
В git можно свернуть горы научившись работать с ветками: джентельменский набор — commit / push / pull / rebase / interactive rebase, понять что такое коммит и ветка. С помощью этого можно сделать очень много. Пока этого мне хватало для эффективной работы над несколькими релизами одновременно с разнородными активностями (коротокоживущие / долгие фичи / хотфиксы / перенос функциональности из релиза в релиз).
Что касается mercurial, нужно научиться commit / push / pull / rebase / mq / histedit чтобы научиться делать сравнимые вещи (хотя возможно даже более мощные, этого я не знаю). То есть нужно освоить в дополнение ещё несколько понятий, выучить несколько комманд.
В git можно свернуть горы научившись работать с ветками: джентельменский набор — commit / push / pull / rebase / interactive rebase, понять что такое коммит и ветка. С помощью этого можно сделать очень много. Пока этого мне хватало для эффективной работы над несколькими релизами одновременно с разнородными активностями (коротокоживущие / долгие фичи / хотфиксы / перенос функциональности из релиза в релиз).
Что касается mercurial, нужно научиться commit / push / pull / rebase / mq / histedit чтобы научиться делать сравнимые вещи (хотя возможно даже более мощные, этого я не знаю). То есть нужно освоить в дополнение ещё несколько понятий, выучить несколько комманд.
НЛО прилетело и опубликовало эту надпись здесь
Я общался с людьми, которых и VSS всем устраивал. Базовые навыки работы с mercurial и git получить очень легко. Говорю это основываясь на опыте перевода компании с зоопарка систем контроля версий StarTeam, ClearCase, SVN, CVS на git. В один прекрасный понедельник репозиторий StarTeam оказался read-only, и к середине дня работа уже шла как обычно. Потихоньку все втянулись, кто-то счастлив с моделью commit/pull+rebase/push, а многие освоились с advanced использованием (как переписывание истории). Один-два раза кто-то чуть не терял свои изменения за пару дней, но всё удавалось восстановить. git blame пользуется популярностью :)
В общем любую современную систему контроля версий на базовом уровне освоить легко, большинству больше этого и не нужно, а в умелых руках, что git, что mercurial способны творить чудеса.
В общем любую современную систему контроля версий на базовом уровне освоить легко, большинству больше этого и не нужно, а в умелых руках, что git, что mercurial способны творить чудеса.
Не вижу разницы — что в одном случае учить один набор команд, что в другом — другой. Да ещё и git’овский rebase — почему нельзя было сделать так, чтобы что и куда указывалось ключами. «hg rebase --source rebased --destination new-base» куда как понятнее «git rebase new-base rebased-tip», причём что и куда здесь очевидно*, а в git — нет. Схемы с «git rebase --onto new-base rebased rebased-tip» — вообще жесть, мне приходится каждый раз перечитывать «git help», чтобы что‐то сделать.
* Во‐первых, понятные имена ключей. Во‐вторых, указывается, что перемещать, а не последнее из перемещающихся изменений. Для тех, кому проще git’овское поведение у mercurial есть «--base». У git же нет «--source».
* Во‐первых, понятные имена ключей. Во‐вторых, указывается, что перемещать, а не последнее из перемещающихся изменений. Для тех, кому проще git’овское поведение у mercurial есть «--base». У git же нет «--source».
Кстати, интересно, что из hg branches не умеет git? В своё время я переключился с mercurial на git как раз из-за работы с ветками и производительности (после полугода работы с hg). Работать эффективно с ветками в git мне оказалось проще, и mercurial я толком тогда не осилил.
НЛО прилетело и опубликовало эту надпись здесь
Верно ли я понимаю, что речь о том, что коммит содержит информацию о том в какой ветке он создан? Если да, тогда я наверное понял что вы имели ввиду, спасибо!
Странно что не будет конфликта между комитами, или все же будет, если изменения пересекаются?
Какой конфликт? У ветки может быть сколько угодно голов. Так всегда делают для feature branches если неохота придумывать имена для закладок или вообще неохота их использовать.
— вот так вотНо её без форса не запушишь. А форс, это преступление против человечества :-)
Что можно почитать о том, как правильно работать с меркуриалом?
НЛО прилетело и опубликовало эту надпись здесь
Нет никакой «правильной» работы с меркуриалом, есть лишь некоторые более-менее популярные практики работы с репозиториями:
nvie.com/posts/a-successful-git-branching-model/
www.infoq.com/articles/agile-version-control
Сами методики не навязывают никакую из конкретных систем контроля версий, а лишь описывают способы организации процесса.
nvie.com/posts/a-successful-git-branching-model/
www.infoq.com/articles/agile-version-control
Сами методики не навязывают никакую из конкретных систем контроля версий, а лишь описывают способы организации процесса.
Для понимания Mercurial всегда даю ссылку на эту статью stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial
Эту штуку можно использовать вместо кофейной гущи и гадать по ней.
Или показывать начальнику, смотрите как все у нас серьезно, работа кипит :)
А так же можно попробовать рисовать картинки…
Комментарий Линуса на эту тему:
…
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
Или показывать начальнику, смотрите как все у нас серьезно, работа кипит :)
А так же можно попробовать рисовать картинки…
Комментарий Линуса на эту тему:
…
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
Ну если вы не смотрели исходники ядра linux через gitk, могу вас заверить, там ситуация не намного лучше.
У меня вот такой вот вопрос — если бранч закрыт — то зачем его отображать? В случае меркуриала мне это кажется бессмысленным.
НЛО прилетело и опубликовало эту надпись здесь
Ну так в том-то и прелесть закрытия бранча — закрыли его, можно и спрятать. и смотреть на него опять только в том случае, если возникнет подозрение, что именно в нем кто-то что-то накосячил. Чтобы этому кому-то что-то куда-то вставить. А так — закрытый бранч, вотличие от гита, неизменен.
Не приходится:
[alias]
g = log --graph --rev '..(head()-closed())'
[alias]
g = log --graph --rev '..(head()-closed())'
А, ну и еще одно — то, как это выглядит напоминает мне «feature branches? successful git branching model? Не, не слышал.»
Имена веток публикуются среди всех участников, поэтому в качестве имен обычно используют устойчивые во времени номера версий.
Если в проекте одновременно поддерживается столько версий, то мне искренне жаль его менеджера.
Если хочется порядка в «большом» хранилище, то локальную историю можно сжимать, прежде чем пересылать на сборку. Но если вы перешлете на сборку гига-патч, то в результате бисекции вы получите «ищите иголку где-то в этом стоге».
НЛО прилетело и опубликовало эту надпись здесь
Неплохо было бы так же указать и такие моменты:
blog.deliciousrobots.com/2011/3/27/no-git-really-is-much-better-than-mercurial/
blog.deliciousrobots.com/2011/3/27/no-git-really-is-much-better-than-mercurial/
НЛО прилетело и опубликовало эту надпись здесь
Если нужно изменить самую последнюю фиксацию, например, добавить что-нибудь забытое или изменить комментарий...
hg rollback
… добавить забытое
hg commit с новым комментарием
зачем в этом случае queue и импорт?
При том, что я сам предпочитаю ртуть, этому не хватает изящества аменда, особенно, когда аменд делается только за тем, чтобы поправить комментарий
НЛО прилетело и опубликовало эту надпись здесь
Вот ещё небольшое отличие stevelosh.com/blog/2010/01/the-real-difference-between-mercurial-and-git/#gits-index
stevelosh.com/blog/2010/08/a-git-users-guide-to-mercurial-queues/
MQ behaves very much like a souped-up version of git‘s index.
Ради всего святого, используйте заимствованное и укоренившееся слово «коммит». Я только на 3-4 «фиксации» понял, о чём идёт речь.
Основной и самый главный плюс для меня в Hg в том, что с TortoiseHg идёт удобнейший GUI Workbench. Для Git ничего бесплатного нет.
Можно привести полезную ссылку по ней есть чуть более развернутая информация по отличиям и сопоставлены команды гита и ртути
Вопрос: как у Меркуриала дела со ссылками на другие репозитории (Git submodules, SVN externals)?
Попользовавшись субмодулями в Гите, понял, что они — говно. Привязка из репозитоия — только к конкретной ревизии. Спулил у кого-нибудь во внешний репозиторий, не спулив субмодуль — сослалось на дырку от бублика. Были свои пуши в субмодуле — они улетели в тартарары. Сослаться на «последнюю версию в ветке» — нельзя. И так далее. Для пущей радости гитовый плагин для VS ни черта не поддерживает субмодули, в результате привычное управление проектом исключительно из VS невозможно. Шаг в сторону — TortoiseGit тоже становится бесполезным. Уж молчу про его совершенно невменяемый интерфейс, который без полбутылки не понять.
Как ссылки на другие репозитории реализованы в Меркуриале? Они сравнимы по функционалу с SVN externals, или такое же кривое убожество, как Git submodules?
Сейчас Git'ом пользоваться модно, и его выбрал как раз исходя из этого. Если куча опенсорсников сидит на гитхабе, то имеет смысл не идти против моды. Но такие вот «нюансы» печалят. Ну и, как сказано в топике, невозможность полноценного отслеживания веток исключительно по репозиторию несколько огорчает. Хотя это не так критично, как субмодули.
Попользовавшись субмодулями в Гите, понял, что они — говно. Привязка из репозитоия — только к конкретной ревизии. Спулил у кого-нибудь во внешний репозиторий, не спулив субмодуль — сослалось на дырку от бублика. Были свои пуши в субмодуле — они улетели в тартарары. Сослаться на «последнюю версию в ветке» — нельзя. И так далее. Для пущей радости гитовый плагин для VS ни черта не поддерживает субмодули, в результате привычное управление проектом исключительно из VS невозможно. Шаг в сторону — TortoiseGit тоже становится бесполезным. Уж молчу про его совершенно невменяемый интерфейс, который без полбутылки не понять.
Как ссылки на другие репозитории реализованы в Меркуриале? Они сравнимы по функционалу с SVN externals, или такое же кривое убожество, как Git submodules?
Сейчас Git'ом пользоваться модно, и его выбрал как раз исходя из этого. Если куча опенсорсников сидит на гитхабе, то имеет смысл не идти против моды. Но такие вот «нюансы» печалят. Ну и, как сказано в топике, невозможность полноценного отслеживания веток исключительно по репозиторию несколько огорчает. Хотя это не так критично, как субмодули.
НЛО прилетело и опубликовало эту надпись здесь
Поддерживается чекаут из hg, git и subversion.
Офигительно. Уже хочу. Не подскажете, с меркуриалом проблемы со ссылками, как в гите? Ну, скажем, один разраб пушнул локально коммиты в основной репозиторий и вложенный, а другой аналогично пушнул, а потом пульнул основной репозиторий с первого разраба — что увидит второй? :)
Ну и отлично.
Решает одну проблему (негарантированное воспроизведение репозитория), добавляет другую (головная боль при регулярных коммитах в основной и вложенный репозитории). Я скорее готов мириться в первым, потому что сталкиваться приходится чаще со вторым.
В дополнение про ссылку на ревизию/коммит: в SVN есть выбор, какую из двух проблем ты хочешь иметь (можно сослаться на ветку, можно сослаться на конкретную ревизию); в Git такого выбора нет.
У второго будет пулл и апдейт на нужный changeset для вложенного репозитория в момент апдейта локальной копии на конкретный changeset в основном репозитории.
Молодцы, заминусовали. А теперь жду развёрнутых ответов с объяснением, в чём я неправ. Или просто правда глаза режет?
Привязка репозитория к конкретной ревизии — это благо. Вы не обнаружите случайно свой код сломанным изменениями в каком-то удаленном репозитории.
Не понял что значит спулил во внешний репозиторий. Если вы про рекурсивный апдейт сабмодулей — то там всё хорошо.
Если у вас были свои пуши в сабмодуле — никуда они не улетят, только если вы специально им это скоммандуете.
Пользуйтесь git bash — всё работает как надо.
Не понял что значит спулил во внешний репозиторий. Если вы про рекурсивный апдейт сабмодулей — то там всё хорошо.
Если у вас были свои пуши в сабмодуле — никуда они не улетят, только если вы специально им это скоммандуете.
Пользуйтесь git bash — всё работает как надо.
Привязка репозитория к конкретной ревизии — это благо. Вы не обнаружите случайно свой код сломанным изменениями в каком-то удаленном репозитории.
А также не обнаружу, что некий корпоративный «фреймворк» уже трижды обновился, и я использую устаревшую версию, то есть в релиз мой «стабильно неломающийся» код пойти не может. Если реально нужна конкретная ревизия (например, фиксируется релизнутая версия), то в SVN ревизию указать можно.
Не понял что значит спулил во внешний репозиторий. Если вы про рекурсивный апдейт сабмодулей — то там всё хорошо.
Конкретный пример: первый разраб закоммитил в субмодуль, потом в содержащий его основной репозиторий (включая обновлённую ссылку на субмодуль); второй разраб аналогично закоммитил в основной репозиторий и субмодуль свои изменения, а потом пульнул изменения из основного репозитория с первого разраба — что увидит второй разраб?
Как обстоит ситуация с поддержкой Git в Windows в 2013 году? Сообщения в интернете от 2011 говорят, что всё плохо.
У меня есть сомнения, ибо не далее чем сегодня на безобидную команду словил вот это:
У меня есть сомнения, ибо не далее чем сегодня на безобидную команду словил вот это:
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 им тоже можно пользоваться.
Git SVN very slow comparative to the Linux version — Closed, Status: WontFix.
Git под Windows вообще похоже развивают по остаточному принципу. Точнее даже не развивают, а так, пытаются сделать вид, что под Windows им тоже можно пользоваться.
На самом деле всё очень даже хорошо. За почти 1.5 года использования (Win XP, Win 7) проблем, связанных с операционной системой у нас не было. К счастью, нам никогда не нужен был git svn. Производительность самого git устраивает чуть более чем полностью.
Ну вот смотрите, банальный пример косяка Git на Windows:
Решается это установкой core.filemode в false. Но об этом надо знать. А когда этого не знаешь, а пытаешься просто делать то, что тебе говорит гит, такое поведение мягко говоря вводит в ступор.
Скрытый текст
/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. Но об этом надо знать. А когда этого не знаешь, а пытаешься просто делать то, что тебе говорит гит, такое поведение мягко говоря вводит в ступор.
Ну так не надо пользоваться git из cygwin. msysgit работает стабильно и быстро.
Хочу отметить немаловажные отличия Mercurial от git, которые определяют мой выбор в пользу последнего:
— Производительность. git намного быстрее!
— Авторизация. Я использую Mercurial keyrings, этот способ, на мой взгляд, самый лучший среди возможных для Mercurial, но, тем не менее, он создает гораздо больше проблем, чем SSH-авторизация git.
Еще менее важное и наиболее субъективное отличие — интерфейс. По моему мнению, на котором я, повторюсь, не настаиваю, git более интуитивен и прост в использовании.
— Производительность. git намного быстрее!
— Авторизация. Я использую Mercurial keyrings, этот способ, на мой взгляд, самый лучший среди возможных для Mercurial, но, тем не менее, он создает гораздо больше проблем, чем SSH-авторизация git.
Еще менее важное и наиболее субъективное отличие — интерфейс. По моему мнению, на котором я, повторюсь, не настаиваю, git более интуитивен и прост в использовании.
Отличный антагонизм — коммерческий проект против библиотеки бинарный файлов, Кто победит?
А некоммерческий проект? А непрограммный проект, но из текстовых файлов?
> После слияния с веткой в Git мы рискуем получить гига-патч, в котором где-то будет скрываться ошибка
это вообще о чём? о мердже со squash? Так это не единственный метод, читаем хабр
Очень странные выводы.
А некоммерческий проект? А непрограммный проект, но из текстовых файлов?
> После слияния с веткой в Git мы рискуем получить гига-патч, в котором где-то будет скрываться ошибка
это вообще о чём? о мердже со squash? Так это не единственный метод, читаем хабр
Очень странные выводы.
Чем нравиттся hg — более лучшая поддержка в bash-competition При, например, вводе имен файлов в add/remove подставляются именно те файлы, которые могут быть добавлены удалены, а не всей кучей, что есть в репе.
Ничего тут сегодня чего занекропостили.
На самом деле ответ есть, он очень простой.
Вот, например, есть github, где лежит несколько миллиардов строк разного кода в открытом доступе для всех, иногда весьма неплохого. А hghub как-то не наблюдается. Ну и какая разница, что вам кажется лучше, а что хуже. Дома можно хоть на голове ходить. На работе уже выбирать особо не приходится!
На самом деле ответ есть, он очень простой.
Вот, например, есть github, где лежит несколько миллиардов строк разного кода в открытом доступе для всех, иногда весьма неплохого. А hghub как-то не наблюдается. Ну и какая разница, что вам кажется лучше, а что хуже. Дома можно хоть на голове ходить. На работе уже выбирать особо не приходится!
Сходство и различие между Mercurial и Git