MS уехала на Git

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

:D Просто есть люди и их мнение всегда субъективно, кому то нравиться Lin кому то win. А самый первый оратор сказал что «винда на десктопе лучше и удобнее линукса». От того и прыгаем потому что нет ничего самого лучшего и удобного в абсолюте, но всегда есть исключения в частности. )

тогда в вашем мире это не факт - и это очевидно, ведь факт не может быть ложью.

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

такое ощущение, что вы пытаетесь ввести нас в заблуждение. но зачем?

Такое ощущение, что думать стало совсем не модно.

EEE планируется?

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

GVFS?

Открыта.
Исходники на Гитхаб.

А у меня венда вообще в сон не входила, а после апдейта стало нормально. Совпадение? Не думаю.

В убунте со сном ни разу проблем не было.

Всего на Git переведено около 3500 разработчиков

и включает 4400 активных веток

Может я отстал от жизни, но в чем смысл? Веток больше чем разрабов. Зачем?

В оригинальной английской статье 440 веток.

GVFS?

Открыта.
Исходники на Гитхаб.

Это плохо?

TFS поддерживает и TFVC репозиторий, и Git репозитории. Так что от TFS они не отказывались. Наоборот. Раньше они свой TFVC не использовали (и поэтому не использовали TFS), теперь используют TFS с Git репозитариями. В оригинальной статье говорится о том, что для больших пул реквестов (порядка 1000 файлов) пришлось оптимизировать веб интерфейс пул реквестов. Упоминались также десятки тысяч билдов верификации пул реквестов в день. Это все функциональности TFS.

Вы привели как вариант закрытой системы, я поправил.

Вы привели как вариант закрытой системы, я поправил.

Спасибо. Но я не приводил его как пример закрытой системы. Я приводил gvfs в ответ на «Получится Git, но другой, к которому уже не подцепишься оригинальным клиентом.». С надеждой, что gvfs может стать катализатором для git и в нем появится подобная функциональность.

И назовут её VaziLindows XY
где XY - это римское обозначение очередной «последней» версии оффтопика, введённое указом Билла III.

Вы ответили на

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

Как можно так сделать открытой?

С надеждой, что gvfs может стать катализатором для git и в нем появится подобная функциональность.

Зачем GVFS в git?

Лучше б они уехали в закат. Ну или Марс покорять.

Вы ответили на

Я уже написал, на что я ответил.

Зачем GVFS в git?

Затем, что бы не тянуть гигабайты репозитория.

Для этого есть GVFS

Тянуть все в VCS по моему не разумно.

Для этого есть GVFS

Я правильно понимаю, что она исключительно windows-only?

Тянуть все в VCS по моему не разумно.

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

Я правильно понимаю, что она исключительно windows-only?

Да
Но если кому то интересно, то можно поритровать или написать свой тул.

Все пихать в Гит по моему мнению плохая идея.

Все пихать в Гит по моему мнению плохая идея.

Все дело в том, что gvfs - это «фильтр» файловой системы, а-ля один из компонентов ibm tivoli.

Не понял о чем вы, но не вижу аргументов в пользу того что Гит должен уметь изображать ФС

Не понял о чем вы, но не вижу аргументов в пользу того что Гит должен уметь изображать ФС

Я не говорил, что git должен уметь изображать FS. Я говорил, что он должен уметь предоставить возможность получить срез нужного бранча.

В майкрософт решили, что лучший путь - это gvfs. Но это не значит, что это единственно правильная реализация.

Безусловно, если мне это ни разу не понадобилось это не говорит что это ненужная фича, но может быть вы выбрали неподходящий VCS?

Безусловно, если мне это ни разу не понадобилось это не говорит что это ненужная фича,

Угу.

но может быть вы выбрали неподходящий VCS?

А Торвальдс тоже выбрал/написал неподходящий vcs для ядра?

Он написал подходящий для себя и того как он представляет разработку.

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

Но если вам нужны фичи которых в принципе не может быть в Гите,

Почему такой фичи в принципе быть не может в гите? Завтра разработчики гита вдохновятся идеей gvfs и реализуют что-то подобное.

скорее всего вам Гит не поодходит.

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

Почему такой фичи в принципе быть не может в гите?

