Доступен (http://permalink.gmane.org/gmane.linux.kernel/1648566) релиз распределенной системы управления исходными текстами Git 1.9.0 (http://git-scm.com/). Изменение нумерации ветки связано с внесением незначительных изменений, нарушающих обратную совместимость. Более существенные изменения, связанные с поведением команд "git puth" и "git add", отложены до выпуска Git 2.0.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/), Xen (http://xenbits.xen.org/gitweb/), Minix (http://git.minix3.org/).
Изменения в 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:
- Поддержка ответа "100 Continue" при GSS-Negotiate для того, чтобы избежать повторной пересылки больших объёмов данных при использовании HTTP в качестве транспорта;
- Различные обновления в реализации "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. Кроме того, будет изменён префикс по умолчанию для команды "git svn" c refs/remotes на refs/remotes/origin/, если префикс не был явно задан при помощи опции "--prefix".
URL: http://permalink.gmane.org/gmane.linux.kernel/1648566
Новость: http://www.opennet.me/opennews/art.shtml?num=39108
Кстати о Mercurial
https://lists.gnu.org/archive/html/emacs-devel/2014-01/msg00...
http://gregoryszorc.com/blog/2013/05/12/thoughts-on-mercuria.../
хочешь узнать про git - иди в тему mercurialхочешь узнать про mercurial - иди в тему про git
Здравствуйте, это канал про git? Как пропатчить mercurial под freebsd?
Дошел до строчки "The problem is that Mercurial isn't git. Git definitely is the leader now. Git is "cool"." И закрыл окно.
Вы так говорите, как будто быть лучше других - преступление.
Стас Михайлов и Дарья Донцова одобряют этот комментарий.
Не преступление, а ответственность
а меркуриал умеет shallowly-cloned ?
Что за шаловливые клоуны?
с английским языком вы походу не знакомы и новость не читали:
Разрешено контролируемое извлечение объектов из репозитория, клонированного в режиме shallow (клон без полной истории изменений, созданный с использованием опции "--depth");
Полноценно нет, можно склонить только один бранч - clone -r
вечерело, а тема ждала первого коммента про git, а не про mercurial :)
Занимаются всякой хрень, в то время как самый нужный способ создать ветку почему-то делается по команде "checkout -b" и не работает с тэгами.
> Занимаются всякой хрень, в то время как самый нужный способ создать ветку
> почему-то делается по команде «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.»
врут, заразы?
> врут, заразы?Да, только не авторы гит. Найти чего-то чего бы было востребовано и гит так не умел - надо очень сильно постараться.
> 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. Ваш вариант решения?
> Задача: нужно создать трэкинг брэнч с тем же именем, что и в
> удаленном репозиторииэто не называется «создать», он у тебя уже есть. ты его не видишь, а он есть. зачем тебе заниматься потенциально конфликтными извращениями вместо того, чтобы переключится на уже существующий бранч — мне не ясно.
>> Задача: нужно создать трэкинг брэнч с тем же именем, что и в
>> удаленном репозитории
> это не называется «создать», он у тебя уже есть. ты его не
> видишь, а он есть. зачем тебе заниматься потенциально конфликтными извращениями вместо
> того, чтобы переключится на уже существующий бранч — мне не ясно.У меня его нет. Мне нужно склонировать репозиторий в состояние ревизии $REVISION для ночной сборки. $REVISION можтет быть:
а) идентификатором конкретного комита
б) тэгом
в) именем ветки (в этом случае - собрать надо HEAD этой ветки)Должны работать все три случая единым способом (делается автоматически на сборочной машине).
Это просто пример, но абсолютно жизненный. В git не хватает отдельной команды для работы с трэкинг-бранчами. Вместо нее перенагрузили checkout и branch лишними параметрами.
git очень хорош архитектурно, но система команд крива и не продумана. Тот же push из топика - один из примеров.
> У меня его нет. Мне нужно склонировать репозиторий в состояние ревизии $REVISION
> для ночной сборки. $REVISION можтет быть:
> а) идентификатором конкретного комита
> б) тэгом
> в) именем ветки (в этом случае — собрать надо HEAD этой ветки)но ЗАЧЕМ? случаи «б» и «в» элеметнарно сводятся к «а».
> Должны работать все три случая единым способом (делается автоматически на сборочной машине).
сделай скрипт-обёртку. лично я, например — категорически против того, чтобы разные вещи делались одним и тем же способом.
> git очень хорош архитектурно, но система команд крива и не продумана.
а как по мне — всё достаточно логично. надо просто думать «по гитовски», и логика находится.
> но ЗАЧЕМ? случаи «б» и «в» элеметнарно сводятся к «а».Как зачем? Есть три сущности, однозначно идентифицирующие комит. Надо достать ревизию по этой сущности. В разных случаях удобно использовать разные:
- имя ветки для разработческих веток (там почти всегда нужен HEAD)
- по tag-у для релизов (учитываем, что релизных веток несколько)
- по tag-у для сборок с разными опциями - debug, trace, fix ... (эти тэги могут гулять по разным веткам)
- по идентификатору, если что-то экстренное и тэг ставить жалкоВсе решаемо, если одновременно знаем имя ветки и тэг/идентификатор в рамках нее. Только имя ветки тут - лишняя сущность, которая несет кучу гемороя. Какой-нибудь тэг fix_abc переехал в из ветки fix1 в fix2 и все - сборка поломалась.
>> Должны работать все три случая единым способом (делается автоматически на сборочной машине).
> сделай скрипт-обёртку. лично я, например — категорически против того, чтобы разные
> вещи делались одним и тем же способом.То есть Вы против того, что checkout работает одинаково с ветками и тэгами при переключении? Только сейчас оно работает от случая к случаю, а должно работать всегда.
В реальности мне нужна отдельная команда, вытаскивающая трэкинг-брэнч в логике
"checkout -b". branch - создать ветку из текущей локальной, какой-нибудь tbranch - создать ветку из удаленной. Тогда можно добиться, чтобы "git tbranch origin something" работал одинаково с ветками, тэгами и комитами.>> git очень хорош архитектурно, но система команд крива и не продумана.
> а как по мне — всё достаточно логично. надо просто думать «по
> гитовски», и логика находится.Может это со мной что-то не так, но я хочу ездить на автомобиле без изучения системы впрыска. У системы есть интерфейс, его должно быть достаточно. Если его не достаточно - значит он плохой, ч.т.д.
> То есть Вы против того, что checkout работает одинаково с ветками и
> тэгами при переключении?в общем-то, да. хотя как это сделать лучше — я не знаю.
> Только сейчас оно работает от случая к случаю,
> а должно работать всегда.хм. бывают случаи, когда checkout не переключается на указаный тэг?
> Может это со мной что-то не так, но я хочу ездить на
> автомобиле без изучения системы впрыска. У системы есть интерфейс, его должно
> быть достаточно. Если его не достаточно — значит он плохой, ч.т.д.у меня есть мнение, что тогда dvcs была выбрана не совсем верно.
>> То есть Вы против того, что checkout работает одинаково с ветками и
>> тэгами при переключении?
> в общем-то, да. хотя как это сделать лучше — я не знаю.Тут соглашусь. Нужна еще одна команда - switch для переключения между ветками, и оставить за checkout только переключение внутри ветки.
>> Только сейчас оно работает от случая к случаю,
>> а должно работать всегда.
> хм. бывают случаи, когда checkout не переключается на указаный тэг?"git checkout -b new_branch origin/some_tag" не сработает
>> Может это со мной что-то не так, но я хочу ездить на
>> автомобиле без изучения системы впрыска. У системы есть интерфейс, его должно
>> быть достаточно. Если его не достаточно — значит он плохой, ч.т.д.
> у меня есть мнение, что тогда dvcs была выбрана не совсем верно.С учетом популярности сабжа по совокупности факторов он выигрывает. Как винда у линукса ;)
>> хм. бывают случаи, когда checkout не переключается на указаный тэг?
> «git checkout -b new_branch origin/some_tag» не сработаетэто не переключение per se. но несколько нелогично, согласен.
>>> хм. бывают случаи, когда checkout не переключается на указаный тэг?
>> «git checkout -b new_branch origin/some_tag» не сработает
> это не переключение per se. но несколько нелогично, согласен.О чем и я. Если это не переключение - это не должна делать checkout. В результате и криво и не работает как надо. Нужна отдельная команда, качественно отрабатывающая все кейсы.
> Нужна отдельная команда, качественно отрабатывающая все кейсыВот когда половине гита поменяют команды на нормальные, а не "как управлять низкоуровневыми потрашками системы контроля версий", тогда и будет конфетка.
Потрошка конечно тоже можно оставить для гурманов, но хотелось бы "простое делать просто, сложное возможно", а не сразу с места в карьер.
так вперёд! код открыт — делай.
Во-первых, проще взять Mercurial.
Во-вторых, писать обертки для git - по сравнению с тем же Mercurial - та еще головная боль.
ну так бери. что ты в новости о git забыл-то, если тебе больше ртуть нравится?
> У меня его нет. Мне нужно склонировать репозиторий в состояние ревизии $REVISION для ночной сборки. $REVISION можтет быть:
> а) идентификатором конкретного комита
> б) тэгом
> в) именем ветки (в этом случае - собрать надо HEAD этой ветки)git checkout $REVISION работает для всего вышеперечисленного.
там, насколько я понял, человек немного другого хочет, просто описал косовато.
А что такое "контролируемое извлечение объектов из репозитория, клонированного в режиме shallow"?
> А что такое "контролируемое извлечение объектов из репозитория, клонированного в режиме
> shallow"?Это извлечение не вообще всей истории а лишь части, на определенную глубину.
Нет, это ты сам shallow описал, он и в предыдущих версиях есть. Меня интересует, что имеется ввиду в самой фразе "контролируемое извлечение объектов из репозитория, клонированного в режиме shallow"?
Ура, ждём 2.0.PS. Решил попробовать git после 2 лет mercurial'а да так и остался.
И MS, помнится, юзал git.
Пока, как и все остальные адекватные компаниии, не перешёл на svn.
Что такое: "MS" .?
Известный производитель качественных клавиатур и мышей.В 80-е они вроде бы ещё запилили какую-то графическую оболочку для MS-DOS, но ничего путного из неё не получилось.
Да, потому что они тогда ещё вроде бы запилили Windows 1, а в мс-досе была куча ограничений, от которых уже давно всем хотелось избавиться и никакие GUI ей помочь решить фундаментальные проблемы были не в состоянии.
> Известный производитель качественных клавиатур и мышей.s/производитель качественных/продавец безумно переоцененных китайских/
, о чём нам намекает торго^Wразвод лохов на коробочки с воздухом с буквами eula и cal.
> но ничего путного из неё не получилось.
Им нравится. Клиент сидит плотнее, чем на героине.
> И MS, помнится, юзал git.
> Пока, как и все остальные адекватные компаниии, не перешёл на svn.Что за адекватные компаниии -)))
>> Пока, как и все остальные адекватные компаниии, не перешёл на svn.
> Что за адекватные компаниии -)))те, видать, которые до этого на cvs сидели.
> И MS, помнится, юзал git.Да, даже до этих корпрративных жирафов стало доходить что их TFSы из каменного века и прочий доисторический крап - это жалкая пародия на VCS, которая имеет разработчику мозг, а вовсе не эффективная подмога. А тут еще гитхабы всякие. Вот и пришлось кой-как прикручивать к вьюжлстудии для виндовых гламурных мальчиков.
Не нарадуюсь на него в DFBSD, особенно сравнивая с фряшным svn-ом. Последний тормознее в несколько раз. Про cvs вообще молчу.:)
> Не нарадуюсь на него в DFBSD, особенно сравнивая с фряшным svn-ом. Последний
> тормознее в несколько раз. Про cvs вообще молчу.:)А если бы разработчики линя использовали svn - они бы уже давно озверели.
А зря молчите про CVS - по сравнению с современным SVN даже он выглядит конфеткой. Работал он гораздо быстрее, а главное - можно было обновлять чекаут из локального зеркала репозитория (с централизованными VCS по-другому нельзя работать в принципе), а коммитить в основной. SVN так не умеет, а переключает весь чекаут на другой URL долго, а главную (единственную, что осталась у централизованных) фичу - возможность работать с отдельной директорией как с целым репозиторием - с 1.7, кажется, успешно убили.
Ну, у меня выборка конечно, нерепрезентативная, но судя по времени обновления сорцов системы, svn работает раза в полтора-два быстрее cvs, а git так вообще раза в 4 быстрее svn. И, что немаловажно, в отличие от обоих лучше переживает перебои связи. Если вдруг коннект порвет, часто сам продолжает, когда снова появится, а svn с cvs'ом надо килять и перезапускать.
> Если вдруг коннект порвет,git оставит тебя с недокачанным куском, который потом придётся скачивать опять с нуля. В svn с этим намного лучше.
> А зря молчите про CVS - по сравнению с современным SVN даже
> он выглядит конфеткой. Работал он гораздо быстрееCVS?!!!! Быстрее???
> возможность работать с отдельной директорией как с целым репозиторием - с 1.7, кажется, успешно убили.
Не убили, чекаутить просто теперь отдельно надо. Зато нет .svn говна в каждой папке и сама рабочая копия гораздо быстрее работает (sqlite теперь).