The OpenNET Project / Index page

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

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Выпуск распределенной системы управления исходными текстами ..."
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Выпуск распределенной системы управления исходными текстами ..."  +/
Сообщение от opennews (??) on 05-Янв-16, 10:37 
После трёх месяцев разработки представлен (https://lkml.org/lkml/2016/1/4/739) релиз распределенной системы управления исходными текстами Git 2.7.0 (http://git-scm.com/). Git является одной из самых популярных, надёжных и высокопроизводительных систем управления версиями, предоставляющей гибкие средства нелинейной разработки, базирующиеся на ответвлении и слиянии веток. Для обеспечения целостности истории и устойчивости к изменениям задним числом используются неявное хеширование всей предыдущей истории в каждом коммите, также возможно удостоверение цифровыми подписями разработчиков отдельных тегов и коммитов. Из проектов, разрабатываемых с использованием Git, можно отметить ядро Linux (https://git.kernel.org/cgit/linux/kernel/git/stable/linux-st.../), 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 (https://code.qt.io/cgit/), 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/).


По сравнению с прошлым выпуском в новую версию принято  539 изменений, подготовленные при участии 81 разработчика, из которых 26 впервые приняли своё участие в разработке. Основные (https://github.com/git/git/blob/v2.7.0/Documentation/RelNote...) изменения (https://github.com/blog/2094-new-year-new-git-release):

-  Реализация нейтральной схемы заданий начальных и конечных версий в "git bisect". Изначально, так как "git bisect" создавался для выявления ревизии, в которой возникло регрессивное изменение, заведомо рабочая версия помечалась ключём "good", а версия в которой проявляется проблема - "bad". Подобное наименование вызывает замешательство при использовании "git bisect" для поиска коммита вызвавшего изменения, не связанные с ошибками, например, для выявления ревизии в которой появилась новая функциональность или  была исправлена ошибка.


Для того чтобы исключить двойное трактование в git 2.7 представлена новая схема пометки начальной и конечной точек для рецензирования: конечная точка теперь может помечаться ключом "old" (вместо good), а начальная - "new" (вместо bad). Кроме того, имена ключей можно переопределить при помощи опций "--term-old" и
"--term-new". Например, при поиске момента появления проблемы с производительностью, замеченной в ветке master, но отсутствующей в v4.2, можно выполнить:

<font color="#461b7e">
   git bisect start --term-old=fast --term-new=slow
   $ git bisect fast v4.2
   $ git bisect slow master
</font>


-  В "git push" добавлена возможность определения базовой конфигурации опции "--recurse-submodules". Например, чтобы каждый раз не запускать "git push --recurse-submodules=on-demand origin" можно внести изменения в конфигурацию по умолчанию - "git config push.recurseSubmodules on-demand", после чего выполнять "git push origin" не заботясь о субмодулях. Для временного отключения сохранённых параметров в командной строке можно указать "--no-recurse-submodules";

-  Расширение возможностей команды "git worktree", позволяющей создать несколько рабочих копий, привязанных к одному локальному Git-репозиторию. В новом выпуске представлена новая команда "git worktree list", позволяющая просмотреть рабочие копии текущего репозитория и доступные в них ветки. Появилась возможность одновременного создания разных сеансов "git bisect" для разных рабочих копий, созданных через "git worktree add". Добавлена поддержка клонирования из любой привязанной рабочей копии. Улучшена поддержка субмодулей для рабочих копий;


-  В "git p4", прослойку для помещения и извлечения изменений между Git и репозиториями Perforce, добавлена поддержка хранилища больших файлов LFS ("Git Large File Storage"). Новая возможность позволяет сохранять полученные из Perforce  большие файлы (например, мультимедийные материалы) отдельно от основного Git-репозитория, чтобы избежать чрезмерного расходования дискового пространства;

-  Проведена унификация команд для вывода ссылок. В Git предлагается три разных способа просмотра списков ссылок: git branch для вывода веток, git tag для вывода тегов и git for-each-ref для вывода ссылок на произвольные объекты. Проблема в том, что каждая из этих команд имеет свои особенности и отличается на уровне опций. В Git 2.7 для всех из этих команд предложен единый набор базовых опций, параметров форматирования вывода и сортировки. Например, добавлены следующие общие опции:


-     --points-at object - вывод любых ссылок, связанных с указанным объектом;
-     --merged [commit] - вывод только тех ссылок, которые прикреплены к коммиту (по умолчанию HEAD);
-    --no-merged [commit]: - вывод только тех ссылок, которые не прикреплены к коммиту (по умолчанию HEAD);
-     --contains [commit]: - вывод только тех ссылок, которые включают заданных коммит (по умолчанию HEAD).


-  В "git stash show" добавлена поддержка параметров конфигурацииstash.showPatch и stash.showDiff, определяющих правила показа записей по умолчанию;
-  В "git blame" обеспечена корректная работа с опцией "--first-parent" и при одновременном использовании опций "--reverse" и "--first-parent";
-  В  gitk улучшена работа на системах с экранами высокого разрешения (highDPI);
-  Устранены уязвимости: целочисленной переполнение (https://github.com/git/git/commit/92cdfd21313c5bf5657d4ac2d3...) в коде оценки изменений (diff) и неограниченное (https://github.com/git/git/commit/f2df3104ce45bc1ee6d7c16f3a...) рекурсивное извлечение субмодулей. Пользователям рекомендуется обновить Git до версий Git 2.3.10, 2.4.10, 2.5.4, 2.6.1 или 2.7.0.

URL: https://lkml.org/lkml/2016/1/4/739
Новость: http://www.opennet.me/opennews/art.shtml?num=43626

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Выпуск распределенной системы управления исходными текстами ..."  –8 +/
Сообщение от Аноним (??) on 05-Янв-16, 10:37 
С этим git bisect old/new ещё больше запутали, только привык к bad/good. Лучше бы yes/no сделали, было бы более логично.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

19. "Выпуск распределенной системы управления исходными текстами ..."  +2 +/
Сообщение от SysA on 05-Янв-16, 13:58 
> С этим git bisect old/new ещё больше запутали, только привык к bad/good.
> Лучше бы yes/no сделали, было бы более логично.

Перечитай еще раз статью, там есть: '...имена ключей можно переопределить при помощи опций "--term-old" и "--term-new"' - специально для тебя! :)

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "Выпуск распределенной системы управления исходными текстами ..."  +7 +/
Сообщение от Какаянахренразница (ok) on 05-Янв-16, 10:59 
> Из проектов, разрабатываемых с использованием 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.

Добавьте Python[1]. И ещё: уберите Minix. При всём уважении к Танненбауму, Миникс можно закапывать.

[1] http://www.opennet.me/opennews/art.shtml?num=43619

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

10. "Выпуск распределенной системы управления исходными текстами ..."  +/
Сообщение от Ph0zzy (ok) on 05-Янв-16, 11:57 
закапывать миникс?
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

11. "Выпуск распределенной системы управления исходными текстами ..."  +1 +/
Сообщение от Joe (??) on 05-Янв-16, 12:34 
Да, также как и все учебные материалы и книги, без обид но они все уже устарели)))))))))
Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

