Здравствуйте, ., Вы писали:

.>Здравствуйте, Gaperton, Вы писали:

G>>Этой командой создается рабочая копия — то есть, слепок исходников без локальной истории. Как в SVN. Просто, и понятно. Это то, что у вас называется "склонировать одну ревизию бранча".
.>Потестил тут... Короче, эта "фича" нафиг гиту не нужна, ибо и так всё быстро работает.

Штатная возможность иметь произвольное количество рабочих копий у каждого бранча, расположенных в разных местах (в bzr это не отдельная "фича", а прямое следствие архитектуры) — неплоха вне зависимости того, как это влияет на скорость. Это элементарно удобно.

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

Здравствуйте, ., Вы писали:

.>Здравствуйте, Gaperton, Вы писали:

A>>>>>Ну, тут уж тебе решать. Минус нынешних распределённых систем контроля как раз в том, что каждый клон репа содержит всю историю, что при большой кодовой базе означает тяжеловесность в смысле занимаемого места.
G>>>>Не всех нынешних. Для bzr это не так, потому что единицей клонирования являются отдельные бранчи, а не репозиторий. Копирования всей истории при этом в общем случае не происходит, если в том же репозитории эта история есть у любого из бранчей.
.>>>А в каких нет? git тоже умеет,
G>>Ага. А когда я второй бранч того же проекта таким образом захочу "склонировать" — он ляжет в другой репозиторий, и у меня еще разок полностью прокачается его полная история. Удобно.
.>Зачем? Закачай бранч в тот же репо, скачаются только отсутствующие коммиты.

Хм. Напугай меня . Приведи листинг заклинаний git-а, который это выполнит.

В bzr все просто до скуки.

Один раз делаешь вот это:

D:
cd \
bzr init-repo

После чего ты надолго забываешь про то, что такое "репозиторий", и тебе за это ничего не будет. Ибо у тебя все локальные бранчи, расположенные на диске D, разделяют свою историю. Всегда. Автоматически. И никогда не качается ничего лишнего по сети. И никогда ничего лишнего не копируется. И тебе ничего не надо для этого знать, и не надо ни за чем следить.

Что мне надо знать, чтобы добиться аналогичного в git?

.>>>умеет даже круче — клонировать только одну ревизию, вообще без истории (bzr вроде так не умеет).
G>>В bzr понятия бранча, репозитория, и рабочей копии полностью независимы, и ими очень просто манипулировать раздельно. В отличии от.
.>Тоже есть shared repository. Рабочая копия, репозиторий и индекс тоже можно разделить. Только непонятно зачем — клоны могут использовать хардлинки для легковесности.

G>>bzr chechout --lightweight branch_path working_copy_path
.>git clone -b branchName git_repo_on_same_filesystem

Это клонирование репозитория, а не вынимание рабочей копии. Т.е. аналог элементарного bzr branch.

.>Правда не представляю накой такое нужно.

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

...вдруг у тебя не same filesystem, а remote? Допустим, у меня большой объем, медленная сеть, и мне история не нужна?

Кстати, а что будет с хардлинками под вендой?

.>Обычно бранчи переключать приходится в одном и том же месте, т.к. всё окружение настроено туда.

bzr switch, если что . А то некоторые думают, что bzr этого не умеет.

G>>Этой командой создается рабочая копия — то есть, слепок исходников без локальной истории. Как в SVN. Просто, и понятно. Это то, что у вас называется "склонировать одну ревизию бранча".
.>Этой командой, если та же файловая система создаётся легковесный клон, работает быстро, даже с локальной историей.

Твоя команда — это, еще раз, аналог bzr branch. Кстати — по вендой эта штука тоже работает? А на флешке с FAT — работает? А по сети — тоже работает?

А вот checkout --lightweight всегда работает, во всех контекстах.

Здравствуйте, Gaperton, Вы писали:

G>Штатная возможность иметь произвольное количество рабочих копий у каждого бранча, расположенных в разных местах (в bzr это не отдельная "фича", а прямое следствие архитектуры) — неплоха вне зависимости того, как это влияет на скорость. Это элементарно удобно.
Дело привычки. За мою историю использования cvs,svn,git я создавал максимум 2-3 рабочие копии. Переключать одну на разные бранчи — быстрее это точно, и, по-моему, гораздо удобнее.