Потому что он изначально создавался для других целей.

Если нужен принципиально другой VCS то его и используют

Завтра разработчики гита вдохновятся идеей gvfs и реализуют что-то подобное.

Нуну ;)

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

Пользуйтесь --depth, Luke

git clone --depth <depth> -b <branch> <repo_url>

На самом деле Микрософт как обычно взял хорошую идею (Git) и обосрал её своими NIH настройками (Git virtual file system, GVFS). Эта настройка работает только под Windows 10 и нуждается в Visual Studio Team System. В общем, типичный embrace and extend от MS.

Потому что он изначально создавался для других целей.

А как изменится цель от возможности снимать только вершину бранча?

Если нужен принципиально другой VCS то его и используют

Да не нужен принципиально другой. Что вы заладили с другим vcs?

Нуну ;)

Я этого не утверждаю, но допускаю.

Пользуйтесь --depth, Luke

Это не совсем то, что предлагает gvfs.

Это не совсем то, что предлагает gvfs.

Но вы ведь именно это просили в предыдущем посте ;)

Но вы ведь именно это просили в предыдущем посте ;)

Нет.

Даже МС оценила удобство гита...

А это вы писали

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

?

Да, я написал. Что делать, если понадобится переключиться на другой бранч, посмотреть лог? В случае с gvfs все это возможно.

Да, я написал

Но ведь --depth удовлетворяет тому что вы написали.

Что делать, если понадобится переключиться на другой бранч, посмотреть лог?

Скачать все репо

Но ведь --depth удовлетворяет тому что вы написали.

А возможность переключиться на ветку/коммит ниже вершины, указанной в --depth?

Скачать все репо

Ну значит не удовлетворяет тому, о чем я говорю.

А возможность переключиться на ветку/коммит ниже вершины, указанной в --depth?

Укажите ещё ниже.

Ну значит не удовлетворяет тому, о чем я говорю.

Так вы на ходу выдумываете новые сценарии.

Но никто вам не мешает портировать GVFS на что хотите.

Укажите ещё ниже.

И как мне во время клонирования узнать будущее?

Так вы на ходу выдумываете новые сценарии.

Почему, именно такой сценарий предлагает gvfs. Именно о нем идет речь.

Но никто вам не мешает портировать GVFS на что хотите.

Я этого и не отрицал.

И как мне во время клонирования узнать будущее?

Никак
Но неужели вы думаете что GVFS вам поможет его узнать?
Нет
Также как гит будет копировать версии.

Я этого и не отрицал.

Чуть выше вы говорили что это нужно в Гит засунуть.

Но неужели вы думаете что GVFS вам поможет его узнать?

GVFS поможет мне об этом не думать, а получать то, что мне нужно в данный момент. Для меня работа с репозиторием становится прозрачной (да, как в ibm tivoli).

Чуть выше вы говорили что это нужно в Гит засунуть.

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

GVFS поможет мне об этом не думать, а получать то, что мне нужно в данный момент. Для меня работа с репозиторием становится прозрачной (да, как в ibm tivoli).

А без GVFS работа с репозиторием совсем непрозрачная?

GVFS - это костыль. Без него на виндах `git status` на большом количестве файлов тормозит по-страшному, потому что NTFS - это куча говна. Вместо того, чтобы lstat (или его эквивалент) в NTFS фиксить, в MS сооружают костыли, которые никогда не будут работать (да и нужны вообще) на других платформах.

А без GVFS работа с репозиторием совсем непрозрачная?

Прозрачная, но нужно тянуть весь репозиторий. GVFS позволяет тянуть только то, что нужно в данный момент.

GVFS - это костыль.

Спору нет, потому и хотелось бы нечто подобное получить из коробки в гите.

Нафиг в гите это не нужно. Похоже, Микрософт, как и ты, не поняли идею гита, и упорно хотят прикрутить к нему сервер, чтобы как в SVN было или Perforce, где без сервера никуда.

Нафиг в гите это не нужно.

Не нужно потому... что так решил rupert. Ну ок.

Похоже, Микрософт, как и ты, не поняли идею гита,

И какова же идея гита?

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

Сервер в реализации gvfs вторичен и используется для кеширования.