Представлен (https://lkml.org/lkml/2015/4/30/754) релиз распределенной системы управления исходными текстами Git 2.4.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/).
По сравнению с прошлым выпуском в новую версию принято 426 изменений, подготовленных при участии 76 разработчиков, из которых 25 впервые приняли своё участие в разработке. В новом выпуске представлены в основном исправления ошибок и мелкие улучшения, значительные изменения отсутствуют. Основные изменения (https://github.com/blog/1994-git-2-4-atomic-pushes-push-to-d...):
- Поддержка атомарных операций "git push", применение которых активируется опцией "--atomic". Атомарный push полезен при необходимости отправки сразу нескольких веток на внешний сервер. В обычных условиях часть обновлений может пройти нормально, но некоторые обновления могут не пройти, например, когда другой разработчик отправил в тот же репозиторий свою ветку. В этом случае потребуется откорректировать вносимые изменения в соответствие с кодом, который успел отправить другой разработчик.
Опция "--atomic" даёт возможность отправить несколько веток атомарно как единое целое, так что либо все из перечисленных веток будут приняты, либо все отвергнуты. Например: "git push --atomic origin branch1 branch2". Подобное поведение особенно востребовано в автоматизированных системах непрерывной интеграции - после добавления очередной порции изменений, если проверка прошла успешно, прошедшая тестирование ветка с изменениями переливается в ветку master, создаётся новый тег и примечание к коммиту. Все эти три шага теперь можно выполнить атомарно с гарантией того, что все они будут выполнены: "git push --atomic origin master refs/tags/release-17 refs/notes/test-results".- Улучшены средства развёртывания кода командой push (Push-to-deploy), которые часто применяются web-разработчиками для размещения новой версии своего проекта на сервере.
- Реализован перехватывающий вызов push-to-checkout, который может быть установлен на сервере для задания собственного поведения в ситуации выполнения операции push для ветки после checked-out. По умолчанию если на сервере в рабочем дереве уже были изменения при выполнении подобной push-операции выводится ошибка. Установка своего обработчика позволяет попытаться выполнить слияние нового содержимого ветки с другими редакциями ветки на стороне сервера или принудительно заменить локальные изменения изначальным содержимым ветки.
- Реализована возможность выполнения Push-to-deploy для только что инициализированного пустого репозитория на сервере, на котором ещё не было коммитов (в обычных условиях операция push в пустой репозиторий не работала корректно).
- Релизация инвертированного поиска по логам. Для фильтрации вывода команды "git log" доступны такие команды, как "--grep", "--author", "--committer", "--grep-reflog", которые позволяют достаточно точно отсеять соответствующие маске записи в логе коммитов. Новая опция "--invert-grep" позволяет вывести только то, то не попало под заданную маску. Например, для вывода записей в которых отсутствует аннотация "Fixes": "git log --all --merges --invert-grep --grep=Fixes";- В команде "git log" пока нет возможности комбинировании опций выборки по маске в произвольные выражения, например, "соответствует А и Б, но не В". Но благодаря опции "--invert-grep" подобные выражения теперь можно симулировать через конвейерную обработку результатов нескольких команд "git log". Например, если нужно найти не приведшие к слияниям коммиты в ветке master, выполненные Иваном Ивановым, для которых не указаны строки "Signed-off-by":
<font color="#461b7e">
git rev-list --no-merges --author="Junio C Hamano" master |
git log --stdin --no-walk --invert-grep --grep='^Signed-off-by:'
</font>
Чтобы дополнительно исключить из вывода отменённые коммиты и посчитать сколько коммитов осталось:
<font color="#461b7e">
$ git rev-list --no-merges --author="Junio C Hamano" master |
git rev-list --stdin --no-walk --invert-grep --grep='^Signed-off-by:' |
git rev-list --stdin --no-walk --invert-grep --grep='^Revert ' |
wc -l</font>
- В команду "git status" добавлена возможность указания опции "--verbose" дважды. В этой ситуации будут показаны данные не только по коммитам, но и по изменениям, ожидающим коммита;
- Команда "git log --decorate", при которой помимо обычных данных из лога показываются связанные с ними имена веток, теперь выводит информацию не только о текущей ветке HEAD, но о том, на какую ветку она ссылается (HEAD -> master);
- Новый параметр конфигурации push.followTags, включающие по умолчанию применение опции "--follow-tags" в команде "git push";
- В транспорте на базе HTTP при запросах реализована отправка заголовка Accept-Language, что позволяет организовать вывод сообщений сервера на языке, отличном от английского.URL: https://lkml.org/lkml/2015/4/30/754
Новость: http://www.opennet.me/opennews/art.shtml?num=42145
Когда же эта пса будет под винды?
http://git-scm.com/download/win ?
Там же 1.9.5
есть же? про версию речь не шла в предыдущем сообщении)
вот тут есть 2.3.7: https://github.com/git-for-windows/git2.4 появится там скоро.
прошлая репа, в которой они вели развитие 1.9, больше обновлляться не будет, они её скоро задепрекейтят в пользу той, на которую даю ссылку.
Ну какому девелоперу сейчас нужна винда? Поставь её на виртуалку, в конце концов, и расшарь папку с хост-системой. Тогда гиту будет всё доступно.
кстати, несколько лет назад была тенденция: гит под виндой очень тормозил.а вот если запустить виртуалку с линуксом и запускать гит и емакс оттуда -- почему-то не тормозил.
исходники есть. когда соберёшь, тогда и будет.
Чем оно лучше subversion?
Всем.
Аналог "svn co subdir" без костыляний и скачивания всей репы уже есть?
> Аналог "svn co subdir" без костыляний и скачивания всей репы уже есть?Есть, с версии 1.7 аж. Называется sparse checkout.
> Есть, с версии 1.7 аж. Называется sparse checkout.Еще раз, для загугливших, но неосиливших - без костыляния или хотя бы без скачивания всей репы.
Вы уж определитесь: Вам VCS или файлопомойку нужно. В данном случае --- прежде всего VCS, хотя, если приложить голову и руки из git можно сотворить и довольно эффективную файлопомойку. А если хочется файлопомойку "из коробки", то ищите что-то другое.
>svn co subdirНе надо так делать, для независимых частей есть submodule.
>без скачивания всей репы
Интернет по карточкам?
> Не надо так делать,т.е. нельзя? А как же тогда
>> чем лучше?
> всем?
> Интернет по карточкам?
Угу, качать в серьезных проектах от пары сотен мб до нескольких гигов, чтобы посмотреть (или даже собрать - если достаточно самодостаточный) плагин или модуль на пару сотен кб - обалдеть! Хорошо, если сервер резвый и интернет быстрый - а если нет?
git clone --depth 1 URL
далее http://stackoverflow.com/questions/180052/checkout-subdirect...Если совсем туго - смотреть через Web-интерфейс.
> git clone --depth 1 URL
> далее http://stackoverflow.com/questions/180052/checkout-subdirect...Угу, и там же сразу:
> Note that sparse checkouts still require you to download the whole repository, even though some of the files Git downloads won't end up in your working tree.
> Если совсем туго - смотреть через Web-интерфейс.Только и остается.
"--depth 1" - это же не весь репозиторий. Только одна ревизия. Хоть и все файлы этой ревизии, да.
> Интернет по карточкам?Гиговые файлы в репозитории.
Git-annex
как в свн удалить коммит, объеденить два в один и несколько поменять местами?
> как в свн удалить коммит, объеденить два в один и несколько поменять
> местами?Еще один не-читатель? Или "Наших бьют! ГитЪ обижають!!"
Речь как бы шла о "чем это лучше svn? - Фсем!!!"
Оказывается - не всем.
Никто не говорил, что svn - верх совершенста, но именно вот эта фича - реально удобно, когда хочется глянуть какую-то часть большого проекта.
> фича - реально удобно, когда хочется глянуть какую-то часть большого проекта.Если что, git в дефолтном виде - удобен для именно разработчиков, а не всяких "посмотреть и унести в нору".
> Если что, git в дефолтном виде - удобен для именно разработчиков, аЧто месье диванный оналитег (который очевидно не в курсе, что случаи разные бывают, а "быстрые интырьнеты" доступны далеко не везде) сказать-то хотел?
> не всяких "посмотреть и унести в нору".А, понятно. Опять несем бред и тешим ЧСВ?
> Что месье диванный оналитег (который очевидно не в курсе, что случаи разные
> бывают, а "быстрые интырьнеты" доступны далеко не везде) сказать-то хотел?Ну, знаешь, я линуксный кернел ради лулзов синкал даже по GPRS. Ну разумеется начальная скачка сделана на быстром канале - раз в жизни это можно себе позволить. А потом дельты достаточно мелкие, несколько мегов всего. Это даже диалапом и жпрс можно укачать.
Зато примерно гиг барахлишка (примерно столько же весят распакованные исходники и сборочное добро) - позволяет мотаться по ВСЕМ ВЕРСИЯМ, от лохматых 2.6 до 4.1-rc1 "All Hail T-800". Со скоростью ракеты. И без перекачки полпроекта на каждую отмотанную версию. Вот это как раз именно то чего я и ожидаю от СИСТЕМЫ КОНТРОЛЯ ВЕРСИЙ.
> А, понятно. Опять несем бред и тешим ЧСВ?Всего лишь называем вещи своими именами. Git удобен разработчикам, а не кому-нибудь еще. Для участия в разработке проекта, используюшего git. Вроде вполне логичная расстановка приоритетов для системы контроля версий. Поэтому с точки зрения желающих присоединиться к проекту, использование проектом git - большой плюс. А все остальные в общем то могут идти лесом с интересом, ублажать их просто не имеет смысла.
через ж0пу, но вполне можно. Сейчас как раз этим и занимаюсь - перелопачиванием истории Subversion для миграции в TFS. Поскольку утилита миграции обламывается на некоторых возможностях Subversion приходится править историю.И ничего, пока всё идёт нормально. Причём народ паралельно комитит в тот же репозиторий. В гите бы так не вышло, между протчим.
Правится svn дамп с помощью SvnDump package (http://svn.borg.ch/svndumptool)
> приходится править историю.
> И ничего, пока всё идёт нормально. Причём народ паралельно комитит в тот
> же репозиторий. В гите бы так не вышло, между протчим.С гитом не пришлось бы править историю.
> С гитом не пришлось бы править историю.Ты уверен что TFS мигратор поддерживает все возможности GIT-а? Или так, абы ляпнуть?
Можно без Интернета работать, предварительно скачав себе репу.
Шёл 2015 год...
Оно не лучше и не хуже. Оно другое.git - децентрализованная VCS. Главная особенность - децентрализация. Тебе не нужно иметь постоянный доступ к репозиторию чтобы коммитить, откатываться и т. п. То есть считай что твоя локальная копия и есть репозиторий. За счет этого получается как бы быстрее. Отсюда и минусы. Сложнее, особенно поначалу как с этим сталкиваешься: checkout vs. clone, commit vs. push и т. п. Учитывая что у тебя как бы локальный репозиторий - занимает больше места локально. А если у тебя есть бинарные объекты - так вообще раздувается. Опять же нет некоторых фишек, которые требуют централизации, например, блокировок (lock).
svn - централизованная VCS. И ее главный минус - для работы с версиями требуется постоянный коннект с репозиторием, скорость работы зависит от скорости канал и самого репозитория. Но на этом ее недостатки заканчиваются. Она проще, особенно для новичков, локально использует меньше места, есть блокировки т. п.
Если бы я выбирал CVS, я бы руководствовался 3 критериями:
1 Могу ли я жить без фишек именно svn типа блокировок?
2 Есть ли у меня проблемы с организацией постоянного доступа к репозиторию?
3 Буду ли я выкладывать на github?И выбирал бы git если 1=да и (2=да либо 3=да). Иначе выбирал бы svn. ИМХО.
http://stackoverflow.com/questions/871/why-is-git-better-tha...
Грош цена этой простоте. Потому что всё равно придётся осваивать гит, так как он везде. Лучше уж сделать это сразу и вовсю пользоваться его возможностями. И, соответственно, основной недостаток SVN - просто то, что она не git, а какая-то дополнительная сущность со своими правилами и заморочками, которую надо дополнительно осваивать. Даже если в каких-то workflow у него есть преимущества (а это, кстати, исключительная редкость - например, вместо блокировок проще ветки плодить и иметь кого-то одного с правом мержа в главную) - организационно рано или позно оказывается, что выгоднее перейти на повсеместно используемый git.
> Грош цена этой простоте. Потому что всё равно придётся осваивать гит, так как он везде.Навязанная свобода (tm) и её агрессивные адепты :)
Тебя опять накормили твоими аргументами в треде про бзд?
> Навязанная свобода (tm) и её агрессивные адепты :)Свобода одного кончается там где начинается свобода другого.
Вот в случае VCS ты свободен пользоваться чем хочешь, но есть шанс что в результате ты будешь взаимодействовать только сам с собой, ну или с кучей необучаемого балласта, что далеко не самые лучшие варианты развития событий на свете.
> вместо блокировок проще ветки плодить и иметь кого-то одного с правом мержа
> в главнуюТут через пул-реквесты можно еще интереснее сделать (добавить всю команду в тех, кто апрувит). Так сказать "принятие кода командным консенсусом". Для распределенных команд может быть весьма полезно!
>> вместо блокировок проще ветки плодить и иметь кого-то одного с правом мержа
>> в главную
> Тут через пул-реквесты можно еще интереснее сделать (добавить всю команду в тех,
> кто апрувит). Так сказать "принятие кода командным консенсусом". Для распределенных команд
> может быть весьма полезно!Ещё интереснее будет, когда настанет время мержить бинарники.
Про используемое место -- вброс или жутко устарелая информация.
git очень хорошо жмёт и частенько вся история по всем когда-либо сделанным коммитам жрёт меньше чем один полный checkout из svn.Вот здесь, например
http://nullprogram.com/blog/2009/02/12/
чувак говорит что svn-checkout ревизии 15574 игры freeciv занял 281Mb.
В гите полная история со _всеми_ 15 тысячью коммитами заняла 225Mb.Похожие цифры ещё в проекте "Lazarus" слышал.
Сам не сравнивал, если честно, ибо у гита есть достоинства которые [для меня] важнее чем объём.
svn для малой группы айтишников, а git для большой, которая активно коммитит.
> svn для малой группы айтишников, а git для большой, которая активно коммитит.И для малой группы разработчиков гит через ГитХаб с возможностью КонтиниусИнтегрейш через, например Travis-CI, с автодеплоем на АмазонАВС... может быть красивым решением!
Пока ещё не лучше но уже догоняет...> Опция "--atomic" даёт возможность отправить несколько веток атомарно как единое целое, так что либо все из перечисленных веток будут приняты, либо все отвергнуты.
Профит !
Например:
* возможностью форкнуть проект и вообще мыслить в режиме форка
* гарантия что ничего не пропадёт даже если по каким-либо причинам основной сервер ёкнется
* скорость. Не обязателен доступ до инета.
* возможность создавать легковесные бранчи, ребейзить, мерджить, diff-ать и т.д.
* github/gitlab, которые стали возможны благодаря другим перечисляемым пунктам.
...она лучше гитом.
Что лучше -- мопед или байк?...
hg (Mercurial) всё равно лучше и легче в обращении. А главное — надёжно.
А был бы на яве - цены бы не было.
Нет его на яве, потому он очень ценный.
То-то никто не пользуется этой питоноподелкой с ограничениями для домохозяек.
> hg (Mercurial) всё равно лучше и легче в обращении. А главное — надёжно.Главное почаще повторять эти виндузоидные мантры.
жаль только, что на Python3 его никак не перепишут..
> жаль только, что на Python3 его никак не перепишут..4ый питон сделает ртуть ещё питательнее и полезнее!
лучше бы сделали человеческую команду для просмотра log одновременно мастера и сабмодуля,
а то через пеньколоду составными командам приходится запускать
Сборка под Windows будет?
> Сборка под Windows будет?конечно. исходники есть, компилятор доступен. собирай.
А когда будет поддержка GIT флаг "--xml"?
Что нового в Mercurial 3.4: http://mercurial.selenic.com/wiki/WhatsNew#Mercurial_3.4_.28...
> Что нового в Mercurial 3.4: http://mercurial.selenic.com/wiki/WhatsNew#Mercurial_3.4_.28...Изя, я как всегда плюсанул тебе прямо в карму !