G>Данная фича полезна для быстрого вынимания из репозитория конкретной ревизии по нужде, с целью, например, воспроизведения ошибки, проявляющейся в конкретной версии. Создать рабочую копию, вынув из репа исходники — это естественно и понятно. Клонировать в этой ситуации репозиторий, потому что это "быстро работает" — контринтуитивно как-то.
А если вперёд-назад по коммитам походить захочешь, что-то поменять там чуть, а потом помержить туда-сюда?

G>Хм. Напугай меня . Приведи листинг заклинаний git-а, который это выполнит.
Ну.... поехали.
1. Сосредоточиться.
2. Потереть руки.
3. Подумать о душе.
4. git fetch origin branch
5. ...
6. Profit!

Да, действительно очень страшно. Ты спать теперь спокойно будешь?

G>В bzr все просто до скуки.
Фу, скучный этот ваш bzr.

G>Один раз делаешь вот это:
G>

G>D:
G>cd \
G>bzr init-repo
G>

G>После чего ты надолго забываешь про то, что такое "репозиторий", и тебе за это ничего не будет. Ибо у тебя все локальные бранчи, расположенные на диске D, разделяют свою историю. Всегда. Автоматически. И никогда не качается ничего лишнего по сети. И никогда ничего лишнего не копируется. И тебе ничего не надо для этого знать, и не надо ни за чем следить.
В смысле? Ты с нуля что ли репо создаёшь, не забираешь чьи-то исходники? В гите это делается даже короче на 5 символов:
git init
остальное — то же самое.

G>Что мне надо знать, чтобы добиться аналогичного в git?
Да вроде ничего особенного, доки прочитать, найти синтаксис аналогичных команд.

.>>git clone -b branchName git_repo_on_same_filesystem
G>Это клонирование репозитория, а не вынимание рабочей копии. Т.е. аналог элементарного bzr branch.
А какая принципиальная разница?

Вопрос в том, а надо ли вынимать по бранчам — ибо бранчи сильно не отличаются и растут друг из друга, а значит "все бранчи" vs "1 бранч" по объёму репо обычно различается незначительно.

.>>Правда не представляю накой такое нужно.
G>Ну мало ли зачем. Например, вытащить несколько разных ревизий из одного бранча одновременно. Или...
ревизии и бранчи в git ничем не отличаются практически. Бранч это human-made метка ревизии, которую можно переставлять.

G>...вдруг у тебя не same filesystem, а remote? Допустим, у меня большой объем, медленная сеть, и мне история не нужна?
G>Кстати, а что будет с хардлинками под вендой?
Я посмотрел, оказывается там тупо путь к источнику указывается. Создаётся файлик ".git\objects\info\alternates" с содержимым "C:/work/git/main_repo/.git/objects" (objects в git это типа БД всех коммитов).
Что-то уже перестал понимать накой там хардлинки... Могу предположить, что для создания независимых клонов.

G>>>Этой командой создается рабочая копия — то есть, слепок исходников без локальной истории. Как в SVN. Просто, и понятно. Это то, что у вас называется "склонировать одну ревизию бранча".
.>>Этой командой, если та же файловая система создаётся легковесный клон, работает быстро, даже с локальной историей.
G>Твоя команда — это, еще раз, аналог bzr branch. Кстати — по вендой эта штука тоже работает? А на флешке с FAT — работает? А по сети — тоже работает?
Сам не пробовал, но судя по тому, что я увидел как оно устроено внутре — должно.

Здравствуйте, ., Вы писали:

G>>Штатная возможность иметь произвольное количество рабочих копий у каждого бранча, расположенных в разных местах (в bzr это не отдельная "фича", а прямое следствие архитектуры) — неплоха вне зависимости того, как это влияет на скорость. Это элементарно удобно.
.>Дело привычки. За мою историю использования cvs,svn,git я создавал максимум 2-3 рабочие копии. Переключать одну на разные бранчи — быстрее это точно, и, по-моему, гораздо удобнее.

Это у вас в гите все кругом дело привычки. А в bzr можно выбирать между обоими способами по ситуации.