12. "Выпуск распределенной системы управления исходными текстами ..."  +8 +/
Сообщение от Какаянахренразница (ok) on 05-Янв-16, 13:02 
> Да, также как и все учебные материалы и книги, без обид но
> они все уже устарели)))))))))

Книги по алхимии годятся в качестве учебных? А ведь когда-то они считались непреложной истиной.

В качестве учебного пособия Миникс, наверное, ещё можно использовать. И в качестве музейного экспоната тоже. Но в качестве примера активного опенсорс проекта, использующего git, Миникс совсем не фонтан. Без обид.

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

13. "Выпуск распределенной системы управления исходными текстами ..."  +7 +/
Сообщение от Какаянахренразница (ok) on 05-Янв-16, 13:03 
> закапывать миникс?

Не хотите закапывать -- засушИте и отнесите в антикварную лавку.

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

16. "Выпуск распределенной системы управления исходными текстами ..."  +/
Сообщение от Igor (??) on 05-Янв-16, 13:35 
Minix3 вполне жива!
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

35. "Выпуск распределенной системы управления исходными текстами ..."  +/
Сообщение от Stax (ok) on 06-Янв-16, 15:47 
> Добавьте Python[1].

Тут список "разрабатываемых". Python разрабатывается в hg, насчет гитхаба пока только PEP с планами выпустили, а сам переход еще даже толком планировать не начали.

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

