LINUX.ORG.RU

git-1.6.6 вышел

 , , , , ,


0

0

В рассылке fa.linux.kernel анонсирован выход новой версии распределенной системы контроля версий Git.

Среди изменений:

  • Улучшения в утилитах GUI (git gui и gitk): добавлена поддержка тем tk 8.5, исправлены мелкие ошибки;
  • Улучшена скорость работы git-fetch через HTTP: полный обход коммитов заменен более интеллектуальным алгоритмом;
  • К команде git-fetch добавлена опции --all и --multiple, позволяющие забирать коммиты сразу из нескольких удаленных репозиториев;
  • Уменьшено использование памяти при выполнении команды «git diff -B»;
  • «git instaweb» теперь поддерживает работу с mod_cgid;
  • imap-send теперь может быть собран в окружении mingw32;
  • В git-svn добавлена поддержка пересоздания пустых директорий (git отслеживает только файлы, потому при импорте SVN-репозитория вставала проблема пустых директорий). Кроме этого улучшена обработка слияний в SVN;
  • «gitweb» теперь имеет опциональную поддержку инкрементального вывода «blame» (для работы опции нужна поддержка JavaScript в браузере клиента);
  • и многое другое (см. changelog)

Кроме того, в данной версии началась подготовка к изменениям параметров комманд версии 1.7: при попытке использования опций, которые будут удалены в 1.7 выводится соответствующее предупреждение.

Скачать

>>> Подробности

★★★★★

Проверено: boombick ()

Ответ на: комментарий от tailgunner

Это самовнушение, да? %)

Боюсь, вы таки не поняли высказывание, и каким-то образом отнесли мои слова на свой счет.

Злой tailgunner — плохой tailgunner. Разоблачитель заговора марсиан, и борец за независимость людей.

baverman ★★★
()
Ответ на: комментарий от tailgunner

>Инопланетяне, разрабатывающие Git, их не примут. Зомбированные земляне, которые хотят стать инопланетянами, и пользуются для этого Git, не примут никаких человеческих изменений.

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

Смотрел «Они живут»? :)


Не смотрел, а читал. И не «Они живут», а просто «Они». Хайнлайн, 5 страниц, а как написал, чертяка. И главное, сразу понятно, что эти самые Они - уже здесь, и никуда от них не деться.

volh ★★
()
Ответ на: комментарий от volh

а еще у нас есть гитхаб - социальная сеть для настоящих арви хэккеров.

volh ★★
()
Ответ на: комментарий от volh

> Да ладно тебе, существует не одна и не две реализации гита,

Назовите всех поименно

в какой-нибудь да сделают гугеноты-отступники гламурный синтаксис команд и возможность расширения на питоне

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

Смотрел «Они живут»? :)

Не смотрел, а читал. И не «Они живут», а просто «Они». Хайнлайн, 5 страниц

Не, момент, когда на рекламном плакате проступает «Obey», надо видеть.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Начало хорошее. К финалу фильм, конечно, скатился.

LamerOk ★★★★★
()
Ответ на: комментарий от tailgunner

>Назовите всех поименно

Нет уж, вторжение так вторжение)

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


Я сейчас сериал смотрю родом из детства, «первая волна», там как раз про это. Но только кажись протагонист-параноик-инопланетяноборец в конце последнего сезона очухивается в психушке, где тепло и сухо.

volh ★★
()
Ответ на: комментарий от MATPOCKUH

> После прочтения этого документа, ты все еще считаешь, что питонисты спорят за tabs vs spaces!?

Вне зависимости от существования этого документа, я знаю, что есть питонисты, использующие Tab.

Генерал говорит: «The most popular way of indenting Python is with spaces only. The second-most popular way is with tabs only». Ты что, генерала не уважаешь?

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> Смотрел «Они живут»?

смотрел, трешовенький такой фильм, но забавный.

По сабжу - вбросить в тему про гит что-нибудь про меркуриал - хорошо, есть надежда услышать от адептов реальные преимущества, а не просто «гит - наше все!». Интересно же узнать у людей активно им пользующихся что там есть такого хорошего, что стоит на него поглядеть. Даже виндузячим быдлокодерам интересно бывает. Но пока ничего конструктивного.

