LINUX.ORG.RU

Git 1.8.0

 , ,


0

0

Анонсирован релиз распределенной системы управления исходными текстами Git 1.8.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.

Переход от серии версий 1.7.x к 1.8.x обусловлен изменением поведения команды «git push». В ситуации когда при выполнении «git push» явно не указано что именно помещать в репозиторий в прошлых выпусках использовалась семантика «matching», при которой для обновления выбирались все внешние ветки и теги с именами, совпадающими с локальными. Начиная с ветки 1.8 поведение изменено и по умолчанию будет применяться семантика «simple», при которой изменения отправляются только из текущей ветки в ветку с тем же именем, в случае если локальная ветка назначена для интеграции с удалённой веткой. Переопределить новое поведение можно через конфигурационную переменную «push.default».

Из других изменений в Git 1.8.0 можно отметить:

  • Команда «git branch --set-upstream» объявлена устаревшей и может перестать работать в будущих выпусках. В качестве замены представлена команда «git branch [-u|--set-upstream-to]». Ранее были не редки случаи указания «git branch --set-upstream origin/master», что приводило к созданию локальной ветки «origin/master» для интеграции с текущей загруженной веткой, что явно не то что подразумевал пользователь. Окончание "-to" поможет исключить ошибочную трактовку назначения опции;
  • В «git svn» обеспечена поддержка работы с SVN 1.7. В «git p4» добавлена опция "--conflicts" для определения действий в случае обнаружения конфликта при выполнении «p4 submit»;
  • В состав включена собственная реализация библиотеки регулярных выражений для платформ, на которых наблюдаются проблемы с работой библиотеки regexp. Также добавлены обвязки для обеспечения совместимости с нестандартными реализациями mkdir и setitimer();
  • В парсер опций «git checkout» добавлена проверка типичных ошибок в порядке задания параметров командной строки. Например, при выполнении «git checkout -b -t foo bar» будет указано, что вместо имени ветки указана опция "-t";
  • Внутренние вызовы «git merge-base» заменены на более упрощённые аналоги, выполняющие только проверки наложения коммитов, без более ресурсоёмких проверок слияний веток;
  • Для платформ Win32 и GNOME добавлены хелперы для доступа к ключам текущего пользователя;
  • Выполнено начальное портирование для операционной системы серверов HP NonStop;
  • При выполнении «git am» теперь из строки «RE: subject» вырезается и префикс «RE:», а не только «Re:» и «re:»;
  • В команду «git cherry-pick» добавлена опция "--allow-empty-message" для повторной отправки коммита без занесения сообщений в лог;
  • В команду «git daemon» добавлена опция "--access-hook", разрешающая внешним командам доступ к сервисам проверки по IP или пути к репозиторию.
  • В команде «git difftool --dir-diff» реализована поддержка использования символических ссылок для подготовки временной копии рабочего дерева;
  • В команду «git grep» по умолчанию добавлена возможность указания нестандартных типов масок;
  • В команде «git log -g» появилась опция "--grep-reflog=pattern" для ограничения вывода с использованием фильтра по маске;
  • В команду «git merge-base» добавлена опция "--is-ancestor A B", позволяющая проверить является ли А прародителем B;
  • В команду «git rebase -i» добавлена опция "--edit-todo" для написания инструкций по дальнейшим изменениям;
  • Через переменные конфигурации mergetool.$name.cmd теперь можно переопределить любые команды для «git mergetool», в том числе и встроенные;
  • Интегрированы накопившиеся изменения для «git gui».

>>> Новость взята с OpenNet.RU

★★★

Проверено: tazhate ()
Ответ на: комментарий от WFrag

не боясь потерять историю

а с чего её вообще терять? или базовая арифметика не спасает?

Патчи против апстрима, значит, предлагается держать в MQ

в случае с git это называется stgit/gitum. но поскольку речь о git, это уже совсем другое дело!

Как патч распилить на два — тоже не очень понятно

тут и правда плохо. К счастью, diff -u вполне себе человекопонятен и спокойно редактируется руками.

Можно, конечно, обычными ветками обойтись

или bookmarks. или вообще анонимными головами.

то, что для логического понятия «ветка» миллион разных вариантов тоже промолчу

то есть git умеет только hg bookmarks и он правильный и гибкий, а hg умеет и multiple heads и hg branches — и оно кривое и негибкое. и никакие это не двойные стандарты, понятно?

как удалить лишнюю ревизию, голову, ветку

hg strip (прилагается в MQ). и hg help revsets для общего развития