G>>Данная фича полезна для быстрого вынимания из репозитория конкретной ревизии по нужде, с целью, например, воспроизведения ошибки, проявляющейся в конкретной версии. Создать рабочую копию, вынув из репа исходники — это естественно и понятно. Клонировать в этой ситуации репозиторий, потому что это "быстро работает" — контринтуитивно как-то.
.>А если вперёд-назад по коммитам походить захочешь, что-то поменять там чуть, а потом помержить туда-сюда?

Можно и так. В чекаут, который out of date (именно таким чекаутом будет легковесная рабочая копия старой ревизии), коммитить нельзя. И это правильно. Но никто не мешает его изменить, и сказать ему перед коммитом update, чтобы он нагнал текущее время, и аккуратно протащил сквозь время локальные изменения.

G>>Хм. Напугай меня . Приведи листинг заклинаний git-а, который это выполнит.
.>Ну.... поехали.
.>1. Сосредоточиться.
.>2. Потереть руки.
.>3. Подумать о душе.
.>4. git fetch origin branch
.>5. ...
.>6. Profit!

.>Да, действительно очень страшно. Ты спать теперь спокойно будешь?

Разумеется страшно. Ты применяешь как минимум две разных команды, мануал по второй из которых выносит неподготовленному человеку мозг,

git clone -b a repo_uri
git fetch origin b

а я обхожусь одной.

bzr branch a_uri a
bzr branch b_uri b

Но вы, фанаты гита, такие отважные парни. Ничего не боитесь.

G>>В bzr все просто до скуки.
.>Фу, скучный этот ваш bzr.

Зато ваш гит веселый, обхохочешься.

G>>Один раз делаешь вот это:
G>>

G>>D:
G>>cd \
G>>bzr init-repo
G>>

G>>После чего ты надолго забываешь про то, что такое "репозиторий", и тебе за это ничего не будет. Ибо у тебя все локальные бранчи, расположенные на диске D, разделяют свою историю. Всегда. Автоматически. И никогда не качается ничего лишнего по сети. И никогда ничего лишнего не копируется. И тебе ничего не надо для этого знать, и не надо ни за чем следить.
.>В смысле? Ты с нуля что ли репо создаёшь, не забираешь чьи-то исходники?
.>В гите это делается даже короче на 5 символов:

В гите аналогичная операция не делается вообще. Там другая концепция репозитория.

G>>Что мне надо знать, чтобы добиться аналогичного в git?
.>Да вроде ничего особенного, доки прочитать, найти синтаксис аналогичных команд.

То есть, ты не знаешь. Понятно.

.>>>git clone -b branchName git_repo_on_same_filesystem
G>>Это клонирование репозитория, а не вынимание рабочей копии. Т.е. аналог элементарного bzr branch.
.>А какая принципиальная разница?

Принципиальная разница в том, что это совсем разные вещи, не имеющие между собой ничего общего. Бранч может не иметь рабочей копии. Или иметь их тысячу. Одна рабочая копия может переключатся между разными бранчами. Операция на бранче не обязана обновлять его рабочие копии, даже если они у бранча есть.

.>Вопрос в том, а надо ли вынимать по бранчам — ибо бранчи сильно не отличаются и растут друг из друга, а значит "все бранчи" vs "1 бранч" по объёму репо обычно различается незначительно.

Ну, я уже привел примеры ситуаций, зачем это может быть нужно.

.>>>Правда не представляю накой такое нужно.
G>>Ну мало ли зачем. Например, вытащить несколько разных ревизий из одного бранча одновременно. Или...
.>ревизии и бранчи в git ничем не отличаются практически. Бранч это human-made метка ревизии, которую можно переставлять.

Какая разница, как оно там внутри — одно и тоже, или не одно и тоже, если с человеческой точки зрения понятия разные.

G>>...вдруг у тебя не same filesystem, а remote? Допустим, у меня большой объем, медленная сеть, и мне история не нужна?
G>>Кстати, а что будет с хардлинками под вендой?
.>Я посмотрел, оказывается там тупо путь к источнику указывается. Создаётся файлик ".git\objects\info\alternates" с содержимым "C:/work/git/main_repo/.git/objects" (objects в git это типа БД всех коммитов).