anonymous
()
Ответ на: комментарий от anonymous

> есть надежда услышать от адептов реальные преимущества, а не просто «гит - наше все!».

Думаешь, еще есть? :)

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> Думаешь, еще есть? :)

да, я безнадежный оптимист :)

anonymous
()
Ответ на: комментарий от tailgunner

>> «For new projects, spaces-only are strongly recommended over tabs.»

А идентация табами всё еще second most popular %)

Обратная совместимость есть неизбежное зло. Не вижу проблемы и повода ломать копья.

MATPOCKUH
()

(Git | Mercurial) + SVN?

А как в Mercurial делается интеграция с SVN-репозиториями? Я как-то пытался прояснить этот вопрос, но так ничего путного и не нагуглил. В итоге выбрал Git, потому как его git-svn - вещь замечательная!

anonymous
()

В последнее время на ЛОРе четко дозируется по одному крупному треду в день: вчера Опера без Qt, сегодня git vs all.

fractaler ★★★★★
()
Ответ на: (Git | Mercurial) + SVN? от anonymous

> А как в Mercurial делается интеграция с SVN-репозиториями?

hgsvn, hgsubversion. Правда, я сам ими не пользовался - у нас всё в Mercurial.

Я как-то пытался прояснить этот вопрос, но так ничего путного и не нагуглил.

Доо... это всё есть в Mercurial Wiki: http://mercurial.selenic.com/wiki/WorkingWithSubversion

anonymous
()
Ответ на: комментарий от andyTon

> Большие дядьки придумали себе новую игрушку и развлекаются :( Причем хоть хорошо бы все одну игрушку ломали - так нет, надо понаплодить ни с чем не совместимых и ломающих моск детям велосипедов под названием git, hg, bazaar-ng и еще много всего.

И юмор в том, что то, что выдается за «прогресс» - на практике - топтание на месте.

Я успел попользоваться, наверное, десятком разных систем контроля версий, и могу сказать, что DVCS реально удобнее централизованных VCS. Так что нравится тебе это или нет, а Git и Mercurial будут увеличивать свою долю. На тупых и ленивых никто ориентироваться не собирается.

pitekantrop ★★★
()
Ответ на: комментарий от Sectoid

>>Да, прикрутили, года три назад, может раньше. Я так далеко в его историю не заглядывал.

Тогда пощупаем. Но помнится, что что-то связанное с бранчами мне в mercurial сильно не понравилось.

Git-like branches прикрутили ровно год назад, в версии 1.1. В Mercurial они называются bookmarks. http://mercurial.selenic.com/wiki/BookmarksExtension

pitekantrop ★★★
()
Ответ на: комментарий от pitekantrop

Git-like branches прикрутили ровно год назад, в версии 1.1. В mercurial они называются bookmarks

Bookmarks are stored localy. You can use rsync or scp to copy the .hg/bookmarks file to a remote repository

Ваще отличная тема. Ага.

baverman ★★★
()
Ответ на: комментарий от Sectoid

+ много. Интересно, почему не 1.7.0 номер присвоили ?

dotbg ★★★★
()
Ответ на: комментарий от baverman

Кстати, кто-нибудь может на реальных примерах объяснить, в чем профит этих branches в git? Git-ом пользовался мало, bookmarks в Mercurial я не пользовался.

pitekantrop ★★★
()
Ответ на: комментарий от anonymous

>> А как в Mercurial делается интеграция с SVN-репозиториями?

hgsvn, hgsubversion. Правда, я сам ими не пользовался - у нас всё в Mercurial.

HgSubversion мне больше нравится. И он даже кое-как стандартную структуру trunk/tags/branches импортирует. Правда, импорт на большом репозитарии размера apache-poi может день занять. И памяти он в процессе импорта жрёт огого как.

pitekantrop ★★★
()
Ответ на: комментарий от pitekantrop

можно легко и ВНЕЗАПНО начать девелопить что-то левое, основываясь на каком-то коммите, периодически подтягивать в этот бранч изменения из апстрима, и когда работа будет завершена, мержить в апстрим.

Zmacs
()

Если кто мучается с svn externals

Решил даже зарегистрироваться, если кто мучается на работе с svn extrnals и git-svn попробуйте скриптик, http://github.com/sushdm/git_svn_externals Ничего в нем волшебного, но в целом похоже работает, если будут баги, пишите, постараюсь исправить, ну и пожелания приму конечно. Другие скрипты пробовал использовать, ничего не работало, поэтому свой и сгородил, может пригодится кому.

sushdm
()
Ответ на: комментарий от Zmacs

> можно легко и ВНЕЗАПНО начать девелопить что-то левое, основываясь на каком-то коммите, периодически подтягивать в этот бранч изменения из апстрима, и когда работа будет завершена, мержить в апстрим.

Для того же самого использую patch queue (Mercurial Queues). В Гите тоже что-то похожее есть. Кроме вышеуказанного, у MQ есть следующие плюшки: changegeset-ы представляют собой обыкновенные текстовые патчи, с которыми можно удобно работать с помощью внешних утилит или даже редактировать в текстовом редакторе, можно откатить несколько патчей, что-нибудь поменять в changeset-е в глубине, а потом накатить патчи снова.

А у бранчей какие плюшки есть?

Да, может кому интересно, Peter Arrenbrecht написал ещё более навороченное расширение для групповой работы с очередями патчей: http://arrenbrecht.ch/mercurial/pbranch/

pitekantrop ★★★
()
Ответ на: комментарий от baverman

baverman, где плагин?!

> Зато у нас нет холиворов о величине отступа, чем его делать и на какой строке располагать открывающую скобку.

Ба! Дружище baverman объявился!

Всем, всем, всем. Было очень забавно. Очень много радости принесли. Мне пора начинать писать плагин к gedit для редактирования xml. На питоне :) Думаю за 10 часов справлюсь. В дальнейшем планирую написать плагин для редактирования php и groovy и получить наконец вменяемую среду, в которой можно будет работать работу.