все эти операции — весьма опасны

сообщения «saved backup bundle to …», видимо, не говорят ни о чём.

т.е напортачить гораздо легче

отличный, просто замечательный инструмент.

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

а с чего её вообще терять? или базовая арифметика не спасает?

Всякое бывает, банально ошибиться можно.

в случае с git это называется stgit/gitum. но поскольку речь о git, это уже совсем другое дело!

В случае с git, это можно делать без стороних плюх, стандартными средствами. Наверняка, эти примочки работают поверх базовых механизмов git, в отличии от MQ. Который как отдельная вселенная внутри Mercurial.

то есть git умеет только hg bookmarks и он правильный и гибкий, а hg умеет и multiple heads и hg branches — и оно кривое и негибкое. и никакие это не двойные стандарты, понятно?

Гибкость-то в том, что так как в основе один механизм, то не надо иметь 10 разных наборов инструментов.

отличный, просто замечательный инструмент.

Очевидно, что бензопилой отпилить руку проще, чем перочинным ножиком. Вот только пилить дерево я бы предпочёл пилой.

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

Они физически выполняются, хочется кому-то этого или нет. Концепция такая у системы.

Это совершенно не помешало мне их спрятать в git backend в aurum.

А зачем? Есть опция -a, хочешь - пользуйся, не хочешь - не пользуйся.

Но нет --addremove.

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

сообщения «saved backup bundle to …», видимо, не говорят ни о чём.

Вот только в git все «бэкапы» без проблем уживаются вместе, и практически каждая операция приводит к созданию нового. То есть если перейти к «мета» уровню, к уровню самого репозиторния, backup bundle vs git way — это как создание бэкапа исходников копированием в новые каталоги vs нормальная VCS.

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

Нет гарантии, что именно ты внёс изменения в рабочий каталог, а не какая-нибудь иде накидала туда мусора. При работе над одним деревом исходников более чем 1 человека - ситуация вполне вероятная.

Не вижу, как здесь поможет staging area.

Если я правильно понял, тебе нужен «git add -A».

Нет. Это не фиксирует изменения. Мне нужно оно + «git commit». В одной команде и по умолчанию. Не по умолчанию у меня уже есть.

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

А зачем эти два шага? Как я понял, то, что здесь делается — это сбор (staging) содержимого следующего изменения — добавление в index.

Весьма полезно при rebase и merge, да и при обычном commit тоже. Позволяет интерактивно набирать изменения, которые хочешь закоммитить и контролировать эти изменения.

Особенно «полезно» то, что проверить, что результат такого коммита хотя бы собирается, без изврата нельзя вообще никак. Закинул в стейдж черт знает что, закоммитил и совесть спокойна, содержимое working copy ведь работает!

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

Весьма полезно при rebase и merge, да и при обычном commit тоже. Позволяет интерактивно набирать изменения, которые хочешь закоммитить и контролировать эти изменения.

Типа без этого механизма нельзя интерактивно набирать изменения? Мне (:AuRecord) и авторам hg record теперь надо всё переписать?

«git commit -a», считаю, вредная команда. Она, конечно, удобна для новичков, которым главное свой хлам вбросить в репозиторий, но создаёт ложное впечатление о работе git.

Во‐первых, не всегда хлам. Во‐вторых, мне плевать как оно работает, review изменений я всё равно сделаю, а куда и как эти изменения локально сохраняет git — не моё дело. Главное я знаю — они в .git, они локальны и они содержат то, что мне нужно. Двухступенчатое добавление — просто ненужное препятствие, вынуждающее хранить в голове лишние сведения.

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

Особенно «полезно» то, что проверить, что результат такого коммита хотя бы собирается, без изврата нельзя вообще никак. Закинул в стейдж черт знает что, закоммитил и совесть спокойна, содержимое working copy ведь работает!.

А оно почти всегда так. Я редко видел, чтобы разработчики подчистую всё коммитили. Постоянно какие-то изменения локальные, да висят. Типа принтов дебажных каких-нибудь в левых файлах.

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

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

alias g=git

~/.gitconfig:
...
[alias]
ci = commit
co = checkout
l = log
s = show
st = status
br = branch
p = pull
ps = push
mr = merge
rb = rebase
rpo = remote prune origin
...

Usage:
g p == git pull
g st == git status
g co == git checkout
...

Slavaz ★★★★★
()
Последнее исправление: Slavaz (всего исправлений: 1)
Ответ на: комментарий от WFrag

