The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Релиз распределенной системы управления исходными текстами Git 1.8.2

15.03.2013 21:59

Доступен релиз распределенной системы управления исходными текстами Git 1.8.2. Git является одной из самых эффективных, надёжных и высокопроизводительных систем управления версиями, предоставляющей гибкие средства нелинейной разработки, базирующиеся на ответвлении и слиянии веток. Для обеспечения целостности истории и устойчивости к изменениям задним числом используются криптографические методы, также возможна привязка цифровых подписей разработчиков к тегам и коммитам.

Из проектов, разрабатываемых с использованием Git, можно отметить ядро Linux, Android, Libreoffice, Systemd, X.Org, Wayland, Mesa, Gstreamer, Wine, Debian, DragonFly BSD, Perl, Eclipse, GNOME, KDE, Qt, Ruby on Rails, PostgreSQL, VideoLAN, PHP, Xen, Minix.

Из изменений в 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 .".



  1. Главная ссылка к новости (https://lkml.org/lkml/2013/3/1...)
  2. OpenNews: Проект Xen перешёл с Mercurial на Git
  3. OpenNews: Компания Microsoft добавила в Visual Studio и Team Foundation Service поддержку Git
  4. OpenNews: Релиз Seafile 1.4, Dropbox-подобного сервера хранения на основе технологий Git
  5. OpenNews: Релиз распределенной системы управления исходными текстами Git 1.8.1
  6. OpenNews: Релиз распределенной системы управления исходными текстами Git 1.8.0
Лицензия: CC-BY
Тип: Программы
Короткая ссылка: https://opennet.ru/36406-git
Ключевые слова: git
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (55) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, ВовкаОсиист (ok), 23:16, 15/03/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Докачка когда нибудь предвидится?...
     
     
  • 2.2, Xasd (ok), 23:31, 15/03/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Докачка когда нибудь предвидится?...

    звучит как какая-то НЕатомарная операция :-)

    я думал для докачки используют wget ...

     
     
  • 3.5, anonymous (??), 23:47, 15/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >я думал для докачки используют wget ...

    rsync, http умеют. Почему git поверх rsync не умеет?

     
     
  • 4.36, Аноним (-), 16:05, 16/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    потому что это никому не нужно.
     
  • 2.3, Аноним (-), 23:32, 15/03/2013 [^] [^^] [^^^] [ответить]  
  • –3 +/
    у вас все еще dial-up ?
     
     
  • 3.4, ВовкаОсиист (ok), 23:39, 15/03/2013 [^] [^^] [^^^] [ответить]  
  • –3 +/
    да, а как вы догадались О_о
     
  • 2.13, iZEN (ok), 00:45, 16/03/2013 [^] [^^] [^^^] [ответить]  
  • –8 +/
    > Докачка когда нибудь предвидится?

    Докачка не нужна. Это же не Mercurial.

     
     
  • 3.28, Аноним (-), 12:00, 16/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Зато в JVM нужна. :)

     
  • 2.31, Аноним (-), 15:11, 16/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Докачка когда нибудь предвидится?...

    Поскольку VCS - не файлокачалка, для нее это куда менее приоритетная вещь, учитывая что сколь-нибудь большой трансфер данных делается единоразово. А потом шлется только весьма мелкая дельта. Вы прикиньте, какие негодяи: делают DVCS ... для удобства [b]разработчиков[/b] и прочих участников проекта. А не тех кто перепутал DVCS с файлокачалкой и прочих казуалов.

     
     
  • 3.34, бедный буратино (ok), 15:23, 16/03/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Поскольку VCS - не файлокачалка, для нее это куда менее приоритетная вещь,
    > учитывая что сколь-нибудь большой трансфер данных делается единоразово. А потом шлется
    > только весьма мелкая дельта. Вы прикиньте, какие негодяи: делают DVCS ...
    > для удобства [b]разработчиков[/b] и прочих участников проекта. А не тех кто
    > перепутал DVCS с файлокачалкой и прочих казуалов.

    Ну теперь я спокоен. Теперь докачка точно появится в git. Потому что уж сильно мальчики-зайчики орут, что она не нужна.

     
     
  • 4.46, Crazy Alex (ok), 05:02, 17/03/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Появится - и ладно, никто против не будет. Но, честно говоря, она и правда не особо нужна.
     
  • 4.56, Аноним (-), 02:22, 18/03/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Ну теперь я спокоен. Теперь докачка точно появится в git. Потому что
    > уж сильно мальчики-зайчики орут, что она не нужна.

    Понимаешь, буратиныч, гит делает удобно участникам проектов. А не каким-то посторонним проходимцам перепутавшим протоколы FTP с VCS. При использовани DVCS как именно DVCS дельты между состояниями - мизерные. А начальная синхронизация делается 1 раз за все время работы с проектом.

     
     
  • 5.59, бедный буратино (ok), 02:41, 18/03/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Понимаешь, буратиныч, гит делает удобно участникам проектов. А не каким-то посторонним
    > проходимцам перепутавшим протоколы FTP с VCS. При использовани DVCS как именно
    > DVCS дельты между состояниями - мизерные. А начальная синхронизация делается 1
    > раз за все время работы с проектом.

    Зашибись логика.

    А участников проекта, наверное, с Марса завезли. где git - с 1576 года от Земного Рождества Христова.

     

  • 1.20, бедный буратино (ok), 03:52, 16/03/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    > При неуказании добавляемых путей при выполнении "git add -u" и "git add -A", начиная с версии Git 2.0 данные команды будут применяться для всего репозитория, а не иерархии относительно текущей поддиректории

    Ну вот, а только две недели назад здесь же мне кто-то объяснял, что у git это самое правильное из самых правильных решений, не то, что у других.

    С каждой новой версией у git становится всё более человеческое и человеческое лицо. А у тех, кто с криками защищал все нелогичности - всё более глупое и квадратное.

     
     
  • 2.24, develop7 (ok), 08:38, 16/03/2013 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > а только две недели назад здесь же мне кто-то объяснял, что у git это самое правильное из самых правильных решений, не то, что у других.

    Это Же Совсем Другое Дело.

     
  • 2.47, Crazy Alex (ok), 05:05, 17/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Эм... А в чём выгода такого поведения? По-моему текущий вариант гораздо удобнее
     
     
  • 3.48, Crazy Alex (ok), 05:09, 17/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Ага, поковырял... Честно говоря, лучше б они дали настройку, дефолтом для которой прописали вообще запрет на выполнение git add -u/-A без аргументов.
     

  • 1.21, jOKer (ok), 05:07, 16/03/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >При задании шаблона в файлах .gitignore и .gitattributes теперь допустимо использовать маску "**/" для допустимости нулевого и более высокого уровня вложенности поддиректории. Т.е. "foo/**/bar" сработает как при наличии bar в директории foo так и если bar находится в поддиректории директории foo;

    Отличная фича! - уже ради нее стоит обновится

     
     
  • 2.23, develop7 (ok), 08:25, 16/03/2013 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Mercurial такое чуть ли не с самого начала умеет. Такими темпами получается, что регэкспы в .gitignore/.gitattributes следует ждать году к 2017.
     
     
  • 3.32, Аноним (-), 15:16, 16/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Mercurial такое чуть ли не с самого начала умеет. Такими темпами получается,
    > что регэкспы в .gitignore/.gitattributes следует ждать году к 2017.

    А в каком году в ртутной буите будет octopus merge?

     
     
  • 4.42, develop7 (ok), 19:59, 16/03/2013 [^] [^^] [^^^] [ответить]  
  • –6 +/
    >> Mercurial такое чуть ли не с самого начала умеет. Такими темпами получается,
    >> что регэкспы в .gitignore/.gitattributes следует ждать году к 2017.
    > А в каком году в ртутной буите будет octopus merge?

    Ух ты, живой пользователь octopus merge!

     
     
  • 5.57, Аноним (-), 02:23, 18/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Ух ты, живой пользователь octopus merge!

    Да, еще запишите что мне 640Кб не хватило. 16Гб оказалось лучше.

     
     
  • 6.66, develop7 (ok), 11:26, 18/03/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> Ух ты, живой пользователь octopus merge!
    > Да, еще запишите что мне 640Кб не хватило. 16Гб оказалось лучше.

    Аналогично. Мои «16Г» — это возможность использовать и hg bookmarks (быстрофиксы и просто короткие ветки) *и* hg branches (долгоживущие, соответственно, ветки). А опечатки править вообще в анонимных ветках.

    Что до octopus merge, я неоднократно встречал Git workflow, в которых явно запрещают его использовать :) Названия проектов уже не помню.

     
     
  • 7.76, Аноним (-), 20:09, 18/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Аналогично. Мои «16Г» — это возможность использовать и

    Да-да, слышали эту песню. Небось монеткой выбираете, когда в git это один адекватный инструмент.

    > Что до octopus merge, я неоднократно встречал Git workflow, в которых явно запрещают его использовать :) Названия проектов уже не помню.

    Кто бы сомневался.

     
     
  • 8.84, develop7 (ok), 11:51, 19/03/2013 [^] [^^] [^^^] [ответить]  
  • –2 +/
    и пью кровь Линуса каждое утро Вот и Совсем Другое Дело подоспело Естественно, ... текст свёрнут, показать
     
  • 7.83, Аноним (-), 10:21, 19/03/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > запрещают его использовать :) Названия проектов уже не помню.

    А некоторые до сих пор используют SVN (sic!). Правда, ходят упорные слухи что програмеров это обычно не устраивает и они поднимают где-нибудь сбоку git-зеркало и там работают по удобным им технологиям. А уже потом оттуда патчи оформляют в апстрим по их политикам и прочая. Такой вот тихий переворот, без выстрелов и взрывов.

     
  • 3.52, Аноним (-), 22:48, 17/03/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А к какому, интересно, году от mercurial ждать избавления от питона?
     
     
  • 4.55, Knuckles (ok), 23:57, 17/03/2013 [^] [^^] [^^^] [ответить]  
  • –2 +/
    А в каком году git избавится от шелл-скриптов и перла?
     
     
  • 5.77, Аноним (-), 20:10, 18/03/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > А в каком году git избавится от шелл-скриптов и перла?

    В ядре git нет ни шелл-скриптов, ни перла.

     
     
  • 6.80, Knuckles (ok), 20:50, 18/03/2013 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > В ядре git нет ни шелл-скриптов, ни перла.

    Что ты понимаешь под "ядром"? Конкретно.

     
  • 4.60, бедный буратино (ok), 02:49, 18/03/2013 [^] [^^] [^^^] [ответить]  
  • –3 +/
    И от лёгкой поддержки платформ, где есть python тоже. И от лёгкого импорта в python-скрипты. И от пользователей, чего уж там.
     
     
  • 5.78, Аноним (-), 20:19, 18/03/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > И от лёгкой поддержки платформ, где есть python тоже.

    Это что ж за платформы такие, где питон поддерживается, а C нет? Или может расскажете что питон не на C написан?

    > И от лёгкого импорта в python-скрипты.

    Феерически маргинальный аргумент, ибо нужно это полутора человекам. Но если вы настаиваете, в python-скрипты также легко импортируется и git, man git-python. Алсо, расскажите как легко он импортируется в C проекты, тогда как для git есть libgit2.

    > И от пользователей, чего уж там.

    Ну пользователей у него и не было никогда - гляньте хотя бы статистику ohloh.

    Но ваш аргумент я понял - hg используют только питонщики, и нужен он им только потому что написан на питоне. Я догадывался.

     
  • 3.54, vsespb (ok), 23:32, 17/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    hg же ничего кроме регэкспов не поддерживает. не удобно же. во всех нормальных тулзах есть выбор файлов не регэкспами.
     
     
  • 4.58, бедный буратино (ok), 02:39, 18/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > hg же ничего кроме регэкспов не поддерживает.

    поддерживает

    > не удобно же. во всех нормальных тулзах есть выбор файлов не регэкспами.

    а чем? только не говорите, что мыжкой, а то моё деревянное ранимое сердце этого не перенесёт.

     
     
  • 5.68, vsespb (ok), 11:33, 18/03/2013 [^] [^^] [^^^] [ответить]  
  • +/

    > поддерживает

    http://mercurial.selenic.com/wiki/.hgignore

    помоему это только регэкспы - не?

    > а чем? только не говорите, что мыжкой, а то моё деревянное ранимое

    см. rsync, duplicity, git - поддерживают wildcard pattern - типа '?', '*', '**" - это удобнее чем постоянно писать регэкспы, а так же выше уровнем чем они - можно например понять что если на конце ** то значит не нужно просматривать данную директорию вообще (это лучше чем анализировать регэксп) и, например, в случае если ** совпадает с 0 или более поддиректориями (а это именно то что добавили в гит), то ** в общем то не компилируется в какой-то определённый регэксп - вернее это скрыто в деталях реализации какой именно, а для юзера не очевидно.

     
  • 4.67, develop7 (ok), 11:30, 18/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > hg же ничего кроме регэкспов не поддерживает. не удобно же. во всех нормальных тулзах есть выбор файлов не регэкспами.

    враньё же, ну — http://www.selenic.com/mercurial/hgignore.5.html#syntax

     
     
  • 5.69, vsespb (ok), 11:37, 18/03/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> hg же ничего кроме регэкспов не поддерживает. не удобно же. во всех нормальных тулзах есть выбор файлов не регэкспами.
    > враньё же, ну — http://www.selenic.com/mercurial/hgignore.5.html#syntax

    ага, пардон, смотрел здесь http://mercurial.selenic.com/wiki/.hgignore и здесь не было.
    ну глобы ещё есть, ок хотя толку от них...

     
     
  • 6.70, бедный буратино (ok), 11:45, 18/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > ага, пардон, смотрел здесь http://mercurial.selenic.com/wiki/.hgignore и здесь не было.

    на практически любом сайте с веб-интерфейсом hg есть help по текущей версии


    > ну глобы ещё есть, ок хотя толку от них...

    поэтому открываем любой сайт с hg, и читаем:

    http://selenic.com/repo/hello/help/patterns
    http://selenic.com/repo/hello/help/filesets

     
     
  • 7.71, vsespb (ok), 11:47, 18/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >> ага, пардон, смотрел здесь http://mercurial.selenic.com/wiki/.hgignore и здесь не было.
    > на практически любом сайте с веб-интерфейсом hg есть help по текущей версии
    >> ну глобы ещё есть, ок хотя толку от них...
    > поэтому открываем любой сайт с hg, и читаем:
    > http://selenic.com/repo/hello/help/patterns
    > http://selenic.com/repo/hello/help/filesets

    ок, спасибо, был не прав.

     
     
  • 8.73, бедный буратино (ok), 11:51, 18/03/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    да наплевать, кто прав и кто не прав нездоровый симптом уже то, что подобные мы... текст свёрнут, показать
     
  • 6.72, бедный буратино (ok), 11:48, 18/03/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Хотя всё равно, есть многие из тех, кому нужен один фюрер и один рейх. и которого вся предыдущая мировая история ничему не научила. И текущая не научит.
     
     
  • 7.79, Аноним (-), 20:23, 18/03/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Хотя всё равно, есть многие из тех, кому нужен один фюрер и
    > один рейх. и которого вся предыдущая мировая история ничему не научила.
    > И текущая не научит.

    Господи, да вы из кожи вылезете чтобы оправдать существование своего меркуриала :)))
    Да используйте его сколько угодно, никто его не отбирает, кто-то наверняка еще rcs или VSS использует. Только вот из всех них потоки г-на из себя изливают только меркуриальщики.

     
     
  • 8.81, бедный буратино (ok), 10:01, 19/03/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Я использую и hg, и git, и fossil по выходным hg просто проще Это у git-овцев ... текст свёрнут, показать
     
     
  • 9.86, Аноним (-), 19:47, 19/03/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Это у вас попаболь прогрессирует, что вы только что показали А я повторюсь Да ... текст свёрнут, показать
     
  • 8.82, бедный буратино (ok), 10:04, 19/03/2013 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А нам не надо оправдывать его существование Потому что он проще и большинство н... текст свёрнут, показать
     
     
  • 9.87, Аноним (-), 19:58, 19/03/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Статистика есть, или тебе просто очень хочется так думать Ага, но ни в коем слу... большой текст свёрнут, показать
     
     
  • 10.88, develop7 (ok), 17:43, 20/03/2013 [^] [^^] [^^^] [ответить]  
  • +/
    но тебя же любая статистика не устроит, не так ли Гитхабом пользоваться удобно ... текст свёрнут, показать
     

  • 1.37, mercurial (?), 18:15, 16/03/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    git log -p
    для просмотра изменений
    а
    возможности просмотра этих же изменений и включая сабмодули когда появится?
     
  • 1.51, Аноним (-), 21:24, 17/03/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    а через сколько лет можно будет 1 файл/каталог слить при помощи git, не выкачивая тонны бесполезной ерунды ?
     
     
  • 2.63, slowpoke (?), 09:55, 18/03/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    сам то понял что сказал?
     
  • 2.65, Andrey Mitrofanov (?), 11:22, 18/03/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > а через сколько лет можно будет 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-single-file-from-a-

    Но да, _нужно, чтобы ответ на запрос git-archive был включён _на _сервере в gitdaemon. //на вскидку на git.k.o и github для демонстрации не нашёл

     

  • 1.62, slowpoke (?), 09:43, 18/03/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    "подсветка вывода результатов выполнения тестов" каких тестов?
     
     
  • 2.64, Andrey Mitrofanov (?), 09:55, 18/03/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > "подсветка вывода результатов выполнения тестов" каких тестов?

    Конечно же тех, которые make test.

     

  • 1.74, бедный буратино (ok), 12:41, 18/03/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    > В реализацию "git p4" внесена большая порция исправлений, связанных с обработкой веток. Обеспечена поддержка использования с Python 2.4/2.5

    Кстати, нахрена козе баян? То есть, гиту python?

     
     
  • 2.75, Andrey Mitrofanov (?), 15:25, 18/03/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> В реализацию "git p4"

    Буквы---^^  не распарчил?

    >> внесена большая порция исправлений, связанных с обработкой веток. Обеспечена поддержка использования с Python 2.4/2.5
    > Кстати, нахрена козе баян? То есть, гиту python?

    А туда же?!

    [CODE] - 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.[/CODE]

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру