The OpenNET Project / Index page

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

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

17.02.2014 14:47

Доступен релиз распределенной системы управления исходными текстами Git 1.9.0. Скачок в нумерации версии связан с внесением изменений, нарушающих обратную совместимость. Более существенные нарушения совместимости, связанные с изменением поведения команд "git push" и "git add", отложены до выпуска Git 2.0.

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.9.0, влияющие на обратную совместимость:

  • Аргументы "$cmd $args" в команде "git submodule foreach $cmd $args", используемые по аналогии с указанием подобных аргументов в ssh, теперь передаются напрямую без выполнения через командный интерпретатор, что позволяет избежать непредсказуемого результата, если пользователь забудет экранировать данные в блоке $args;
  • Прекращена поддержка работающего в режиме только для чтения экспериментального формата несвязанных объектов (loose-object);
  • Изменено действие опции "--tags" в команде "git fetch", которая теперь приводит к извлечению не только тегов, но и данных, извлекаемых как при использовании команды без опции "--tags" (ранее при указании "--tags" извлекались только теги);
  • Расширен способ интерпретации аргумента $what в команде "git push $there $what", в ситуации когда, через двоеточие явно не определено, какая ссылка в репозитории $there должна быть обновлена;
  • Прекращена поддержка серии давно устаревших команд: repo-config, tar-tree, lost-found и peek-remote.

Среди других изменений в Git 1.9.0:

  • При использовании HTTP в качестве транспорта добавлена поддержка ответа "100 Continue" при выполнении HTTP GSS-Negotiate для того, чтобы избежать повторной пересылки больших объёмов данных;
  • Различные обновления в реализации "git p4", "git svn" и "gitk";
  • Разрешено контролируемое извлечение объектов из репозитория, клонированного в режиме shallow (клон без полной истории изменений, созданный с использованием опции "--depth");
  • Добавлена возможность переопределения обработчика команды lv через переменную окружения LV, по аналогии с переопределением less через LESS;
  • Использования опции "--prune" в команде "git fetch" теперь позволяет при извлечении удалённо отслеживаемой ветки 'frotz' осуществить предварительное удаление ранее извлечённой ветки 'frotz/nitfol' для высвобождения места;
  • Добавлена переменная конфигурации "diff.orderfile=file", выступающая аналогом опции "-Ofile" для команды "git diff";
  • Поддержка синтаксиса для исключения отдельных путей, например, "git log -- . ':!dir'" приведёт к обработке всего содержимого, кроме директории 'dir';
  • В процессе выполнения команды "git difftool" добавлено отображение общего числа файловых путей и сколько из них уже показано;
  • Команда "git push origin master", используемая для отправки текущей master-ветки для обновления внешней master-ветки в оригинальном репозитории, расширена возможностью указания идентичного метода маппинга ссылок, позволяющего определить какие из ссылок в оригинальном репозитории были обновлены на основании текущей master-ветки;
  • В "gitweb" добавлена возможность работы с иерархиями ссылок, отличных от refs/heads, когда используются дополнительные пространства имён веток, например, refs/changes/ в Gerrit;
  • В команды, подобные "git log", добавлена опция "--exclude=glob" для исключения при выводе истории изменений данных, соответствующих указанной маске, например, "git log --exclude='*/*' --branches".

