Представлен (https://lkml.org/lkml/2015/7/27/891) релиз распределенной системы управления исходными текстами Git 2.5.0 (http://git-scm.com/). Git является одной из самых популярных, надёжных и высокопроизводительных систем управления версиями, предоставляющей гибкие средства нелинейной разработки, базирующиеся на ответвлении и слиянии веток. Для обеспечения целостности истории и устойчивости к изменениям задним числом используются неявное хеширование всей предыдущей истории в каждом коммите, также возможно удостоверение цифровыми подписями разработчиков отдельных тегов и коммитов. Из проектов, разрабатываемых с использованием Git, можно отметить ядро Linux (https://git.kernel.org/cgit/linux/kernel/git/stable/linux-st.../), Android (https://android.googlesource.com/), LibreOffice (http://cgit.freedesktop.org/libreoffice), Systemd (http://cgit.freedesktop.org/systemd), X.Org (http://cgit.freedesktop.org/xorg), Wayland (http://cgit.freedesktop.org/wayland), Mesa (http://cgit.freedesktop.org/mesa/), Gstreamer (http://cgit.freedesktop.org/gstreamer), Wine (http://source.winehq.org/git/wine.git), Debian (http://anonscm.debian.org/gitweb), DragonFly BSD (http://gitweb.dragonflybsd.org/?p=dragonfly.git;a=summary), Perl (http://perl5.git.perl.org/perl.git), Eclipse (http://git.eclipse.org), GNOME (http://git.gnome.org/browse/), KDE (https://projects.kde.org/projects), Qt (http://qt.gitorious.org/), Ruby on Rails (https://github.com/rails/rails), PostgreSQL (http://git.postgresql.org/gitweb/), VideoLAN (http://git.videolan.org), PHP (http://git.php.net/), Xen (http://xenbits.xen.org/gitweb/), Minix (http://git.minix3.org/).
По сравнению с прошлым выпуском в новую версию принято 583 изменений, подготовленных при участии 70 разработчиков, из которых 21 впервые приняли своё участие в разработке. В новом выпуске представлены в основном исправления ошибок и мелкие улучшения, значительные изменения отсутствуют. Основные изменения (http://git-blame.blogspot.com/2015/07/git-25.html):- Новое сокращение branch@{push}, обозначающее удалённую отслеживаемую ветку, в которую будут помещены push-операции;
- В команду "git send-email" добавлена поддержка файла /etc/aliases, используемого в sendmail;
- В низкоуровневые внешние драйверы обеспечения слияния данных от трёх источников, помимо имён трёх временных файлов (%O, %A и %B) теперь передаётся финальный путь (%P);
- Улучшена эвристика определения ошибок в определении путей в параметрах командной строки, что сняло ограничение на разделение опцией "--" похожих на имена файлов параметров в "git grep" (вместо "git grep строка -- *.c" теперь можно указывать "git grep строка *.c");
- В скриптах с фильтрами обеспечена возможность завершения работы с выводом ошибки до того, как будут получены все данные от Git (при записи игнорируется EPIPE);
- В "git diff" добавлена опция "--ws-error-highlight", подсвечивающая завершающие строку символы пробелов при отображении изменений;
<center><a href="http://i.stack.imgur.com/7eWG7.png"><img src="http://www.opennet.me/opennews/pics_base/0_1438088075.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></a></center>- Команда "git merge FETCH_HEAD" теперь учитывает, что ранее выполненный запрос "git fetch" может привести к множественному слиянию (Octopus merge) и избавляет от необходимости использования синтаксиса "git merge msg HEAD commits" в скриптах git pull;
- В "git cat-file --batch" добавлена опция "--follow-symlinks", допускающая обход символических ссылок при запросе объекта по хэшу SHA-1. Например, HEAD:RelNotes может быть ссылкой на Documentation/RelNotes/2.5.0.txt и при указании данной опции git удет считать, что на входе Documentation/RelNotes/2.5.0.txt вместо HEAD:RelNotes;- Представлена замена для скрипта contrib/workdir/git-new-workdir, не зависящая от символических ссылок и надёжно обеспечивающая совместное использование объектов и ссылок.
URL: https://lkml.org/lkml/2015/7/27/891
Новость: http://www.opennet.me/opennews/art.shtml?num=42679
Хоть бы слово про "упростили", а то все это консольное вырвиглазие просто невозможно использовать без слез. 80% хватило бы 20% функционала, только если бы доступ к нему был человеческий, а не через заднее место.Я думаю я не один такой, кто делает бекапы папки с джит перед выполнением сложных команд. Охрененно удобная система!
Прочитай уже Pro Git, наконец.
Тем более, что Pro Git выложена на официальном сайте git, и даже переведена там на русский язык https://git-scm.com/book/ru/v1
>Я думаю я не один такой, кто делает бекапы папки с джит перед выполнением сложных команд.Надеюсь, что один, так как испортить репоизторий можно только командой rm -rf .git, все остальное легко откатывается
... если знаешь магические слова
И да, на репозиторий насрать (его можно восстановить из другого), главное чтобы исходники не пострадали. А вот откатить случайное действие без перечитывания "Pro Git" реально под силу немногим.
>>Я думаю я не один такой, кто делает бекапы папки с джит перед выполнением сложных команд.
> Надеюсь, что один, так как испортить репоизторий можно только командой rm -rf
> .git, все остальное легко откатываетсяоткати мне rebase
> откати мне rebaseman git-reflog
DBA сертификаты по Git уже кто-то выдает или еще нет?
> DBA сертификаты по Git уже кто-то выдает или еще нет?угу, Git certified CCNA
CCNA - это дети в сетях.
man git-show-ref
>> .git, все остальное легко откатывается
> откати мне rebaseСам себе duckduckgo.com/?q=rebase+undo откати.
>>Я думаю я не один такой, кто делает бекапы папки с джит перед выполнением сложных команд.
> Надеюсь, что одинНу я порой бэкаплю перед сложными git rebase -i, чтоб не раскапывать потом git reflog.
А временную ветку создать перед ребейзом религия не позволяет?
> А временную ветку создать перед ребейзом религия не позволяет?до этого места ещё не дочитал, угу.
еще git clean -fdx нельзя откатить, пару раз так терял нужные файлики хоть и не сильно критичные
Джавы с джаваскриптом вам мало, так теперь ещё и джит? Болезнь-то прогрессирует...
Выпей гин с тоником
> Выпей гин с тоникомох лол.. Ок, сразу после того, как ты найдёшь в джугле, где его купить подешевле.
Ещё давай позовём джида (вместо гида), снимем пару джёрлс в сауну в джималаях и запишем джигабайты хоум-видео на эту тему. Мне продолжать?
> Мне продолжать?Напиши стихотворение и выложи на джитхуб.
gin, giraffe, giant, ginger - читается как "дж". Недавно узнал в комментах про произношение gif.Но это скорее ради хохмы ради, git официально считается гит http://english.stackexchange.com/questions/47622/how-do-you-... как презентовал сам Линас Торвальдс
Думаю, один.
> Хоть бы слово про "упростили",Уже давно https://www.kernel.org/pub/software/scm/git/docs/giteveryday... , документацию же читать надо.
Smoke git everyday
Ну так почитайте документацию по git. Там хорошо описаны многие моменты.
https://git-scm.com/book/ru/v1/Введение
Советую с самой первой главы.
А далее, чтобы упростить жизнь можете создавать скрипты. Например, можно сделать скрипт для создания ветки для новой версии, где будет происходить сразу
git checkout -b project-v1.x.x
и
git tag -a v1.x.x -m 'Версия 1.x.x'.Одинаковые аргументы, думаю, заметны. ;) К тому же скрипты уменьшат шансы ошибки из-за человеческого фактора.
> Я думаю я не один такой, кто делает бекапы папки с джит перед выполнением сложных команд. Охрененно удобная система!Если честно, я это делаю и в hg, и в svn. В svn вообще жесть после неудачного большого мержа, частично выполненного, частично провалившегося. Подозреваю, что какими-то хитрыми командами во всех VCS можно откатить даже сложные команды, но сделать копию тупо проще, чем их искать...
> Я думаю я не один такой, кто делает бекапы папки с джит перед выполнением сложных команд.Естественно не один, дураков вокруг достаточно. Кто папок с мамками бэкапит, кто даже название утилиты прочитать не может, куда там две строчки документации прочитать.
> Охрененно удобная система!
Метлу вам в руки. Там ничего бэкапить не надо.
> Метлу вам в руки. Там ничего бэкапить не надо.Как, а саму метлу?
Вас таких 95%. Правда остальные даже не знают, что такое Git и зачем он нужен. Они вообще в программирование не лезут.
Специально для вас: http://www.youtube.com/watch?v=hkBVAi3oKvo
> делает бекапы папки с джит перед выполнением сложных команд.Прочитайте наконец документацию по Git.
Может это поможет Вам не писать х..и и тратить рабочее время на бредовые вещи.
Не удобная, а универсальная.Для удобств есть gitk, gitg, smartgit (для нон коммершиал - бесплатный), и вообще https://git-scm.com/download/gui/linux
TortoiseGit под винду и оверхеад как рукой сняло!
Возможно, самый лучший гип для git *fix*
ой, только не это, оно через такую попу работает, как и все в винде
Если бы ещё под Винду актуальные версии Git были. А так на 1.9.5 сидим.
Ну хоть одна хорошая новость за сегодня!
> Ну хоть одна хорошая новость за сегодня!Ну, да... Как это здорово... Хоть у кого-то хуже чем у тебя
Кто-то пользуется виндой и страдает за свои убеждения!
Я бы пользовался и Linux, если бы была нормальная альтернатива Office и прежде всего Outlook. На прошлой работе сидел на Mint c Виндой в VirtualBox. Сейчас просто на Винде.
> Я бы пользовался и Linux, если бы
>c Виндой в VirtualBox. Сейчас просто на Винде.Чего только люди не учудят, чтобы не пользоваться Имаксом!!
>> Я бы пользовался и Linux, если бы
>>c Виндой в VirtualBox. Сейчас просто на Винде.
> Чего только люди не учудят, чтобы не пользоваться Имаксом!!А Имакс тут каким боком?
Ну как же так?
https://github.com/git-for-windows/git/releases
ага, почти stable
Вы, вендузятники, должны страдать.
к вопросу по GUI к git:
ничего ещё не появилось, что может нормально файлы перемещать/переименовывать с сохранением истории изменений?
давно всё появилось.
fossil forever
Там все просто, а если знаешь sql то легко решать проблемы с репозиторием
Для простых случаев - хорошо, когда легкои просто. Но Git настолько распространён, что не уметь его всё равно нельзя. А раз так - зачем возиться с лишней SCM, которая кроме простоты (в данном случае невостребованной) ничего предложить не может?Хотя такой, как у фоссила, гибрид проекта в git с вики, пожалуй, мог бы пригодиться по мелочи. Надо глянуть, наверняка кто-то уже сделал подобное.
На счёт не уметь гит согласен: куда не сунься, все на нём.Но я уже несколько проектов делаю на fossil, ещё не упёрся в отсутствие функционала. Какие там функции отсутствуют, которые нужны или которые есть в гите?
Там не только вики, там еще и пользователи и просмотр когда и багтрекер :-)
> Какие там функции отсутствуют, которые нужны или которые есть в гите?Например, rebase как он сделан в git. Без этой фичи (d)VCS совсем не нужна для работы с кодом.
вообще-то есть масса workflow, где rebase особо не используется. Самое простое - если задача делится на много простых фич/тасков, каждая живёт в своей ветке и merge --squash когда готова, после чего ветка убивается.
> вообще-то есть масса workflow, где rebase особо не используется.если кодить не ~ хеллоу ворлд, то таких workflow нет. Конечно, можно не пользоваться ребейзом и делать как-то иначе, но это от неопытности разработчика и/или из-за ограничения используемой VCS.
> Самое простое - если задача делится на много простых фич/тасков, каждая живёт в своей ветке и merge --squash когда готова
Цикл разработки почти всегда делится на мелкие задачи, но это деление в основном последовательное, а не паралельное. Т.е. нельзя насоздавать сразу N веток и пилить в них одновременно несколько мелких задач. Тут можно развести много бла-бла-бда на тему тщательного планирования и поэтапного выполнения работы, но это невозможно для сколь- нибудь сложного проекта. И это тупо неудобно.
Если ребейзом не пользоваться, то реп сразу же становится помойкой из комитов с коментами типа "fix", а если часто налегать squash, то в сборище беспощадных и бессмысленных мегакоммитов. В общем, во всех вариантах без ребейза реп превращается в тупой инкрементальный бэкап.
Там есть приватные ветки. Они только на один репозиторий. Их тоже можно запулить в другой, только нужно указать спкцом, что ты этого хочешь.По мне, так если знаешь sql, то в fossil rebase не нужен: delete все знаменит. А можно просто голову создать, потом закрыть и все, они останутся в истории, будут выглядеть как ветка, только без имени
На fossil он сам и sqlite
> По мне, так если знаешь sql, то в fossil rebase не нужен: delete все знаменит.Интересно, это как? Вот, есть, например, два последовательных коммита A и B над одним куском кода. Комит B перемещает редактируемый кусок кода в другой файл + делает некоторые изменения. Хочу ребейзом поменять их местами. git rebase умеет разруливать такие ситуации, в разумных пределах, без конфликтов (см. three-way merge, patch commutation и т.п.), а через тупой delete + add такого ну никак не сделаешь.
По-моему, ты совсем упоролся. Даже если знать хорошо SQL, то всю эту детерминированную машинерию скорее всего не сделаешь никогда. Ты бы ещё посоветовал сразу всё хранить в файликах и руками с ними работать. Ну если, конечно, хорошо знаешь bash, sed и awk.
Разумеется, в основном последовательное деление - но какая разница? Главное, чтобы фичи были достаточно небольшими, не первращаясь в монстров при squash - ну так оно при скраме так или иначе полезно. И зачем в каждой ветке пилить несколько задач? Одна задача - одна ветка - один коммит в дев-ветке в итоге. Я, собственно, так работал в весьма немаленьком проекте (скажем так - миллионы строк). Сам, правда, rebase гонял в хвост и в гриву - но ровно потому, что имею привычку коммитить на любой чих с абсолютно бессмысленными мессаджами - просто для своего удобства, как замена stash, а уже потом выгребать из этого нужное. Коллеги без него обходились и обходятся.
> имею привычку коммитить на любой чих с абсолютно бессмысленными мессаджами -
> просто для своего удобства, как замена stash, а уже потом выгребать
> из этого нужное.о, брателло! а то я думал, я один такой.
> Одна задача - одна ветка - один коммит в дев-ветке в итоге .. Я, собственно, так работал в весьма немаленьком проекте (скажем так - миллионы строк)Такое в разработке проекта на несколько М SLOCов бывает почти никогда, одна фича крайне редко состоит из одной задачи. Типичный цикл разработки содержит следующие типы мелких задач: рефакторинг уже имеющегося кода (в проектах хотя бы от 10К SLOC без этого уже никак), реализация какой-либо отсутствующей функциональности (в библиотеках, в ядре сервиса и т.п.) и, собственно, реализация самой фичи. Это уже минимум три задачи в каких-то простых случаях, причём все они пилятся хронологически одновременно, но логически последовательно.
> Коллеги без него обходились и обходятся.
Ну это не удивительно, сейчас культуре разработке мало где удиляют внимание и, как следствие, мало айти инженеров умеет работать с VCS выше уровня бэкапов или CVS. Хотя уже можно часто встретить требование отделять рефакторинг от создания новых сущностей и функционала.
Вы все поступаете неправильно: твои коллеги, видимо, засирают реп мусорными мелкими бессмысленными коммитами, а ты засираешь мегапатчами (да, я не верю что тебе приходится действительно пилить мало кода для фичи). В итоге ваш реп почти бесполезен в плане истории разработки, ибо...
* нельзя легко понять на чём именно что-то сломалось, т.к. локализация проблемы до гранулярности целой фичи совсем не прикольна, а до мусорного коммита малоинформативна;
* в обоих случаях не понятно что разработчику пришлось интересного сделать во время реализации. Это затрудняет ревью работы и коммуникацию внутри команды и между;
* нельзя легко портировать часть работы в другие ветки;
* пользоваться blame'ом становится трудно, из-за всего выше написанного.
Я имею в виду, что гит всё равно знать приходится. А когда его знаешь уже нет необходимости в "чём-то попроще" - он, в общем, не сложен, просто кривая освоения крутовата.Что до пользователей и багтрекера - оно по факту настолько минималистично, что если понадобились пользователи - значит, нужно что-то покрупнее. А для себя вместо багтрекера и файлика .org внутри репы хватает. А вот вики в комплекте - удобно, чтобы всякие нюансы проекта фиксировать даже когда полноценное что-то поднимать лень. Хотя если есть дисциплина и желание - можно всё в доксигене держать, даже красивее выходит.
Так вот fossil и есть покрупнее. Например если над проектом работают четыре человека, то как пользователей держать? Я у себя на vps запустил сервер fossil сделал перенаправление на его порт с определённого адреса в ngnix и все, теперь, если я хочу новый репозиторий создать, с пользователям и всеми наворотами, то просто создаю там его файлик и все. Получается полноценный сайт проекта за три минуты (пока дизайн выберешь и я его немного кастомизирую иногда).Или, например, маленький проект для офиса. Просто запускаешь сервер на своём пк и к тебе могут заходить по ip писать баги и вики - какие-нибудь пояснения...
А с доксигн - это уже настраивать надо... К тому же если написать очень много код не видно :-) меня это в нём раздражает. Маленькая функция, а доков больше чем кода...
Особенно если хочешь чтобы на двух языках :-)Кстати, на мой взгляд, единственное что я бы хотел видеть ещё в fossil - интернационализация. Но, похоже, автор со мной не согласен, мол надо разработку вести только на одном языке, а не на пяти :-)
Вот насчёт интеранционализации я полностью с автором фоссила согласен. Впрочем, я вообще люблю минимизировать количество сущностей (и поэтому предпочитаю не связываться с fossil, зная git). Если человек занимается IT - то английский он знать обречён, а раз так - нечего лишний раз раскладки дрёгать и пытаться тащить русскоязычные кальки с терминов.А насчёт проектов - я верю, что бывают проекты "на один раз", но я видел только два варианта - либо есть один разработчик, либо какая-то организация/команда. В первом случае в трекере и пользователях смысла нет, а во втором один хрен нужно поднимать инфраструктуру, в которой потом только проекты новые заводят. Тут фоссил как раз не очень, так как в нём все проекты получатся совершенно изолированными, в то время как тот же гитлаб или мантис позволит нормально держать взаимосвязи.
Насчёт офиса - ок, но там непонятно, зачем к этим вики и трекеру VCS :-) Кроме того, для неподготовленного народу оно очень уж аскетичное - даже картинку не вставишь, если не ошибаюсь. Ну и всякие "просто поднимаешь на своём ПК" порождает в перспективе слишком много мороки - либо оно не поднялось когда надо, либо вырубил кто-то машину... Вещи общего пользования должны быть на местном сервере или, на худой конец, где-то на VPS или в облаке. Хотя, конечно, иногда народ копейки экономит - но я бы скорее таких послал.
Доксиген один хрен в серьёзном проекте настраивать надо - ну хотя бы ради того, чтобы код документировался и это каким-то инструментом проверялось. И там он удобен тем, что текстовая болтовня хорошо увязывается с кодом - ссылки и т. п. И я не имел в виду, что большие объёмы текста надо совать в исходники - делаешь отдельные файлы да ссылки на них в содержании. Мороки больше, чем с вики, но результат лучше. Это на чём-то объёмном заметно скорее, когда в голову весь код уже даже близко не помещается, и максимум, что можно объяснить новичку - общую архитектуру.
ну чего спорите‐то? фоссил — не гит, и не задумывался, как замена гита же. у фоссила есть зато уберфича, которой у гита нет: он весь состоит из одного бинаря, а репозиторий — из одной sqlite-базы. бывают ситуации, когда это может быть нужно.а в остальном — dvcs как dvcs.
2fleonis: в гите тоже можно без проблем рулить низкоуровневым хранилищем — садись да делай свои замены commit, rebase и прочих, если хочется. в смысле — все «кирпичи», из которых высокоуровневые команды построены, спокойно доступны в командной строке.
> ну чего спорите‐то?Да, чего-то я... Хватит opennet заси****
> фоссил — не гит, и не задумывался, как замена
> гита же. у фоссила есть зато уберфича, которой у гита нет:
> он весь состоит из одного бинаря, а репозиторий — из одной
> sqlite-базы. бывают ситуации, когда это может быть нужно.Это кстати круто :-)
> 2fleonis: в гите тоже можно без проблем рулить низкоуровневым хранилищем — садись
> да делай свои замены commit, rebase и прочих, если хочется. в
> смысле — все «кирпичи», из которых высокоуровневые команды построены,
> спокойно доступны в командной строке.Хм.. Я не вникал в содержимое каталога .git , но где-то читал что его лучше не трогать :-)
> Хм.. Я не вникал в содержимое каталога .git , но где-то читал
> что его лучше не трогать :-)а его и не надо трогать, git имеет низкоуровневые команды для манипуляций с базой. по сути, .git/ — это такое key-value хранилище. как оно там внутри реализовано — не так уж важно, потому что команды для манипуляции ключами и значениями есть прямо в коробке. понимать, конечно, что и как гит хранит, всё ещё надо. сами же вещи типа git init, git commit и прочие как раз используют доступные низкоуровневые команды, а не лазят в хранилище руками.
> Вот насчёт интеранционализации я полностью с автором фоссила согласен.Сам сначала хотел ему написать, потом подумал и не стал, действительно не нужно разработку вести на нескольких языках. Он кстати специально не запилил любое изменение истории. Можно только комнтарий подправить, но старая версия все равно будет доступна.
> А насчёт проектов - я верю, что бывают проекты "на один раз",
> но я видел только два варианта - либо есть один разработчик,
> либо какая-то организация/команда. В первом случае в трекере и пользователях смысла
> нет,Есть: для себя :-) если нужно быстро сделать, то нормальные доки писать некогда да и лень.а вот вики - самое то, когда нужно будет вернуться что-то поправить, то можно быстро вспомнить.
> а во втором один хрен нужно поднимать инфраструктуру, в которой
> потом только проекты новые заводят. Тут фоссил как раз не очень,
> так как в нём все проекты получатся совершенно изолированными, в то
> время как тот же гитлаб или мантис позволит нормально держать взаимосвязи.Какая взаимосвязь? Субрепы? Они есть, а вот такого колва народу как на гитхабе, конечно нет :-(
> Насчёт офиса - ок, но там непонятно, зачем к этим вики и
> трекеру VCS :-) Кроме того, для неподготовленного народу оно очень уж
> аскетичное - даже картинку не вставишь, если не ошибаюсь. Ну иНу.. Я сайт делал, там нужна была админка специфическая. Где народу описать как пользоваться? Вот пригодилось :-) а картинки можно вставлять.
Кстати, когда последний сайт делал, заказчик, чуть-чуть разбирался в программировании. Попросил посмотреть :-) я ему ссылку кинул, пользователя создал, показал файла с переменными lesscss :-) он некоторые цвета сам подправил на сайте :-)
> всякие "просто поднимаешь на своём ПК" порождает в перспективе слишком много
> мороки - либо оно не поднялось когда надо, либо вырубил кто-то
> машину... Вещи общего пользования должны быть на местном сервере или, на
> худой конец, где-то на VPS или в облаке.Ага, я один раз в облаке настроил, теперь там даже маленькие проекты делаю.
Ну, в офисе, как правило, есть свой такой сервер... Он у нас музыку раздаёт :-) там чувак сидит, который ее качает :-) ну и если чего по ssh можно зайти :-)> Доксиген один хрен в серьёзном проекте настраивать надо - ну хотя бы
> ради того, чтобы код документировался и это каким-то инструментом проверялось. И
> там он удобен тем, что текстовая болтовня хорошо увязывается с кодом
> - ссылки и т. п. И я не имел в виду,
> что большие объёмы текста надо совать в исходники - делаешь отдельные
> файлы да ссылки на них в содержании. Мороки больше, чем с
> вики, но результат лучше. Это на чём-то объёмном заметно скорее, когда
> в голову весь код уже даже близко не помещается, и максимум,
> что можно объяснить новичку - общую архитектуру.Да, кстати, надо по лучше присмотреться к ссылкам. Да, там удобно диаграммы.
У меня есть обычно файлик, или, если на fossil - wiki, где я пишу цели проекта и roadmap. Мне хватает обычного перечисления, так что не использую специальную систему. Такое в доксиген делать наверное не удобно: если откатишь дерево, то и этот файл тоже уйдет. Я когда с таким файлом работаю и мне нужно полазить по истории, открыватю его,а потом лазию :-)
Во! Дельную штуку добавили ещё: https://git-scm.com/docs/git-worktree
Теперь можно как в SVN нормально работать параллельно в с несколькими ветками большого репозитория, без необходимости выкачивать его несколько раз из bare
А зачем его несколько раз выкачивать? Склонируй выкачанный, оно по умолчанию ещё и хардлинками всё сделает. разве что origin придётся подправить в клонах. А постоянно прыгать между деревьями... не, ну тоже вариант, конечно, но, например, IDE спасибо не скажет, make тоже.
> А зачем его несколько раз выкачивать?прёт его, видимо.
> Надеюсь, что один, так как испортить репоизторий можно только командой rm -rf .git, все остальное легко откатываетсязначит вам очень круто повезло. А вот push с --force не такая веселая штука. И потом узнавать из n разрабов а у кого же самая свежая версия и все собирать до кучи - не так весело.
Советую прочитать для общего развития - http://stevebennett.me/2012/02/24/10-things-i-hate-about-git/
> значит вам очень круто повезло. А вот push с --force не такая
> веселая штука. И потом узнавать из n разрабов а у кого
> же самая свежая версия и все собирать до кучи - не
> так весело.а ещё можно мошонку гвоздями к доске прибить. виноваты будут, понятно, гвозди и молоток.
>> значит вам очень круто повезло. А вот push с --force не такая
>> веселая штука. И потом узнавать из n разрабов а у кого
>> же самая свежая версия и все собирать до кучи - не
>> так весело.
> а ещё можно мошонку гвоздями к доске прибить. виноваты будут, понятно, гвозди
> и молоток.команда есть и она "опасная". Или вы потом скажите, так виноват Вася, что не прочитал 600 страниц pro git ;) Но всегда виноват админ :D Порог вхождения у git по сравнению с svn/hg намного больше и отрицать это глупо
> команда есть и она "опасная". Или вы потом скажите, так виноват Вася,
> что не прочитал 600 страниц pro git ;)откуда дебил‐вася узнал о «--force» вообще? тупо скопировал из интернетов, не пытаясь понять? молодец вася, он дважды дебил. или таки заглянул в документацию — и не прочитал предупреждения? трижды дебил.
от дебилов защиты не существует, дебилы очень изобретательны в своём дебилизме. любая попытка «защититься» от дебила дебилом с лёгкостью обходится, а нормальным людям доставляет массу неудобств.
>> команда есть и она "опасная". Или вы потом скажите, так виноват Вася,
>> что не прочитал 600 страниц pro git ;)
> откуда дебил‐вася узнал о «--force» вообще? тупо скопировал из интернетов,
> не пытаясь понять? молодец вася, он дважды дебил. или таки заглянул
> в документацию — и не прочитал предупреждения? трижды дебил.
> от дебилов защиты не существует, дебилы очень изобретательны в своём дебилизме. любая
> попытка «защититься» от дебила дебилом с лёгкостью обходится, а нормальным людям
> доставляет массу неудобств.какая разница откуда он узнал, твоя задача быстро все исправить, а не с пеной у рта кричать, что это Вася дебил и что он не прочитал n страниц мануала. Документация в git то еще удовольствие :D
> какая разница откуда он узнал, твоя задача быстро все исправитьнет, у меня не было такой задачи. у меня была задача уволить дебила, который не умеет читать, и дебила, который взял такого дебила на работу. я доступно излагаю?