Где плагин, мля?! У тебя было дохрена времени. Или ты все ещё факториалы с аккерманами считаешь?

http://www.linux.org.ru/jump-message.jsp?msgid=4115459&cid=4117003

От анонимуса не скроешься.

anonymous
()
Ответ на: комментарий от volh

> потому что отдельная сущность.

Если ты о том, что это — extension, то это как раз хорошо, т.к. раз такие вещи могут делаться как расширения, значит Mercurial спроектирован грамотно.

pitekantrop ★★★
()
Ответ на: комментарий от pitekantrop

как неграмотный гит-файнбой я должен подавлять зависть по поводу расширяемости hg и кричать что экстеншены - источник мирового зла. хотя стой.. так и есть!!!111

volh ★★
()
Ответ на: комментарий от m0rph

> Хорошо бы git еще под оффтопик нормально портировали, можно было бы пересадить на него коллег-подоконников.

А чо, работает. Наши сидят, даже некоторые операции, вроде мёржа, делают строго в git-svn, несмотря на повальный TortoiseSVN - так предсказуемее получается... Медленно только git ворочается на NTFS'е...

AlexM ★★★★★
()
Ответ на: комментарий от AlexM

Медленно в сравнении с ним же, но на линуксовых файлухах. Особенно заметно на массовых операциях типа filter-branch или длинных ребэйзах.

AlexM ★★★★★
()
Ответ на: комментарий от cyberax

Читать про core.autocrlf & Co в git.config. правда, если в репозитории бардак, то это плохо работало. Сейчас у меня, после наведения порядка, работает хорошо. Ну и редакторы - они того, решают. Примерно, как с отступами у питона :)

AlexM ★★★★★
()
Ответ на: комментарий от tailgunner

> Назовите всех поименно

JGit - Pure Java реализация, лежащая внутри гуглоадроидного Gerrit'а.

Есть Pure Python реализация — не git-python имени Давида Агилара (David Aguilar), которая является обёрткой над утилитами, а именно питоньей реализацией именно работы с git'овой базой. Правда, подробно на неё не смотрел, но, если интересно, дойду до работы, погляжу в историю, пришлю ссылку.

AlexM ★★★★★
()
Ответ на: комментарий от pitekantrop

> Git-like branches прикрутили ровно год назад, в версии 1.1. В Mercurial они называются bookmarks. http://mercurial.selenic.com/wiki/BookmarksExtension

