Доступен (https://lkml.org/lkml/2013/3/13/455) релиз распределенной системы управления исходными текстами Git 1.8.2 (http://git-scm.com/). Git является одной из самых эффективных, надёжных и высокопроизводительных систем управления версиями, предоставляющей гибкие средства нелинейной разработки, базирующиеся на ответвлении и слиянии веток. Для обеспечения целостности истории и устойчивости к изменениям задним числом используются криптографические методы, также возможна привязка цифровых подписей разработчиков к тегам и коммитам. Из проектов, разрабатываемых с использованием Git, можно отметить ядро Linux (http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6...), 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/).Из изменений в Git 1.8.2 можно отметить:
- Начальная поддержка платформ QNX и z/OS UNIX System Services;
- Добавлена подсветка вывода результатов выполнения тестов: зелёным помечены пройденные без ошибок тесты, красным - тесты при выполнении которых возникли проблемы, желтым - выполнение которых вызывает вопросы, синим - информативные результаты;- Проведена унификация наименований в документации. Для продукта и связанных с ним технологий рекомендуется использовать имя Git. В контексте выполнения конкретных команд указывается git. Имя GIT не рекомендовано для использования;
- Дополнительный скрипт (contrib/completion), применяемый в системе автодополнения для предложения вариантов часто используемых путей, модифицирован для более точного соответствия предложений особенностям тех или иных команд (например для "git add" не предлагаются немодифицированные пути);
- При задании шаблона в файлах .gitignore и .gitattributes теперь допустимо использовать маску "**/" для допустимости нулевого и более высокого уровня вложенности поддиректории. Т.е. "foo/**/bar" сработает как при наличии bar в директории foo так и если bar находится в поддиректории директории foo;
- Разделитель аргументов и путей в командной строке "--" теперь не обязательно использовать для маски пути ":/", например, вместо "git cmd -- :/" можно указать "git cmd :/".
- В "git blame" и "git diff" добавлена поддержка опции "--no-follow";
- Для помощи в отладке файлов .gitignore добавлена новая команда "git check-ignore";
- Команда "git cherry-pick" теперь может применяться для повтора корневого коммита для несозданной ветки;
- В конфигурацию добавлены переменные commit.cleanup = 'whitespace' и setting diff.algorithm для использования опции --cleanup=whitespace в "git commit" и выбора нестандартного алгоритма для команды "git diff";- В команду "git format-patch" добавлена опция "-v $count", при указании которой к именам файлов с сохраняемыми патчами добавляется строка "v$count-" и в файлах используется префикс "PATCH v$count", что позволяет сохранять патчи под разными именами;
- В команды, подобные "git log", добавлена опция "--use-mailmap" для перезаписи имён и адресов в соответствии с механизмом mailmap;
- При указании "git log --cc --graph" теперь отображается вывод отличий, комбинированный с графом предков;
- В "git mergetool" и "git difftool" обеспечен вывод списка доступных бэкендов в более непротиворечивой форме;
- Для обновления тега через "git push" теперь нужно всегда указывать опцию "-f" (--force);
- Обновлена реализация команды "git fast-export", которую теперь допустимо использовать в контексте интерфейса внешних хелперов;
- В директорию contrib/ добавлен внешний хэлпер для взаимодействия с репозиториями bzr;
- В реализацию "git p4" внесена большая порция исправлений, связанных с обработкой веток. Обеспечена поддержка использования с Python 2.4/2.5 и решены проблемы с совместимостью с окружением Cygwin;
- В "git fsck" добавлена проверка на наличие в дереве объектов, которых там быть не должно (например, ".", ".git" и "..");
- Проведена оптимизация кода сопоставления путей, содержащих маски;
- Переработана и ускорена реализация команды "git reset";
- Обновлена реализация команды "imap-send", в которой задействован уже используемый в команде http-push код квотинга XML;- Добавлена возможность сборки с опцией USE_WILDMATCH=YesPlease, активирующей альтернативную реализацию логики сопоставления шаблонов для ссылок и путей в репозитории. Основное отличие новой реализации в поддержке маски "**/" для многоуровневых путей ("refs/**/master" сработает для "refs/heads/master" и "refs/remotes/origin/master").
В анонсе также отмечается, что начиная с выпуска Git 2.0 будет изменено поведение команды "git push" по умолчанию. В ситуации когда при выполнении "git push" явно не указано что именно помещать в репозиторий ранее использовалась семантика "matching", при которой для обновления выбирались все внешние ветки и теги с именами, совпадающими с локальными. В будущем поведение будет изменено и по умолчанию будет применяться семантика "simple", при которой изменения отправляются только из текущей ветки в ветку с тем же именем, в случае если локальная ветка назначена для интеграции с удалённой веткой. Переопределить новое поведение можно через конфигурационную переменную "push.default".
При неуказании добавляемых путей при выполнении "git add -u" и "git add -A", начиная с версии Git 2.0 данные команды будут применяться для всего репозитория, а не иерархии относительно текущей поддиректории, что соответствует поведению "git commit -a" и других похожих команд. Для распространения действия только начиная с текущей директории следует явно указывать текущий путь, например, "git add -u .".URL: https://lkml.org/lkml/2013/3/13/455
Новость: http://www.opennet.me/opennews/art.shtml?num=36406
Докачка когда нибудь предвидится?...
> Докачка когда нибудь предвидится?...звучит как какая-то НЕатомарная операция :-)
я думал для докачки используют wget ...
>я думал для докачки используют wget ...rsync, http умеют. Почему git поверх rsync не умеет?
потому что это никому не нужно.
у вас все еще dial-up ?
да, а как вы догадались О_о
> Докачка когда нибудь предвидится?Докачка не нужна. Это же не Mercurial.
Зато в JVM нужна. :)
> Докачка когда нибудь предвидится?...Поскольку VCS - не файлокачалка, для нее это куда менее приоритетная вещь, учитывая что сколь-нибудь большой трансфер данных делается единоразово. А потом шлется только весьма мелкая дельта. Вы прикиньте, какие негодяи: делают DVCS ... для удобства разработчиков и прочих участников проекта. А не тех кто перепутал DVCS с файлокачалкой и прочих казуалов.
> Поскольку VCS - не файлокачалка, для нее это куда менее приоритетная вещь,
> учитывая что сколь-нибудь большой трансфер данных делается единоразово. А потом шлется
> только весьма мелкая дельта. Вы прикиньте, какие негодяи: делают DVCS ...
> для удобства разработчиков и прочих участников проекта. А не тех кто
> перепутал DVCS с файлокачалкой и прочих казуалов.Ну теперь я спокоен. Теперь докачка точно появится в git. Потому что уж сильно мальчики-зайчики орут, что она не нужна.
Появится - и ладно, никто против не будет. Но, честно говоря, она и правда не особо нужна.
> Ну теперь я спокоен. Теперь докачка точно появится в git. Потому что
> уж сильно мальчики-зайчики орут, что она не нужна.Понимаешь, буратиныч, гит делает удобно участникам проектов. А не каким-то посторонним проходимцам перепутавшим протоколы FTP с VCS. При использовани DVCS как именно DVCS дельты между состояниями - мизерные. А начальная синхронизация делается 1 раз за все время работы с проектом.
> Понимаешь, буратиныч, гит делает удобно участникам проектов. А не каким-то посторонним
> проходимцам перепутавшим протоколы FTP с VCS. При использовани DVCS как именно
> DVCS дельты между состояниями - мизерные. А начальная синхронизация делается 1
> раз за все время работы с проектом.Зашибись логика.
А участников проекта, наверное, с Марса завезли. где git - с 1576 года от Земного Рождества Христова.
> При неуказании добавляемых путей при выполнении "git add -u" и "git add -A", начиная с версии Git 2.0 данные команды будут применяться для всего репозитория, а не иерархии относительно текущей поддиректорииНу вот, а только две недели назад здесь же мне кто-то объяснял, что у git это самое правильное из самых правильных решений, не то, что у других.
С каждой новой версией у git становится всё более человеческое и человеческое лицо. А у тех, кто с криками защищал все нелогичности - всё более глупое и квадратное.
> а только две недели назад здесь же мне кто-то объяснял, что у git это самое правильное из самых правильных решений, не то, что у других.Это Же Совсем Другое Дело.
Эм... А в чём выгода такого поведения? По-моему текущий вариант гораздо удобнее
Ага, поковырял... Честно говоря, лучше б они дали настройку, дефолтом для которой прописали вообще запрет на выполнение git add -u/-A без аргументов.
>При задании шаблона в файлах .gitignore и .gitattributes теперь допустимо использовать маску "**/" для допустимости нулевого и более высокого уровня вложенности поддиректории. Т.е. "foo/**/bar" сработает как при наличии bar в директории foo так и если bar находится в поддиректории директории foo;Отличная фича! - уже ради нее стоит обновится
Mercurial такое чуть ли не с самого начала умеет. Такими темпами получается, что регэкспы в .gitignore/.gitattributes следует ждать году к 2017.
> Mercurial такое чуть ли не с самого начала умеет. Такими темпами получается,
> что регэкспы в .gitignore/.gitattributes следует ждать году к 2017.А в каком году в ртутной буите будет octopus merge?
>> Mercurial такое чуть ли не с самого начала умеет. Такими темпами получается,
>> что регэкспы в .gitignore/.gitattributes следует ждать году к 2017.
> А в каком году в ртутной буите будет octopus merge?Ух ты, живой пользователь octopus merge!
> Ух ты, живой пользователь octopus merge!Да, еще запишите что мне 640Кб не хватило. 16Гб оказалось лучше.
>> Ух ты, живой пользователь octopus merge!
> Да, еще запишите что мне 640Кб не хватило. 16Гб оказалось лучше.Аналогично. Мои «16Г» — это возможность использовать и hg bookmarks (быстрофиксы и просто короткие ветки) *и* hg branches (долгоживущие, соответственно, ветки). А опечатки править вообще в анонимных ветках.
Что до octopus merge, я неоднократно встречал Git workflow, в которых явно запрещают его использовать :) Названия проектов уже не помню.
> Аналогично. Мои «16Г» — это возможность использовать иДа-да, слышали эту песню. Небось монеткой выбираете, когда в git это один адекватный инструмент.
> Что до octopus merge, я неоднократно встречал Git workflow, в которых явно запрещают его использовать :) Названия проектов уже не помню.
Кто бы сомневался.
> Небось монеткой выбираетеи пью кровь Линуса каждое утро
> в git это один адекватный инструмент
Вот и Совсем Другое Дело подоспело. Естественно, Ведь Это Же Целый Git.
> Кто бы сомневался.
на здоровье
> запрещают его использовать :) Названия проектов уже не помню.А некоторые до сих пор используют SVN (sic!). Правда, ходят упорные слухи что програмеров это обычно не устраивает и они поднимают где-нибудь сбоку git-зеркало и там работают по удобным им технологиям. А уже потом оттуда патчи оформляют в апстрим по их политикам и прочая. Такой вот тихий переворот, без выстрелов и взрывов.
А к какому, интересно, году от mercurial ждать избавления от питона?
А в каком году git избавится от шелл-скриптов и перла?
> А в каком году git избавится от шелл-скриптов и перла?В ядре git нет ни шелл-скриптов, ни перла.
> В ядре git нет ни шелл-скриптов, ни перла.Что ты понимаешь под "ядром"? Конкретно.
И от лёгкой поддержки платформ, где есть python тоже. И от лёгкого импорта в python-скрипты. И от пользователей, чего уж там.
> И от лёгкой поддержки платформ, где есть python тоже.Это что ж за платформы такие, где питон поддерживается, а C нет? Или может расскажете что питон не на C написан?
> И от лёгкого импорта в python-скрипты.
Феерически маргинальный аргумент, ибо нужно это полутора человекам. Но если вы настаиваете, в python-скрипты также легко импортируется и git, man git-python. Алсо, расскажите как легко он импортируется в C проекты, тогда как для git есть libgit2.
> И от пользователей, чего уж там.
Ну пользователей у него и не было никогда - гляньте хотя бы статистику ohloh.
Но ваш аргумент я понял - hg используют только питонщики, и нужен он им только потому что написан на питоне. Я догадывался.
hg же ничего кроме регэкспов не поддерживает. не удобно же. во всех нормальных тулзах есть выбор файлов не регэкспами.
> hg же ничего кроме регэкспов не поддерживает.поддерживает
> не удобно же. во всех нормальных тулзах есть выбор файлов не регэкспами.
а чем? только не говорите, что мыжкой, а то моё деревянное ранимое сердце этого не перенесёт.
> поддерживаетhttp://mercurial.selenic.com/wiki/.hgignore
помоему это только регэкспы - не?
> а чем? только не говорите, что мыжкой, а то моё деревянное ранимое
см. rsync, duplicity, git - поддерживают wildcard pattern - типа '?', '*', '**" - это удобнее чем постоянно писать регэкспы, а так же выше уровнем чем они - можно например понять что если на конце ** то значит не нужно просматривать данную директорию вообще (это лучше чем анализировать регэксп) и, например, в случае если ** совпадает с 0 или более поддиректориями (а это именно то что добавили в гит), то ** в общем то не компилируется в какой-то определённый регэксп - вернее это скрыто в деталях реализации какой именно, а для юзера не очевидно.
> hg же ничего кроме регэкспов не поддерживает. не удобно же. во всех нормальных тулзах есть выбор файлов не регэкспами.враньё же, ну — http://www.selenic.com/mercurial/hgignore.5.html#syntax
>> hg же ничего кроме регэкспов не поддерживает. не удобно же. во всех нормальных тулзах есть выбор файлов не регэкспами.
> враньё же, ну — http://www.selenic.com/mercurial/hgignore.5.html#syntaxага, пардон, смотрел здесь http://mercurial.selenic.com/wiki/.hgignore и здесь не было.
ну глобы ещё есть, ок хотя толку от них...
> ага, пардон, смотрел здесь http://mercurial.selenic.com/wiki/.hgignore и здесь не было.на практически любом сайте с веб-интерфейсом hg есть help по текущей версии
> ну глобы ещё есть, ок хотя толку от них...поэтому открываем любой сайт с hg, и читаем:
http://selenic.com/repo/hello/help/patterns
http://selenic.com/repo/hello/help/filesets
>> ага, пардон, смотрел здесь http://mercurial.selenic.com/wiki/.hgignore и здесь не было.
> на практически любом сайте с веб-интерфейсом hg есть help по текущей версии
>> ну глобы ещё есть, ок хотя толку от них...
> поэтому открываем любой сайт с hg, и читаем:
> http://selenic.com/repo/hello/help/patterns
> http://selenic.com/repo/hello/help/filesetsок, спасибо, был не прав.
> ок, спасибо, был не прав.да наплевать, кто прав и кто не прав. нездоровый симптом уже то, что подобные мысли возникают.
Хотя всё равно, есть многие из тех, кому нужен один фюрер и один рейх. и которого вся предыдущая мировая история ничему не научила. И текущая не научит.
> Хотя всё равно, есть многие из тех, кому нужен один фюрер и
> один рейх. и которого вся предыдущая мировая история ничему не научила.
> И текущая не научит.Господи, да вы из кожи вылезете чтобы оправдать существование своего меркуриала :)))
Да используйте его сколько угодно, никто его не отбирает, кто-то наверняка еще rcs или VSS использует. Только вот из всех них потоки г-на из себя изливают только меркуриальщики.
Я использую и hg, и git, и fossil по выходным. hg просто проще.Это у git-овцев как раз болезнь "один рейх, один фюрер", судя по теме, прогрессирует.
Это у вас попаболь прогрессирует, что вы только что показали. А я повторюсь:Да используйте его сколько угодно, никто его не отбирает, кто-то наверняка еще rcs или VSS использует. Только вот из всех них потоки г-на из себя изливают только меркуриальщики.
> Господи, да вы из кожи вылезете чтобы оправдать существование своего меркуриала :)))А нам не надо оправдывать его существование. Потому что он проще и большинство новичков предпочитают его. А git обычно выбирают не потому, что "проще было разобраться", а потому что "там уже был git".
Если завтра появится хорошо разрекламированный fossilhub, все будут пользоваться fossil, да ещё и оправдывать "как же это удобно". :)
К счастью, те, кто решают, какой системой пользоваться, могут всё ещё выбирать инструмент. И да, python это серьёзное преимущество. Я даже некоторые изменения делал для себя, потому что это просто. :)
> А нам не надо оправдывать его существование. Потому что он проще и
> большинство новичков предпочитают его. А git обычно выбирают не потому, что
> "проще было разобраться", а потому что "там уже был git".Статистика есть, или тебе просто очень хочется так думать?
> Если завтра появится хорошо разрекламированный fossilhub, все будут пользоваться fossil,
> да ещё и оправдывать "как же это удобно". :)Ага, но ни в коем случае не могло так случиться так что github стал популярным потому что им и гитом удобно пользоваться. Все плевались, но переползали на них, только потому что ZOG рекламировал их в 25-кадре лога загрузки ядра.
> К счастью, те, кто решают, какой системой пользоваться, могут всё ещё выбирать
> инструмент.Так и есть. Ещё раз напомнить что все выбирают?
> И да, python это серьёзное преимущество. Я даже некоторые изменения
> делал для себя, потому что это просто. :)Да, удачи вам.
>> А нам не надо оправдывать его существование. Потому что он проще и
>> большинство новичков предпочитают его. А git обычно выбирают не потому, что
>> "проще было разобраться", а потому что "там уже был git".
> Статистика есть, или тебе просто очень хочется так думать?но тебя же любая статистика не устроит, не так ли?
>> Если завтра появится хорошо разрекламированный fossilhub, все будут пользоваться fossil, да ещё и оправдывать "как же это удобно". :)
> Ага, но ни в коем случае не могло так случиться так что github стал популярным потому что им и гитом удобно пользоваться. Все плевались, но переползали на них, только потому что ZOG рекламировал их в 25-кадре лога загрузки ядра.Гитхабом пользоваться удобно. Отсюда популярность. Большое кол-во пользователей git объясняется именно этим.
>> К счастью, те, кто решают, какой системой пользоваться, могут всё ещё выбирать инструмент.
> Так и есть. Ещё раз напомнить что все выбирают?Ну то есть как «выбирают»:
— Куда проект положим?
— На этот, как его, популярный очень… во, гитхаб. Больше народу узнает опять же.
— Ок.— В какую VCS складывать проект?
— SVN нынче немодно (да и святой Линус его юзеров ругал плохими словами), модно этот, как его, гит, вот.
— Ок, давай.— Вот тут программеры возмущаются, мол им svn работать мешает. Я посмотрел, похоже и правда мешает. Кто-то так вообще mercurial тихой сапой пользуется.
— Хорошо, давай. Какой там хостинг mercurial умеет?
— Вот, bitbucket.
— Не, не слышал. Да и аляповатый он какой-то. А вот про гитхаб слышал и много.
— Оно mercurial не умеет.
— Дапофиг, перебрались с SVN раз, переберутся и другой.— Посоны, мне тут subversion жить мешает, под что бы проект переложить?
— Git
— Git
— Git
— Git
— Git
— Ок, всем спасибо, будет Git.Вот так «выбирают» контроль версий в реальном мире.
git log -p
для просмотра изменений
а
возможности просмотра этих же изменений и включая сабмодули когда появится?
а через сколько лет можно будет 1 файл/каталог слить при помощи git, не выкачивая тонны бесполезной ерунды ?
сам то понял что сказал?
> а через сколько лет можно будет 1 файл/каталог слить при помощи git,
> не выкачивая тонны бесполезной ерунды ?Уже. Давно? С разморозкой!
git archive --remote=git://git.foo.com/project.git HEAD:path/to/directory filename | tar -x
http://stackoverflow.com/questions/1125476/git-retrieve-a-si...
Но да, _нужно, чтобы ответ на запрос git-archive был включён _на _сервере в gitdaemon. //на вскидку на git.k.o и github для демонстрации не нашёл
"подсветка вывода результатов выполнения тестов" каких тестов?
> "подсветка вывода результатов выполнения тестов" каких тестов?Конечно же тех, которые make test.
> В реализацию "git p4" внесена большая порция исправлений, связанных с обработкой веток. Обеспечена поддержка использования с Python 2.4/2.5Кстати, нахрена козе баян? То есть, гиту python?
>> В реализацию "git p4"Буквы---^^ не распарчил?
>> внесена большая порция исправлений, связанных с обработкой веток. Обеспечена поддержка использования с Python 2.4/2.5
> Кстати, нахрена козе баян? То есть, гиту python?А туда же?!
- Git is reasonably self-sufficient, but does depend on a few external
[...8<...]
- Python version 2.4 or later (but not 3.x, which is not
supported by Perforce) is needed to use the git-p4 interface
to Perforce.