21. "Выпуск распределенной системы управления исходными текстами ..."  –3 +/
Сообщение от myhand (ok) on 06-Янв-16, 00:16 
> Расширение возможностей команды "git worktree"

Мне одному кажется как эта штука обрастает рюшечками, которые
дублируют друг друга по нескольку раз?

Вот зачем это, когда есть git stash?  (Или наоборот, зачем этот stash теперь?)

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

22. "Выпуск распределенной системы управления исходными текстами ..."  +/
Сообщение от Ytch (ok) on 06-Янв-16, 01:31 
> Вот зачем это, когда есть git stash?

Ну например, как пишут сами разработчики (https://git-scm.com/docs/git-worktree):

> You might typically use git-stash[1] to store your changes away temporarily, however, your working tree is in such a state of disarray (with new, moved, and removed files, and other bits and pieces strewn around) that you don’t want to risk disturbing any of it.

То есть, когда изменения настолько глобальны и запутанны, что stash использовать уже страшновато )))

> Или наоборот, зачем этот stash теперь?

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

Для условно небольших репозиториев и вовсе при помощи clone ненапряжно сделать тоже самое.

Не так уж, имхо, это и плохо иметь несколько способов.

P.S. А так можно ж потенциально ещё и наборы stash-ей в разных worktree одновременно! Чтоб уж путаница, так настоящая!!! )

Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

24. "Выпуск распределенной системы управления исходными текстами ..."  –1 +/
Сообщение от myhand (ok) on 06-Янв-16, 02:08 
> Ну например, как пишут сами разработчики

"Ниче не понял" (ц)

Как именно все должно быть поломано, чтобы git stash не сработал и
с какого это вдруг теперь не считается багом?

> что stash использовать уже страшновато )))

Так докатимся до того, что любую команду git будешь бояться запускать.

> Не так уж, имхо, это и плохо иметь несколько способов.

Но не до фанатизма ж!

Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

26. "Выпуск распределенной системы управления исходными текстами ..."  +/
Сообщение от Ytch (ok) on 06-Янв-16, 03:15 
> Как именно все должно быть поломано, чтобы git stash не сработал и
> с какого это вдруг теперь не считается багом?

Откуда мне знать? ) Так "пишут сами разработчики" - я лишь привел цитату их же собственного примера применения из официального man-а. Сам я не сталкивался с такими поломками (пока, по-крайней мере).

>> что stash использовать уже страшновато )))
> Так докатимся до того, что любую команду git будешь бояться запускать.

Ну это ж был немного юмор/ирония, не стоит уж настолько буквально-то...

"such a state of disarray that you don’t want to risk disturbing any of it." - "такой бардак, что ну его нафиг рисковать что-то трогать" вполне, имхо, тянет на шуточный короткий перевод типа "ссыкотно +смайл", что в чуть более культурном варианте звучит как "страшновато )))". Не вот же уж "ужас-ужас".

Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

28. "Выпуск распределенной системы управления исходными текстами ..."  +/
Сообщение от myhand (ok) on 06-Янв-16, 03:57 
> Откуда мне знать? ) Так "пишут сами разработчики"

Пишут так, что кондратий скоро хватит при прочтении.

>>> что stash использовать уже страшновато )))
>> Так докатимся до того, что любую команду git будешь бояться запускать.
> Ну это ж был немного юмор/ирония, не стоит уж настолько буквально-то...

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

> "such a state of disarray that you don’t want to risk disturbing
> any of it." - "такой бардак, что ну его нафиг рисковать что-то трогать"