Постоянно какие-то изменения локальные, да висят. Типа принтов дебажных каких-нибудь в левых файлах.

В mercurial я сделаю так:

hg qadd -i debug_stmts.patch # добавляем в патч ненужные изменения
hg qpop # убираем патч куда подальше
# проверяем, что в working copy все ок, коммитим
hg qpush # возвращаем локальные изменения

А в гите как предложите с этим бороться?

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

Особенно «полезно» то, что проверить, что результат такого коммита хотя бы собирается, без изврата нельзя вообще никак. Закинул в стейдж черт знает что, закоммитил и совесть спокойна, содержимое working copy ведь работает!

Именно поэтому у меня hook, тестирующий последнее изменение в default ветке перед отправкой на удалённый сервер. Самое интересное — в git такого хука нет! Только на входящие изменения. Если дело идёт о работе, где удалённый сервер свой, то это нормально. А если это мой мелкий проект на bitbucket, а тесты работают довольно долго (и я иногда хочу фиксировать изменения, которые их проваливают), то нет.

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

А в гите как предложите с этим бороться?

Коммитим нужное
$ git add ...
$ git commit ...

прячем ненужное:
$ git stash

проверяем, что всё работает. Если нет, то правим и потом разово:
$git commit -a --amend

Пушим коммит:
git push ...

возвращаем локальные изменения:
$ git stash pop

А вообще хорошая практика держать такие локальные изменения в отдельном собственном бранче и потом просто черри-пикать коммиты в основную ветку разработки (с последующим ребайзом своей ветки).

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

Коммитим нужное $ git add ... $ git commit ...

прячем ненужное: $ git stash

проверяем, что всё работает. Если нет, то правим и потом разово: $git commit -a --amend

Пушим коммит: git push ...

возвращаем локальные изменения: $ git stash pop

Или просто пишем скрипт, который берёт ревизию в качестве аргумента и проводит тестирование с ней.

Потом можно его скармливать hg bisect, особенно если написать так, чтобы он мог брать тест из рабочей копии, а остальное из данной ревизии. Правда у меня функциональные тесты и в отдельных файлах.

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

Или просто пишем скрипт, который берёт ревизию в качестве аргумента и проводит тестирование с ней.

Да, такое без проблем:
git checkout <ShaCommitId>
и можно скриптовать сколько душе угодно

Потом можно его скармливать hg bisect, особенно если написать так, чтобы он мог брать тест из рабочей копии, а остальное из данной ревизии.

http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html
git bisect run <cmd>...

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

Скажем так, новичку абсолютно без разницы в чём не разбираться: или он не будет знать Git, или он не будет знать Mercurial - в обоих случаях шансы на путь к успеху равны :) В конечном итоге получится адепт гита или ртути, но только лишь в силу привычки.

Slavaz ★★★★★
()
Последнее исправление: Slavaz (всего исправлений: 1)
Ответ на: комментарий от Slavaz

Да, такое без проблем: git checkout <ShaCommitId> и можно скриптовать сколько душе угодно

Это замечание не было описанием преимущества git или mercurial (в отличие от замечания про хуки, набор которых у git очень беден). Просто странно слышать от народа о проблеме вроде «версия в рабочем каталоге работает, а что зафиксировали — ХЗ». А потом весьма неудобный способ решения проблемы от вас.

Если надо что‐то сделать со старой версией один раз — то нормально. А проводить так регулярно тестирование…

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

Скажем так, новичку абсолютно без разницы в чём не разбираться: или он не будет знать Git, или он не будет знать Mercurial - в обоих случаях шансы на путь к успеху равны :) В конечном итоге получится адепт гита или ртути, но только лишь в силу привычки.

На уровне pull/commit/push — да. На чём‐то большем выясняется наличие у mercurial API и лучшей системы хуков. Плюс выпячивание некоторых деталей реализации у git и слишком подробная справка.

API и хуки мне важны, без остального, что я видел в качестве преимуществ git я легко обхожусь.

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

Mercurial недолюбливаю, ибо там нет аналога git add + git diff --cached.

Меня наоборот, это в git раздражает. До сих пор не могу понять, нафига нужен index? Если нужно частично зафиксировать изменения то есть hg record vim+:AuRecord. Для чего ещё может быть нужен index я совершенно не понимаю.

Добавить поднабор изменённых файлов/чанков. Посмотреть, что добавлено. Добавить ещё что-то. Посмотреть. И т. д. Сделать коммит.

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

alias g=git
~/.gitconfig: [alias]