Кстати, bookmarks более адекватное название, чем branches. Потому как git'овские бранчи - ни что иное, как «самодвижущиеся метки» на графе коммитов. Осознание этого факта очень способствует пониманию и объяснению происходящего при, скажем, forward-only мёржах или, например, пояснению различий между мёржами и ребэйзами.

AlexM ★★★★★
()

Весь тред не читал.

Небольшое отступление на тему питона.

Хороший язык, мне очень много нравится, хоть и ооп. Писал на удаве даже пару толстых гуёвых вещей. Но есть одна серьёзная трабла: расставлять заново инденты, когда копируешь кусок кода из одного файла в другой (хорошо ещё, если ошибку интерпретатор заметит... а если не заметить и не *убрать* отступ после окончания блока?)

В этом отношении фигурные скобки и т.п. практичнее — хоть и всё равно красявости наводить, но зато хоть работать будет в любом случае, структуру копированием не испортишь.

// монотролям просьба не беспокоить

matimatik
()
Ответ на: комментарий от pitekantrop

> Кстати, кто-нибудь может на реальных примерах объяснить, в чем профит этих branches в git? Git-ом пользовался мало, bookmarks в Mercurial я не пользовался.

Беда в том, что никто из «серьёзных» пользователей git'а не представляет толком, что делается в hg. А в git'е это, пожалуй, самый естественный способ вести проект. Порождение, убиение и даже, скажем, переотращивание бранча на новом корне, особенно, если дело касается твоего персонального репозитория или ветки в командном репозитории, которой пользуются 3-4 человека - дело простое и естественное.

git branch --track new_branch [other/branch]
(или вообще git checkout -b new_branch [other/branch]
git merge joe/branch1 fred/branch1 jane/branch2
git rebase mike/branch1

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

Конечно, при несоблюдении элементарных правил самоорганизации, - например, всякие экспериментальные вещи лучше называть с префиксом
exp/ или ещё каким, явно отличающим такую ветку от «рабочих», а временные ветки, потребные только для того, чтобы подержать в сторонке пару коммитов, - с префиксом tmp/, - при несоблюдении таких правил репозиторий может превратиться в помойку. Но, в общем, бранчи безболезненно переименовываются, удаляются и прочее, даже в командных репозиториях, старые, отжившие своё бранчи без проблем уезжают в архив, доступный по отдельному запросу итп.

В общем, схема разделения на «настоящие бранчи» и «букмарки» представляется мне несколько надуманной.

AlexM ★★★★★
()
Ответ на: комментарий от matimatik

> Но есть одна серьёзная трабла: расставлять заново инденты, когда копируешь кусок кода из одного файла в другой (хорошо ещё, если ошибку интерпретатор заметит... а если не заметить и не *убрать* отступ после окончания блока?)

Решается редактором? Все приличные даже рефакторить умеют по-человечьи

AlexM ★★★★★
()
Ответ на: Если кто мучается с svn externals от sushdm

> Решил даже зарегистрироваться, если кто мучается на работе с svn extrnals и git-svn попробуйте скриптик, http://github.com/sushdm/git_svn_externals

Спасибо, посмотрю. Вообще, по идее, весь git-submodule надо пере-/доколбасить, даже примерно понятно как, только всё некогда :)

AlexM ★★★★★
()
Ответ на: комментарий от pitekantrop

> Для того же самого использую patch queue (Mercurial Queues). В Гите тоже что-то похожее есть.

stgit

changegeset-ы представляют собой обыкновенные текстовые патчи, с которыми можно удобно работать с помощью внешних утилит или даже редактировать в текстовом редакторе, можно откатить несколько патчей, что-нибудь поменять в changeset-е в глубине, а потом накатить патчи снова.

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