Где — там? Зачем указывается? Какой от этого прок?

.>Что-то уже перестал понимать накой там хардлинки... Могу предположить, что для создания независимых клонов.

Это фича файловой системы, пользуясь которой git ускоряет тебе клонирование на локальной ФС.

Thanks to hardlinking, local clones require less time and space than a plain backup.

G>>>>Этой командой создается рабочая копия — то есть, слепок исходников без локальной истории. Как в SVN. Просто, и понятно. Это то, что у вас называется "склонировать одну ревизию бранча".
.>>>Этой командой, если та же файловая система создаётся легковесный клон, работает быстро, даже с локальной историей.
G>>Твоя команда — это, еще раз, аналог bzr branch. Кстати — по вендой эта штука тоже работает? А на флешке с FAT — работает? А по сети — тоже работает?
.>Сам не пробовал, но судя по тому, что я увидел как оно устроено внутре — должно.

Cудя потому, что я знаю про то, как оно устроено (а оно устроено на хардлинках), с перечисленным мной выше у git будут определенные проблемы.

Здравствуйте, Gaperton, Вы писали:

G>>>Штатная возможность иметь произвольное количество рабочих копий у каждого бранча, расположенных в разных местах (в bzr это не отдельная "фича", а прямое следствие архитектуры) — неплоха вне зависимости того, как это влияет на скорость. Это элементарно удобно.
.>>Дело привычки. За мою историю использования cvs,svn,git я создавал максимум 2-3 рабочие копии. Переключать одну на разные бранчи — быстрее это точно, и, по-моему, гораздо удобнее.
G>Это у вас в гите все кругом дело привычки. А в bzr можно выбирать между обоими способами по ситуации.
В git тоже. Я говорю, что мне удобнее в одном каталоге держать и переключаться. Сделать можно несколько, но не понимаю зачем. Для svn/cvs — я понимал, т.к. тормозило. В git — не тормозит, поэтому делаю как удобно.
Судя по этому, bzr в таком сценарии работает в 80 раз медленнее. Если правда, то понятно, что тебе приходится "выбирать" по ситуации.

G>Можно и так. В чекаут, который out of date (именно таким чекаутом будет легковесная рабочая копия старой ревизии), коммитить нельзя. И это правильно. Но никто не мешает его изменить, и сказать ему перед коммитом update, чтобы он нагнал текущее время, и аккуратно протащил сквозь время локальные изменения.
Ты же так выбор любишь, а тут то нелзья, сё нельзя. В гите можно и закоммитить, а потом замержить, или сделать новую ветку потом, или делать rebase для "протаскивания времени", или тупо выбросить и забыть, если лажа вышла.

G>Разумеется страшно. Ты применяешь как минимум две разных команды, мануал по второй из которых выносит неподготовленному человеку мозг,
А что делать — фич очень много, я знаю наверное только половину, реально использовал наверное только треть. Но наличие неизвестных фич не мешает использовать удобные.

G>

G>git clone -b a repo_uri
G>git fetch origin b
G>

G>а я обхожусь одной.
git clone repo_uri
делается один раз для проекта (аналог bzr init-repo с вытягиванием данных из удалённого репо одной командой). За кулисами делается примерно следующее:
git init (новый репо, создание каталога ".git")
git remote add origin repo_url(говорим гиту, что хотим работать с удалённым репо repo_url, можно работать с несколькими одновременно)
git fetch origin (выкачиваем содержимое по сети)
git checkout master (в рабочую копию помещаются файлы из ветки удалённой master).
Как-то так.
clone это просто удобная процедурка, совмещающая кукчу boilerplate команд.

G>

G>bzr branch a_uri a
G>bzr branch b_uri b
G>

потом "git checkout a", "git checkout b". Вытаскивать бранчи отдельно смысла нет.

Ты просто нештатный юскейс спросил. Так под гитом делать можно, опускаясь до более low-level команд, но нафиг не нужно.

G>Зато ваш гит веселый, обхохочешься.
А что, плакать что-ли?

G>В гите аналогичная операция не делается вообще. Там другая концепция репозитория.
Опиши, плз. Или ссылку хорошую хотя бы...