Ну да. Разница только в том, что в hg это есть из коробки, а в git этого нет. И каждый раз, когда заходишь на другой сервер или просто приходишь к другому человеку, то в hg сразу все классно, а в git надо или настраивать на месте, или тащить с собой конфиги.

Получается как с раскладкой typewriter, у себя все хорошо и удобно, но приходишь на другую машину... Собственно, об этом и спорили: в git каждый заботится о себе сам, в hg девелоперы заботятся о пользователях. :)

Хотя есть и более интересные темы для споров. Скажем, как в hg увидеть переименование файлов? `hg st` их не показывает. Или чем можно заменить `hg heads` в git? ;)

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

Да, гит писался для программистов с квалификацией kernal hacker. Ghjcnsv Простым смертным не осилить.

Да ладно, у нас даже девочка-QA осиливает

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

До сих пор не могу понять, нафига нужен index?

Типичная ситуация, когда рабочая директория должна разбита на N коммитов: эта строчка чинит коммит А, другая Б, третья В, эти строчки пойдут новым коммитом, а остальные в stash или выбросить. Часто приходится построчно вырезать из одного файла на 10 временных логов одно полезное изменение с помощью git add -i. Или забрать строчку из другого коммита через git checkout -p. Или разбить коммит на несколько с помощью git reset -q.

В Git причёсывание дерева делается легко и непринуждённо.

git commit -a считаю опасной командой, с определённого времени свёл её использование к нулю. Перед каждым коммитом: git status, git diff --cached. Аж комок в горле застряёт, когда вижу новичов, отправляющих неглядя в коммит всё что нужно и ненужно, после чего приходится в Gerrit разгребать весь их локальный мусор.

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

«git commit -a», считаю, вредная команда. Она, конечно, удобна для новичков, которым главное свой хлам вбросить в репозиторий

А как же .gitignore?

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

В случае с git, это можно делать без стороних плюх, стандартными средствами.

MQ уже очень давно (несколько лет) является стандартным средством.

Очевидно, что бензопилой отпилить руку проще, чем перочинным ножиком

А тормоза придумал трус.

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

«git commit -a», считаю, вредная команда. Она, конечно, удобна для новичков, которым главное свой хлам вбросить в репозиторий

А как же .gitignore?

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

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

В случае с git, это можно делать без стороних плюх, стандартными средствами

ещё раз: для git есть примочки писанные кем попало, для hg — искаробочный плагин, поддерживаемый core developers. savvy?

Который как отдельная вселенная внутри Mercurial.

такая отдельная, что патчи видны в hg log без дополнительных телодвижений. ах да, ведь extensions API — это нечестно, потому что git в него не умеет.

в основе один механизм

DAG называется. и в hg у его ноды больше свойств. следовательно hg гибче. элементарно.

не надо иметь 10 разных наборов инструментов

попривыкали к кучке батников. инструмент тут вообще один — hg.

пилить дерево я бы предпочёл пилой

завязывайте уже с некорректными аналогиями, ок?

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

как там ртутка не тормозит?

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

Вот только в git все «бэкапы» без проблем уживаются вместе

дада, ведь всё, что вне ветки, в git как бы не существует. также обратите внимание на ключи --keep* команды rebase.

это как создание бэкапа исходников копированием в новые каталоги vs нормальная VCS

не вижу проблемы. а зарелизят obsolete changesets — будет вам и reflog.

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

Как патч распилить на два — тоже не очень понятно

тут и правда плохо. К счастью, diff -u вполне себе человекопонятен и спокойно редактируется руками.

hg qcrefresh решит проблему.

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

diff -u вполне себе человекопонятен и спокойно редактируется руками.

Вот спасибо, добрый человек.

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

В git'е с этим можно бороться так же (через механизм git stash), а можно просто не добавлять ненужные изменения в ченджсет.

Вообще, на самом деле, позицию «отрицателей удобства git add -i» можно довести до абсолюта: дерево исходников представляет из себя целостную сущность. Соответственно, возможность выбирать файлы в коммит - в принципе лишняя: надо просто коммиттить всё изменённое, а если кому что не нравится - всегда есть возможность сделать diff -u и отредактировать его руками.

По-моему, я не сильно преувеличил, а? ;)

AlexM ★★★★★
()
Последнее исправление: AlexM (всего исправлений: 2)
Ответ на: комментарий от anonymous

Хотя есть и более интересные темы для споров. Скажем, как в hg увидеть переименование файлов? `hg st` их не показывает.

“hg status -C” aka “hg status --copies”.

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