Порядок следования, равно как и содержимое (неопубликованной) серии изменений, влёгкую изменяеется при помощи git cherry-pick , git add --interactive и git commit --amend. Для меня является скорее нормой, чем исключением, вначале наколбасить фичу, сделав произвольное количество промежуточных коммитов, произвести первоначальную отладку, опять-таки, коммитая по ходу, потом «прыгнуть назад» в начало работы, растащить пачку образовавшихся изменений на логически цельные, правильно отсортированные коммиты: этот - к рефакторингу, этот - к багфиксу чего-то застарелого, а этот - собственно фича, - после чего начинать публикацию полученной цепочки коммитов. Всё это делается в рамках персонального гитового репозитория (или репозиториев, если надо, например, отладиться на линуксе и винде), при помощи стандартных git'овых средств. Хотя, конечно, ничего не мешает сбросить всё в текстовые файлы и оперировать уже ими, но, как правило, это не нужно.

Поэтому мне собственно и интересно, а MQ - это обязательное условие для подобного воркфлоу или, всё-таки, и в pure hg подобное делается удобно?

AlexM ★★★★★
()
Ответ на: комментарий от AlexM

Посмотрел. В качестве быстрого решения - очень хорошо.

Скажите, у Вас нет желания объединить Ваш скрипт с какой-либо из имеющихся в git/на базе git системой множественных репозиториев? (имеются ввиду git-submodule и repo из Android/Gerrit) А то, чувствую, у меня так и не хватит моральных и физических сил допилить свои хаки до публикуемого состояния.

Пояснения относительно имеющейся на сегодня в git инфраструктуры для реализации задачи, а так же, если потребуется, свои соображения относительно того, что стоит делать, а что нет, дам с удовольствием. mail/jid - в профиле.

AlexM ★★★★★
()
Ответ на: комментарий от AlexM

влёгкую изменяеется при помощи git cherry-pick , git add --interactive и git commit --amend.

Да, чтобы не пугать непосвящённых git'оспецифичной терминологией:

git cherry-pick - приложить изменения из указанного коммита [из другой ветки] и сформировать новый коммит в текущей ветке с атрибутами (автор, коммит-мессэйдж, время) исходного коммита. Есть ключик --no-commit, который прикладывает изменения на рабочее дерево, подготавливает (предположительные) параметры следующего коммита и останавливается, чтобы дать пользователю проверить/закоммитать всё руками.

git add --interactive - выбрать из списка изменений в рабочем дереве те, которые будут закоммитаны следующей командой git commit. Можно выбирать как целиком изменённые файлы, так и отдельные изменённые строчки в файлах, при этом содержимое рабочего дерева не меняется, меняется только индекс.

git commit --amend - исправить предыдущий коммит изменениями, помеченными для коммита. При этом формируется новый коммит, являющийся суперпозицией предыдущего и добавленных изменений

AlexM ★★★★★
()
Ответ на: комментарий от AlexM

>> changegeset-ы представляют собой обыкновенные текстовые патчи, с которыми можно удобно работать с помощью внешних утилит или даже редактировать в текстовом редакторе, можно откатить несколько патчей, что-нибудь поменять в changeset-е в глубине, а потом накатить патчи снова.

Собственно, излишество.

«Зелен виноград» (c)

Порядок следования, равно как и содержимое (неопубликованной) серии изменений, влёгкую изменяеется при помощи git cherry-pick , git add --interactive и git commit --amend.

«Влегкую» %) А в MQ нужно просто подредактировать series. И вроде бы git cherry-pick работает путем генерации и наложения патчей? %)

при помощи стандартных git'овых средств.

Это MQ «нестандартное» средство?

Поэтому мне собственно и интересно, а MQ - это обязательное условие для подобного воркфлоу или, всё-таки, и в pure hg подобное делается удобно?

Да что вы доколебались до факта, что MQ - плагин? Этот плагин всего на полгодв моложе самого Mercurial. Почему никто не жалуется, что stgit или topgit - обертки вокруг Git?

tailgunner ★★★★★
()
Ответ на: комментарий от AlexM

> чтобы не пугать непосвящённых git'оспецифичной терминологией:

Да пугай уж лучше сразу. За одну терминологию аффтаров git следовало бы убить.

tailgunner ★★★★★
()
Ответ на: комментарий от pitekantrop

>Что ты подразумеваешь под «нативно» и где ты увидел в MQ костыли?
Поясняю:Ты хочешь изменить старый коммит. Лишние действия в hg: конвертировать в mq, pop, изменяешь, push, превращаешь в обычные коммиты.
А теперь сделай это в гите и удивись :)

xorik ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.