Доктор, и как мне после этого git stash вообще использовать?

Не, действительно интересно что конкретно имелось в виду.

Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

29. "Выпуск распределенной системы управления исходными текстами ..."  +1 +/
Сообщение от Ytch (ok) on 06-Янв-16, 04:34 
> Не, действительно интересно что конкретно имелось в виду.

Вообще это похоже немного на трогательную заботу о тех у кого опыт с другими VCS (где ничего подобного stash либо просто нет либо вообще нетипичная практика) сильно превышает опыт с git. В тех VCS сложно придумать что-то кроме как вытащить working tree куда-нибудь в другое место, поговнофиксить там, по окончании всё грохнуть и продолжить работу. А в стрессах старые привычки никуда не денешь. А тут прям привычный workflow.

И у меня пару раз бывало подобное. После серии бесчеловечных экпериментов "отвлекся" на срочную работу, потом на очень срочную, потом на следующую и так далее... Так тихо и незаметно прошло несколько месяцев. И тут надо че-то подправить и, как это бывает, "позавчера уже должно было быть сделано". Кто бы помнил что там и в каком состоянии осталось и вообще зачем затевалось...

Добавляем к такому вот дурацкому рабочему процессу ещё и lack of git experience и понеслось...

Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

23. "Выпуск распределенной системы управления исходными текстами ..."  +/
Сообщение от anonymous (??) on 06-Янв-16, 01:53 
Но ведь stash это совсем другое.
С worktree можно сделать checkout какого-нибудь коммита не затронув файлов в текущей рабочей директории.

Типа
git branch worktree_01 <commit>
git clone --depth 1 -b worktree_01 file://<path>

Только я тож не совсем понимаю зачем это - кто-то пришел с флешкой "А дай-ка мне версию 123"?
А ты ему "git worktree add <флешка> <commit>

Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

25. "Выпуск распределенной системы управления исходными текстами ..."  +/
Сообщение от Ytch (ok) on 06-Янв-16, 03:01 
> Только я тож не совсем понимаю зачем это

Например (немного фантазирую), может иногда оказаться удобным чтоб "визуально" сравнить дерево файлов с разных веток (особенно если между ними было много переименований файлов/добавлений файлов/удалений файлов/переносов в поддиректории и т. п.) - просто чтоб наглядно и быстро оценить отличия именно в структуре файлов и их расположениях в поддиректориях. Просто быстро глянуть (может на какие-то определенные поддиректории или ещё как). В общем, где глазом оценить проще и быстрей чем всякими могучими diff-ами и т. п. Как вариант.

Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

27. "Выпуск распределенной системы управления исходными текстами ..."  –1 +/
Сообщение от myhand (ok) on 06-Янв-16, 03:47 
> Но ведь stash это совсем другое.
> С worktree можно сделать checkout какого-нибудь коммита не затронув файлов в текущей рабочей директории.

git stash # спасаем
git checkout -b worktree_01 <commit>  # достаем

ы?

Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

36. "Выпуск распределенной системы управления исходными текстами ..."  –1 +/
Сообщение от anon007 on 06-Янв-16, 16:49 
Что "ы"?

и git stash и git checkout перезапишут вам рабочую директорию.

P.S. тут http://git-scm.com/book/en/v2 (на русском http://git-scm.com/book/ru/v2)
довольно хорошая книга о git.

Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

38. "Выпуск распределенной системы управления исходными текстами ..."  +/
Сообщение от myhand (ok) on 06-Янв-16, 17:38 
> и git stash и git checkout перезапишут вам рабочую директорию.

git stash - _сохранит_ текущую рабочую директорию.

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

Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

31. "Выпуск распределенной системы управления исходными текстами ..."  +/
Сообщение от Andrey Mitrofanov on 06-Янв-16, 10:31 
> Но ведь stash это совсем другое.
> С worktree можно сделать checkout какого-нибудь коммита не затронув файлов в текущей
> рабочей директории.
> Типа
> git branch worktree_01 <commit>
> git clone --depth 1 -b worktree_01 file://<path>
> Только я тож не совсем понимаю зачем это - кто-то пришел с