Типичная ситуация, когда рабочая директория должна разбита на N коммитов: эта строчка чинит коммит А, другая Б, третья В, эти строчки пойдут новым коммитом, а остальные в stash или выбросить. Часто приходится построчно вырезать из одного файла на 10 временных логов одно полезное изменение с помощью git add -i. Или забрать строчку из другого коммита через git checkout -p. Или разбить коммит на несколько с помощью git reset -q.

Первое так же легко делается без использования staging area. Мне мой AuRecord для таких вещей гораздо более удобен несмотря на пачку имеющихся TODO, которые очень не помешало бы иметь.

Второе и третье являются преимуществами git (я не знаю, как сделать то же в mercurial (если бы было надо, то, может быть, знал бы)), но они никак не связаны со staging area.

git commit -a считаю опасной командой, с определённого времени свёл её использование к нулю. Перед каждым коммитом: git status, git diff --cached. Аж комок в горле застряёт, когда вижу новичов, отправляющих неглядя в коммит всё что нужно и ненужно, после чего приходится в Gerrit разгребать весь их локальный мусор.

“git commit -a” никак и никогда не мог отменить review. Почему нельзя смотреть “git diff” (без “--cached”) и только затем делать “git commit -a”? Я всегда так делаю за исключением редких случаев, когда я точно знаю чего и где изменено.

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

Добавить поднабор изменённых файлов/чанков. Посмотреть, что добавлено. Добавить ещё что-то. Посмотреть. И т. д. Сделать коммит.

В mercurial это можно сделать с помощью mq. С помощью AuRecord тоже (если не надо добавлять изменения в процессе, иначе получите проблему импорта изменений в рабочий каталог), но это никак не преимущество mercurial (с subversion и git AuRecord работает точно так же).

Пока что вижу, что mq гибче. Но от его использования можно отказаться, а от staging area — сложнее.

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

В машину ты тоже на лошади заходишь?

Какая тут связь с моими проблемами?

Напоминаю систему ограничений: мне требуется коммитить
в рабочие репо на Github и при этом не шквариться об гитопарашу.
Поэтому и приходится использовать hg-git.

И это не «в машину на лошади», это «сделать удобный мягкий
салон в танке для езды по городу».

Sphinx ★★☆☆
()

Это святое, новость конечно же очень хорошая

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

hg st -C
В hg нет Ъ-переименования (по-моему, его нигде нет).

Да, я знаю, что mv — это cp+rm. И даже знаю, почему. Потому что можно один файл скопировать в несколько других, а потом удалить оригинал, и тогда это будет уже не переименование.

Но, блин, это ж не гит, он же для людей писался, так почему нельзя сделать вывод для людей? Можно же сдетектить отдельно случай, cp+rm и именно для этого случая вместо:

A newname
  oldname
R oldname
выводить что-то вроде
M oldname => newname
Но не сделали. Может, кто-то отправит патч девелоперам?

PS: что-то адепты git-а молчат, никто не скажет аналога hg heads в git...

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

можно один файл скопировать в несколько других

Идея на первый взгляд хорошая, но, когда параллельно с копированием на другом бранче в файл вносятся изменения, hg пытается смержить эти изменения во все копии %)

так почему нельзя сделать вывод для людей?

AFAIK, обоснование - не хотят ломать пользовательские скрипты, которые парсят вывод с дефолтными флагами (а изначально предлагалось что-то похожее на твою форму).

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

Э-э-э, git branch (git branch --list) ?

“hg heads” = “hg log -r 'reverse(head() and not closed())'”. Также принимает некоторые аргументы, относящиеся к формату вывода.

“git branch” лишь чуть более информативен, чем “ls -1 .git/refs/heads/**/*(^/)”.

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

Примерный эквивалент на git+*sh —

git log --no-walk $(git branch --list | sed s/..//)
. Понятия не имею, нужно ли здесь что‐то дополнительно экранировать.

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

Mercurial наше всё :)

Кому и кобыла - невеста

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

Не пойму, чем это удобней git-show-branch?

Эта не слишком информативна. И у меня, и в куче других проектов, которые я видел (не во всех конечно) (по понятным причинам, большинство проектов, которые я видел, на git), первая строчка сообщения не является кратким описанием всех изменений. Кроме того, не видно автора и даты. Возможно задавшему тот вопрос нужны ещё какие‐то сведения.

ZyX
()

И ещё в git аналог revsets не настолько функционален. Мне оно не часто нужно, но когда нужно — спасает от кучи лишних телодвижений.