Начиная с выпуска 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 .". Команда "git add путь" в Git 2.0 будет соответствовать выполнению "git add -A путь" в выпусках Git 1.x. Кроме того, c refs/remotes на refs/remotes/origin/ будет изменён префикс по умолчанию для команды "git svn", если префикс не был явно задан при помощи опции "--prefix".

  1. Главная ссылка к новости (http://permalink.gmane.org/gma...)
  2. OpenNews: Инициатива по переводу Emacs c Bazaar на Git
  3. OpenNews: Релиз распределенной системы управления исходными текстами Git 1.8.4
  4. OpenNews: Релиз распределенной системы управления исходными текстами Git 1.8.1
  5. OpenNews: Релиз распределенной системы управления исходными текстами Git 1.8.2
  6. OpenNews: Релиз распределенной системы управления исходными текстами Git 1.8.3
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/39108-git
Ключевые слова: git
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (48) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 15:36, 17/02/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –11 +/
    Кстати о Mercurial
    https://lists.gnu.org/archive/html/emacs-devel/2014-01/msg00343.html
    http://gregoryszorc.com/blog/2013/05/12/thoughts-on-mercurial-%28and-git
     
     
  • 2.2, бедный буратино (ok), 15:45, 17/02/2014 [^] [^^] [^^^] [ответить]  
  • +32 +/
    хочешь узнать про git - иди в тему mercurial

    хочешь узнать про mercurial - иди в тему про git

     
     
  • 3.8, Аноним (-), 16:45, 17/02/2014 [^] [^^] [^^^] [ответить]  
  • +19 +/
    Здравствуйте, это канал про git? Как пропатчить mercurial под freebsd?
     
  • 2.11, Пропатентный тролль (?), 17:04, 17/02/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Дошел до строчки "The problem is that Mercurial isn't git. Git definitely is the leader now. Git is "cool"." И закрыл окно.
     
     
  • 3.34, Аноним (-), 22:18, 17/02/2014 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Вы так говорите, как будто быть лучше других - преступление.
     
     
  • 4.41, Аноним (-), 08:55, 18/02/2014 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Стас Михайлов и Дарья Донцова одобряют этот комментарий.
     
  • 4.68, ffirefox (?), 12:41, 19/02/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Не преступление, а ответственность

     

  • 1.3, Аноним (-), 16:04, 17/02/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    а меркуриал умеет shallowly-cloned ?
     
     
  • 2.10, pavlinux (ok), 16:51, 17/02/2014 [^] [^^] [^^^] [ответить]  
  • +22 +/
    Что за шаловливые клоуны?
     
     
  • 3.31, Аноним (-), 21:12, 17/02/2014 [^] [^^] [^^^] [ответить]  
  • +/
    с английским языком вы походу не знакомы и новость не читали:
    Разрешено контролируемое извлечение объектов из репозитория, клонированного в режиме shallow (клон без полной истории изменений, созданный с использованием опции "--depth");
     
  • 2.37, Аноним (-), 01:37, 18/02/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Полноценно нет, можно склонить только один бранч - clone -r
     

  • 1.4, бедный буратино (ok), 16:17, 17/02/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    вечерело, а тема ждала первого коммента про git, а не про mercurial :)
     
  • 1.6, Аноним (-), 16:22, 17/02/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    Занимаются всякой хрень, в то время как самый нужный способ создать ветку почему-то делается по команде "checkout -b" и не работает с тэгами.
     
     
  • 2.22, arisu (ok), 19:23, 17/02/2014 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Занимаются всякой хрень, в то время как самый нужный способ создать ветку
    > почему-то делается по команде «checkout -b» и не работает с тэгами.

    man git-branch.
    выдержка оттуда: «The command's second form creates a new branch head named <branchname> which points to the current HEAD, or <start-point> if given.»
    врут, заразы?

     
     
  • 3.44, Аноним (-), 09:07, 18/02/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > врут, заразы?

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

     
  • 3.49, Аноним (-), 13:54, 18/02/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > The command's second form creates a new branch head named <branchname> which points to the current HEAD, or <start-point> if given.

    Это Вы, пардон, к чему?

    Задача: нужно создать трэкинг брэнч с тем же именем, что и в удаленном репозитории одинаковым набором команд
    а) если ревизия задана именем ветки (вытаскиваем HEAD)
    б) если ревизия задана тэгом (вытаскиваем ту ветку, из которой tag)

    Ревизия задана переменной окружения $REVISION. Ваш вариант решения?

     
     
  • 4.50, arisu (ok), 14:35, 18/02/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Задача: нужно создать трэкинг брэнч с тем же именем, что и в
    > удаленном репозитории

    это не называется «создать», он у тебя уже есть. ты его не видишь, а он есть. зачем тебе заниматься потенциально конфликтными извращениями вместо того, чтобы переключится на уже существующий бранч — мне не ясно.

     
     
  • 5.54, Аноним (-), 15:00, 18/02/2014 [^] [^^] [^^^] [ответить]  
  • +/
    У меня его нет Мне нужно склонировать репозиторий в состояние ревизии REVISION... большой текст свёрнут, показать
     
     
  • 6.56, arisu (ok), 15:09, 18/02/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > У меня его нет. Мне нужно склонировать репозиторий в состояние ревизии $REVISION
    > для ночной сборки. $REVISION можтет быть:
    > а) идентификатором конкретного комита
    > б) тэгом
    > в) именем ветки (в этом случае — собрать надо HEAD этой ветки)

    но ЗАЧЕМ? случаи «б» и «в» элеметнарно сводятся к «а».

    > Должны работать все три случая единым способом (делается автоматически на сборочной машине).

    сделай скрипт-обёртку. лично я, например — категорически против того, чтобы разные вещи делались одним и тем же способом.

    > git очень хорош архитектурно, но система команд крива и не продумана.

    а как по мне — всё достаточно логично. надо просто думать «по гитовски», и логика находится.

     
     
  • 7.57, Аноним (-), 15:59, 18/02/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Как зачем Есть три сущности, однозначно идентифицирующие комит Надо достать ре... большой текст свёрнут, показать
     
     
  • 8.58, arisu (ok), 16:08, 18/02/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    в общем-то, да хотя как это сделать лучше 8212 я не знаю хм бывают случаи,... текст свёрнут, показать
     
     
  • 9.59, Аноним (-), 17:15, 18/02/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Тут соглашусь Нужна еще одна команда - switch для переключения между ветками, и... большой текст свёрнут, показать
     
     
  • 10.61, arisu (ok), 17:17, 18/02/2014 [^] [^^] [^^^] [ответить]  
  • +/
    это не переключение per se но несколько нелогично, согласен ... текст свёрнут, показать
     
     
  • 11.63, Аноним (-), 17:59, 18/02/2014 [^] [^^] [^^^] [ответить]  
  • +/
    О чем и я Если это не переключение - это не должна делать checkout В результат... текст свёрнут, показать
     
     
  • 12.65, rshadow (ok), 00:10, 19/02/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Вот когда половине гита поменяют команды на нормальные, а не как управлять низк... текст свёрнут, показать
     
     
  • 13.66, arisu (ok), 06:45, 19/02/2014 [^] [^^] [^^^] [ответить]  
  • +/
    так вперёд код открыт 8212 делай ... текст свёрнут, показать
     
     
  • 14.72, Аноним (-), 20:58, 21/02/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Во-первых, проще взять Mercurial Во-вторых, писать обертки для git - по сравнен... текст свёрнут, показать
     
     
  • 15.73, arisu (ok), 21:07, 21/02/2014 [^] [^^] [^^^] [ответить]  
  • +/
    ну так бери что ты в новости о git забыл-то, если тебе больше ртуть нравится ... текст свёрнут, показать
     
  • 6.60, Аноним (-), 17:15, 18/02/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > У меня его нет. Мне нужно склонировать репозиторий в состояние ревизии $REVISION для ночной сборки. $REVISION можтет быть:
    > а) идентификатором конкретного комита
    > б) тэгом
    > в) именем ветки (в этом случае - собрать надо HEAD этой ветки)

    git checkout $REVISION работает для всего вышеперечисленного.

     
     
  • 7.62, arisu (ok), 17:18, 18/02/2014 [^] [^^] [^^^] [ответить]  
  • +/
    там, насколько я понял, человек немного другого хочет, просто описал косовато.
     

  • 1.7, vitalif (ok), 16:28, 17/02/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    А что такое "контролируемое извлечение объектов из репозитория, клонированного в режиме shallow"?
     
     
  • 2.45, Аноним (-), 09:08, 18/02/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > А что такое "контролируемое извлечение объектов из репозитория, клонированного в режиме
    > shallow"?

    Это извлечение не вообще всей истории а лишь части, на определенную глубину.

     
     
  • 3.69, vitalif (ok), 19:30, 19/02/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Нет, это ты сам shallow описал, он и в предыдущих версиях есть. Меня интересует, что имеется ввиду в самой фразе "контролируемое извлечение объектов из репозитория, клонированного в режиме shallow"?
     

  • 1.19, Аноним (-), 18:37, 17/02/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Ура, ждём 2.0.

    PS. Решил попробовать git после 2 лет mercurial'а да так и остался.

     
  • 1.36, Аноним (-), 01:32, 18/02/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    И MS, помнится, юзал git.
    Пока, как и все остальные адекватные компаниии, не перешёл на svn.
     
     
  • 2.38, r (?), 01:37, 18/02/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Что такое: "MS" .?
     
     
  • 3.48, pkdr (ok), 12:45, 18/02/2014 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Известный производитель качественных клавиатур и мышей.

    В 80-е они вроде бы ещё запилили какую-то графическую оболочку для MS-DOS, но ничего путного из неё не получилось.

     
     
  • 4.52, Аноним (-), 14:50, 18/02/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Да, потому что они тогда ещё вроде бы запилили Windows 1, а в мс-досе была куча ограничений, от которых уже давно всем хотелось избавиться и никакие GUI ей помочь решить фундаментальные проблемы были не в состоянии.
     
  • 4.64, Andrey Mitrofanov (?), 18:02, 18/02/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Известный производитель качественных клавиатур и мышей.

    s/производитель качественных/продавец безумно переоцененных китайских/

    , о чём нам намекает торго^Wразвод лохов на коробочки с воздухом с буквами eula и cal.

    > но ничего путного из неё не получилось.

    Им нравится. Клиент сидит плотнее, чем на героине.

     
  • 2.40, СРР (?), 04:44, 18/02/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > И MS, помнится, юзал git.
    > Пока, как и все остальные адекватные компаниии, не перешёл на svn.

    Что за адекватные компаниии -)))

     
     
  • 3.51, arisu (ok), 14:43, 18/02/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> Пока, как и все остальные адекватные компаниии, не перешёл на svn.
    > Что за адекватные компаниии -)))

    те, видать, которые до этого на cvs сидели.

     
  • 2.46, Аноним (-), 09:09, 18/02/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > И MS, помнится, юзал git.

    Да, даже до этих корпрративных жирафов стало доходить что их TFSы из каменного века и прочий доисторический крап - это жалкая пародия на VCS, которая имеет разработчику мозг, а вовсе не эффективная подмога. А тут еще гитхабы всякие. Вот и пришлось кой-как прикручивать к вьюжлстудии для виндовых гламурных мальчиков.

     

  • 1.42, Аноним (-), 09:01, 18/02/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Не нарадуюсь на него в DFBSD, особенно сравнивая с фряшным svn-ом. Последний тормознее в несколько раз. Про cvs вообще молчу.:)
     
     
  • 2.47, Аноним (-), 09:10, 18/02/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > Не нарадуюсь на него в DFBSD, особенно сравнивая с фряшным svn-ом. Последний
    > тормознее в несколько раз. Про cvs вообще молчу.:)

    А если бы разработчики линя использовали svn - они бы уже давно озверели.

     
  • 2.55, Аноним (-), 15:06, 18/02/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А зря молчите про CVS - по сравнению с современным SVN даже он выглядит конфеткой. Работал он гораздо быстрее, а главное - можно было обновлять чекаут из локального зеркала репозитория (с централизованными VCS по-другому нельзя работать в принципе), а коммитить в основной. SVN так не умеет, а переключает весь чекаут на другой URL долго, а главную (единственную, что осталась у централизованных) фичу - возможность работать с отдельной директорией как с целым репозиторием - с 1.7, кажется, успешно убили.
     
     
  • 3.67, Аноним (-), 09:23, 19/02/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, у меня выборка конечно, нерепрезентативная, но судя по времени обновления сорцов системы, svn работает раза в полтора-два быстрее cvs, а git так вообще раза в 4 быстрее svn. И, что немаловажно, в отличие от обоих лучше переживает перебои связи. Если вдруг коннект порвет, часто сам продолжает, когда снова появится, а svn с cvs'ом надо килять и перезапускать.
     
     
  • 4.71, Аноним (-), 14:08, 20/02/2014 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Если вдруг коннект порвет,

    git оставит тебя с недокачанным куском, который потом придётся скачивать опять с нуля. В svn с этим намного лучше.

     
  • 3.70, vitalif (ok), 19:32, 19/02/2014 [^] [^^] [^^^] [ответить]  
  • +/
    > А зря молчите про CVS - по сравнению с современным SVN даже
    > он выглядит конфеткой. Работал он гораздо быстрее

    CVS?!!!! Быстрее???

    > возможность работать с отдельной директорией как с целым репозиторием - с 1.7, кажется, успешно убили.

    Не убили, чекаутить просто теперь отдельно надо. Зато нет .svn говна в каждой папке и сама рабочая копия гораздо быстрее работает (sqlite теперь).

     

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



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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