Не, это облегченный локальный git slone --share! (наверное. я ж тоже не понимаю зачем. идём от "добавление уровня индирекции решает"(1)... ищем ту проблему!)  Так вот, получается же клон+чекаут вообще без директории ./.git/ в нём, да? [[[Надо смотреть, как они индексы чекау^Wворкдиров разделяют при одной .git/]]]  Можно использовать для билдов ы отдельном дереве, которое выбрасывать сразу после  -- rm--rf вместо make clean. Да, для короткоживущих ч-о не сильно проще или лучше share-клона. Наверное. Или, например, отдельные долгоживущие ч-о & ветка с фич-девелопментом без мерджа/публикации (пока~) в "master"/внеш.мир.

*(1) да, и усложняет.

> флешкой "А дай-ка мне версию 123"?
> А ты ему "git worktree add <флешка> <commit>

git clone где://то.там/должен/бы/знать/уже

Кого-кого, а _друзей_ надо держать в курсе! Особенно того, что клон-ч-о +точно+ [да, должен быть!] быстрее "прийти" и "флэшки".

Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

32. "Выпуск распределенной системы управления исходными текстами ..."  +/
Сообщение от Andrey Mitrofanov on 06-Янв-16, 11:48 
>> Но ведь stash это совсем другое.
>> Только я тож не совсем понимаю зачем это - кто-то пришел с
> Не, это облегченный локальный git slone --share! (наверное. я ж тоже не

Полистал https://duckduckgo.com/?q=why+git+worktrees+are+needed пару ответов на этот вопрос.
   http://stackoverflow.com/questions/31935776/what-would-i-use...
   ?
  
Судя по всему, "реп-один -- ч-о-много" избавляет от: 1) очистки (uor workdir is not clean) w.d. перед ч-о (или запустить билд, тест, робо-биссект, и в то жк время(!) редактировать и коммитить в рабочей w.d. -- чуть быстрее, чем с клонами? впрочем, там коммиты и пуши не нужны... О! тогда робо-биссект с робо-ребейзами на робо-тестак!!%) И публикация рибейзнутого, чтоб мёном не.);  2) не сташ = у того _нет_ w.d./ч-о (и да, stash не нужен >> w.d. ==ответ неосиляторов stash-а? %) или w-d ==ответ на нЕмощь стэша?); 3) с клоном (независито от --local/--share) всё равно для публикации/мерджа будет нужен push -- а с w.d. "та ветка" уже там... Видна и сравнима "ешё до/совсем без пуша". Наверное. 3.5) Да! Не надо держать в голове, сколько локальных клонов проекта есть -- все w.d. в отдном "флаконе".

4!) git битва: апстрим *против* хуба! https://github.com/blog/2042-git-2-5-including-multiple-work...

И да, git-worktree(1):
   ..."you can simply delete it/"
   ..."still experimental, and the support for submodules is incomplete."...

Во всех примерах w.d. сравнивают именно со stash. Так что, по-простому, вилимо, w.d. = новый stash с чекаутами и грязнымиB) деревьями. Может, это и есть гл.причина ==замена рудиментарной Ж) quilt-япки.   А может, просто (пока?) других применений я (и/или они? никто??) не нашёл.


..."мы не знаем"ТМ -- позовите Джунио?
---Наливай! //ушёд листать архив git ML