+ я не нашёл в начале “git help push” того, что аргументы надо передавать ему в каком‐то особом порядке. Но:

(zyx-desktop:zyx:~/.vam/fugitive) % git push --ff-only --dry-run
error: unknown option `ff-only'
usage: git push [<options>] [<repository> [<refspec>...]]

    -v, --verbose         be more verbose
    -q, --quiet           be more quiet
    --repo <repository>   repository
    --all                 push all refs
    --mirror              mirror all refs
    --delete              delete refs
    --tags                push tags (can't be used with --all or --mirror)
    -n, --dry-run         dry run
    --porcelain           machine-readable output
    -f, --force           force updates
    --recurse-submodules[=<check>]
                          controls recursive pushing of submodules
    --thin                use thin pack
    --receive-pack <receive-pack>
                          receive pack program
    --exec <receive-pack>
                          receive pack program
    -u, --set-upstream    set upstream for git pull/status
    --progress            force progress reporting
Сказывается отсутствие API, из‐за которого приходится иметь вот это:
(zyx-desktop:zyx:~/.vam/fugitive) % file /usr/libexec/git-core/* | sed 's/[^:]*: *//' | sort | uniq -c
      1 directory
    120 ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped
      5 Perl script, ASCII text executable
     26 POSIX shell script, ASCII text executable
      1 POSIX shell script, ASCII text executable, with very long lines
      1 POSIX shell script, UTF-8 Unicode text executable
      1 Python script, ASCII text executable

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

Примерный эквивалент на git+*sh —
git log --no-walk $(git branch --list | sed s/..//)

Это не совсем то. Вопрос длиннее, чем кажется. `hg heads` используется, например, при pull-е. Скажем, есть «мой» репозиторий, от которого 3 человека сделали clone, каждый внес какие-то свои изменения, теперь я делаю у них pull и получаю что-то вроде:

$ hg pull /path/to/child1 ; hg pull /path/to/child2 ; hg pull /path/to/child3
[...]
$ hg glog --style compact
o  3[tip]:0   a0c6c15db44b   2012-10-24 14:29   user3
|    Child 3
|
| o  2:0   f3bafcbaa443   2012-10-24 14:21   user2
|/     Child 2
|
| o  1   69a598f11808   2012-10-24 14:12   user1
|/     Child 1
|
@  0   1f22005c4832   2012-10-24 14:10   me
     Parent
При этом в моем рабочем каталоге лежит все та же ревизия 1f22005c4832 (отмечена @), но в репозитории есть три «головы», по одной от каждого pull-а. Вот в этом случае `hg heads` выдаст:
$ hg heads --style compact
3[tip]:0   a0c6c15db44b   2012-10-24 14:29   user3
  Child 3

2:0   f3bafcbaa443   2012-10-24 14:21   user2
  Child 2

1   69a598f11808   2012-10-24 14:12   user1
  Child 1
Теперь я могу их merge-ить у себя как хочу. Могу смержить все по очереди, могу каждую посмотреть, смержить только два, и стрипнуть третий и т.д. Могу не мержить ни один, просто коммитить дальше, а эти три головы оставить до лучших времен.

А какой будет аналог в гите? Три pull-а он сделать не даст, на втором pull-е будет merge-конфликт, и до третьего pull-а дело просто не дойдет. Делать три fetch-а? ;) И как потом увидеть heads? Как выполнить аналогичный workflow в git?

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

Как выполнить аналогичный workflow в git?

насколько я понимаю, fetch, найти наследников 1f22 в reflog, и избирательно вмергать их в текущую ветку.

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

насколько я понимаю, fetch, найти наследников 1f22 в reflog, и избирательно вмергать их в текущую ветку.

Например? Скажем, в mercurial

$ hg pull /path/to/child1
$ hg pull /path/to/child2
$ hg pull /path/to/child3
$ hg heads
А в git?

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

Идея на первый взгляд хорошая, но, когда параллельно с копированием на другом бранче в файл вносятся изменения, hg пытается смержить эти изменения во все копии %)

Что, вообще говоря, вполне логично. :)

AFAIK, обоснование - не хотят ломать пользовательские скрипты, которые парсят вывод с дефолтными флагами (а изначально предлагалось что-то похожее на твою форму).

Дык, ёпт, пусть сделают опцию --humans, в которой будет не фиксированный, но понятный человеческому глазу вывод. В конце концов --style и --template же сделали. Что-то вроде --style compact вполне подошло бы...

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