G>>>Что мне надо знать, чтобы добиться аналогичного в git?
G>То есть, ты не знаешь. Понятно.
Не знаю чего именно ты хочешь добиться. Если тупо чтобы git работал как bzr, то я думаю это невозможно по понятным причинам. А "как решить проблему А" — может и знаю, если что, могу и нагуглить.

.>>>>git clone -b branchName git_repo_on_same_filesystem
G>>>Это клонирование репозитория, а не вынимание рабочей копии. Т.е. аналог элементарного bzr branch.
.>>А какая принципиальная разница?

G>Принципиальная разница в том, что это совсем разные вещи, не имеющие между собой ничего общего. Бранч может не иметь рабочей копии. Или иметь их тысячу. Одна рабочая копия может переключатся между разными бранчами. Операция на бранче не обязана обновлять его рабочие копии, даже если они у бранча есть.
Я имею в виду чем клонирование репо в новый каталог с созданием рабочей копии там же отличается от "вынимания рабочей копии".

.>>Вопрос в том, а надо ли вынимать по бранчам — ибо бранчи сильно не отличаются и растут друг из друга, а значит "все бранчи" vs "1 бранч" по объёму репо обычно различается незначительно.
G>Ну, я уже привел примеры ситуаций, зачем это может быть нужно.
Ты привёл ситуацию, когда нужно взять либо только бранч А, либо только бранч Б для экономии (?) трафика, места. В гите можно сразу взять все бранчи А-Я и быстро переключаться между ними по желанию левой пятки, экономить ничего не надо.
Или ты о чём?

.>>>>Правда не представляю накой такое нужно.
G>>>Ну мало ли зачем. Например, вытащить несколько разных ревизий из одного бранча одновременно. Или...
.>>ревизии и бранчи в git ничем не отличаются практически. Бранч это human-made метка ревизии, которую можно переставлять.
G>Какая разница, как оно там внутри — одно и тоже, или не одно и тоже, если с человеческой точки зрения понятия разные.
С человеческой точки зрения тоже нет принципиальной разницы — бранч называется "my_experiments", ревизия называется "74b817e". Просто удобнее имя, все команды понимают одинаково и то, и то.

G>>>...вдруг у тебя не same filesystem, а remote? Допустим, у меня большой объем, медленная сеть, и мне история не нужна?
G>>>Кстати, а что будет с хардлинками под вендой?
.>>Я посмотрел, оказывается там тупо путь к источнику указывается. Создаётся файлик ".git\objects\info\alternates" с содержимым "C:/work/git/main_repo/.git/objects" (objects в git это типа БД всех коммитов).
G>Где — там? Зачем указывается? Какой от этого прок?
В shared-клоне. Этот клон — легковесный, он не содержит данных, а просто путь к ним. Но при этом он полнофункиональный — все ветки, мержи как хочешь, етс.

.>>Что-то уже перестал понимать накой там хардлинки... Могу предположить, что для создания независимых клонов.
G>Это фича файловой системы, пользуясь которой git ускоряет тебе клонирование на локальной ФС.
G>

G>Thanks to hardlinking, local clones require less time and space than a plain backup.

Вот я и говрю, shared-клон зависим от основного — если он сломается/потеряется, то кирдык. Но для флешек/фат — самое то. А hardlinking клон — работает в пределах одной ФС, создаёт независимые клоны — бекап.

G>>>>>Этой командой создается рабочая копия — то есть, слепок исходников без локальной истории. Как в SVN. Просто, и понятно. Это то, что у вас называется "склонировать одну ревизию бранча".
.>>>>Этой командой, если та же файловая система создаётся легковесный клон, работает быстро, даже с локальной историей.
G>>>Твоя команда — это, еще раз, аналог bzr branch. Кстати — по вендой эта штука тоже работает? А на флешке с FAT — работает? А по сети — тоже работает?
.>>Сам не пробовал, но судя по тому, что я увидел как оно устроено внутре — должно.

G>Cудя потому, что я знаю про то, как оно устроено (а оно устроено на хардлинках), с перечисленным мной выше у git будут определенные проблемы.
Нет, shared клон содержит просто путь, нету никаких хардлинков.

Парни, вы вот лучше скажите, какой стороной ножа нужно бить яйцо?
Тупой или острой?