> понимаю зачем. идём от "добавление уровня индирекции решает"(1)... ищем ту проблему!)
>  Так вот, получается же клон+чекаут вообще без директории ./.git/ в
> нём, да? [[[Надо смотреть, как они индексы чекау^Wворкдиров разделяют при одной

Посмотрел: в .git/worktrees/*/ кладут "много маленьких .git/-иков. И пляшут вокруг.

> *(1) да, и усложняет.
>> флешкой "А дай-ка мне версию 123"?
>> А ты ему
> git clone где://то.там/должен/бы/знать/уже

Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

33. "Выпуск распределенной системы управления исходными текстами ..."  +/
Сообщение от myhand (ok) on 06-Янв-16, 14:32 
> Во всех примерах w.d. сравнивают именно со stash. Так что, по-простому, вилимо,
> w.d. = новый stash с чекаутами и грязнымиB) деревьями.

Заметьте, не я это предложил!

Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

34. "Выпуск распределенной системы управления исходными текстами ..."  +/
Сообщение от Andrey Mitrofanov on 06-Янв-16, 15:38 
>> Во всех примерах w.d. сравнивают именно со stash. Так что, по-простому, вилимо,
>> w.d. = новый stash с чекаутами и грязнымиB) деревьями.
> Заметьте, не я это предложил!

Не осилил, или я опять невнятен?

Попробую ещё раз: [возможно,] git-worktree - это git-stash "done right", лучше, проще и быстрее. И, вероятно, после того, как закончат вкрячивать этот +1 слой индирекции во все-все "основные" функции, git-stash объявят устаревшим и выкинут.

Ключевые, чтоб понятнее: больше, дальше, сильнее, но пока ещё не [на 100%] тут.

Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

37. "Выпуск распределенной системы управления исходными текстами ..."  –1 +/
Сообщение от anon007 on 06-Янв-16, 17:12 
> Попробую ещё раз: [возможно,] git-worktree - это git-stash "done right", лучше, проще
> и быстрее.

А мне кажется :-) что git-worktree это "расширение" возможностей веток (типа "параллельные ветки").
Пока параллельно, например, собираются версии v1, v2, v3
можно редактировать файлы в версии dev.

Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

42. "Выпуск распределенной системы управления исходными текстами ..."  +/
Сообщение от Аноним (??) on 11-Янв-16, 15:54 
> А мне кажется :-) что git-worktree это "расширение" возможностей веток (типа "параллельные
> ветки").
> Пока параллельно, например, собираются версии v1, v2, v3
> можно редактировать файлы в версии dev.

Верно, я с самого начала так git-worktree и воспринял. Мне регулярно приходится делать как раз подобное. Непонятки местных комментаторов и сравнение со stash меня удивляют.

Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

43. "Выпуск распределенной системы управления исходными текстами ..."  +/
Сообщение от Andrey Mitrofanov on 11-Янв-16, 17:21 
>> А мне кажется :-) что git-worktree это "расширение" возможностей веток
>Непонятки местных комментаторов и сравнение со stash меня удивляют.

Вкус фломастеров. Кто мы такие, чтобы развевать ваши фантазии?

<Впрочем.> Ветки, неожиданно, были "параллельными" и до того.

На локалхостике их пришлось бы "обернуть" избыточными теперь (и stash -- туда же) git-clone-ами и приседаниями с push-pull-ами  --  именно в случае одновременно живучих чекаутов.

Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

41. "Выпуск распределенной системы управления исходными текстами ..."  +/
Сообщение от Аноним (??) on 11-Янв-16, 15:51 
Это сообщение отформатировано настолько безумно, что я ничего не понял.
Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

44. "Выпуск распределенной системы управления исходными текстами ..."  +/
Сообщение от Andrey Mitrofanov on 11-Янв-16, 17:22 
> Это сообщение отформатировано настолько безумно, что я ничего не понял.

А промолчал бы -- сошёл за умного.

Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

39. "Выпуск распределенной системы управления исходными текстами ..."  –2 +/
Сообщение от Аноним (??) on 08-Янв-16, 04:42 
> Пользователям рекомендуется обновить Git до версий Git 2.3.10, 2.4.10, 2.5.4, 2.6.1 или 2.7.0

$ git --version
git version 1.9.1

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

40. "Выпуск распределенной системы управления исходными текстами ..."  +2 +/
Сообщение от myhand (ok) on 08-Янв-16, 11:51 
>> Пользователям рекомендуется обновить Git до версий Git 2.3.10, 2.4.10, 2.5.4, 2.6.1 или 2.7.0
> $ git --version
> git version 1.9.1

А некоторые племена на Земле используют каменные топоры...

Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




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

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