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

BFE>>Всё что мне нужно — это одна версия файла лежащего в двух разных каталогах.
S>Совпдающие версии — это частный случай. В общем случае тут разговор просто про зависимость от другого репозитория. Правильное решение это когда версия указана явно, а не "последняя по умолчанию".

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

Другое дело, что значительная часть идеологии git держится на механизме pull request'ов, а они не совсем прямо с самообновляющимися подрепозитариями дружат...

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

S>Не могу поддержать этот спор, т.к. о заработках таксистов знаю через третьи руки. Сомнения про Москву проистекают из банальных соображений: стоимость жизни. Таксисту в Москве надо оплачивать аренду квартиры или ипотеку, плюс лизинг автомобиля. Это ж не Тында — за 5000р ты квартиру не снимешь. Так что если у них "потолок" 60к, то непонятно, как они вообще выживают.

Они могут снять себе квартиру на пятерых.

S>И почему не идут, например, в машинисты метро — там всё обклеено объявлениями, где з.п. начинается от 80к.

Полагаю, в метро их не берут: с гражданством не повезло. Те, кому повезло с гражданством, среди таксистов встречаются редко.

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

SVZ>>С CVS или SourceSafe и его клонами доводилось работать?
В>Я скорее с Hg+черепаха сравниваю.

К hg есть плагинчик, который позволяет ему работать с git'овскими репозиториями, как с родными.

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

В>>Ведь ломкое, не для средних умов и относительно нормально работает только в консоли. Ужас.

M>Потому что на фоне всех альтернатив он летал, как реактивный самолет на стероидах. Пока тот же SVN туго соображал, куда он вчера закинул лапти, git успевал слить сотню мегабайтов апдейтов с сервера, смерджить их, и залить все обратно на сервер.

Я не сказал бы, что он летает сильно шустрее hg. Скорее даже медленнее, в некоторых операциях.

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

_>Ну например Mercurial лучше практически во всём. )

Тогда непонятно, в чем проблема. К hg есть плагинчик, позволяющий ему работать с git'овскими репозиториями. Я тоже привык к hg, если мне приходится с кем-то работать, кто использует git, я просто применяю этот плагинчик, и работаю в hg, а другим это не заметно.

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

BFE>>В git нельзя сделать копию файла с сохранением истории.

SVZ>А можно юзкейс когда это требуется?

Да. Вот у нас был исходный файл, потом он распух, и мы решили разбить его на несколько. У всех этих файлов общая предыстория, было бы разумно ее сохранить при разбиении.

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

K>Строго говоря, там и "побеждать" особо нечему — завтра первый же проект-выскочка сделает работу проще и хомячки забросят торвальдсовскую кокажку и начнут юзать новый тул. Просто время нормальных DVCS ещё не пришло, не написал никто.

Не забросят, потому что legacy в виде кучи кода в гитхабе.

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

AN>>>Может быть. CVS и SVN появились раньше, но после появления Git большинство постепенно перешло на него.
K>>Сравнил лисапед с камазом! Время "просто VCS" прошло с первым же DVCS проектом.
C>Первый коммерческий DVCS — это BitKeeper. Не взлетел. Первый более-менее распространённый свободный DVCS — это TLA (Tom Lord's Arch), он был таким невменяемым, что git там даже близко по сложности использования не стоял.

Мне кажется, если бы BitKeeper в свое време не поссорился с Торвальдсом, то и BitKeeper бы взлетел, и git'а бы никакого не было.

В общем, хороший проект был убит идиотским административным решением.

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

K>>Что навскидку помню, так это бесконечная игра в мержи — кто первый закоммитил, с того как с гуся вода, а остальные вынуждены заливать его изменения, соединять (даже если файлы вообще НЕ ПЕРЕСЕКАЮТСЯ!), и только потом заливать на сервер.

N>Принципиальная проблема DVCS. При чём тут конкретный инструмент? Или ты хочешь кнопку "зателепай мне хорошо"? Ну хоти дальше...

Эта проблема отчасти решается автоматизацией мержев. Уж если изменения не пересекаются по файлам, merge должен быть тривиален...

N>В Git у тебя будет в таком варианте конфликт при pull, и ты увидишь, что что-то изменилось со стороны. А что, Hg такое не детектит? Говоришь, "прекрасный тул"?

У hg будет конфликт при push.

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

D>У меня git отлично работает в SourceSafe и Fork. Fork, увы, пока с субмодулями не умеет, но в остальном шустрее SourceSafe в разы.

Даже CVS в большинстве случаев была быстрее SourceSafe в разы.

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

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

E>В частности, гит мог бы давать возможность выбора, как оно будет в каждом конкретном случае...
Так он и дает Сейчас можно и так и этак

E>Другое дело, что значительная часть идеологии git держится на механизме pull request'ов, а они не совсем прямо с самообновляющимися подрепозитариями дружат...
+1 Именно поэтому в гите раньше и надо было явно указывать. Сейчас есть опция "следовать за головой".

S>Он действительно не прост и выше я уже писал, что можно понять уровень кандидата обсуждая с ним работу гита: dag, абстракции(коммит, ветка, тэг), алгоритмы слияния и т.д.
Я когда был студентом, работал в стартапе, где разрабатывали в то числе и систему версию, да, я лично участвовал в написании этих хитрых алгоритмов, мониторинге дисковой активности и пр.

А гит терпеть не могу. Какой мой уровень?

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

D>>У меня git отлично работает в SourceSafe и Fork. Fork, увы, пока с субмодулями не умеет, но в остальном шустрее SourceSafe в разы.
Pzz>Даже CVS в большинстве случаев была быстрее SourceSafe в разы.

АЙ ПЕРЕПУТАЛ

SourceTree, это клиент для гита guiшный.

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

C>>Первый коммерческий DVCS — это BitKeeper. Не взлетел. Первый более-менее распространённый свободный DVCS — это TLA (Tom Lord's Arch), он был таким невменяемым, что git там даже близко по сложности использования не стоял.
Pzz>Мне кажется, если бы BitKeeper в свое време не поссорился с Торвальдсом, то и BitKeeper бы взлетел, и git'а бы никакого не было.
К моменту ссоры BK уже существовал 6 лет. Не взлетал.

Pzz>В общем, хороший проект был убит идиотским административным решением.
Я его использовал (для работы с кодом MySQL). Он был ну уж очень неудобным.

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

Pzz>>В общем, хороший проект был убит идиотским административным решением.
C>Я его использовал (для работы с кодом MySQL). Он был ну уж очень неудобным.

Хм. А Торвальдсу нравился.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Удобнее для чего? Если для пользователей, то им наплевать и и как правил ты в коде, им важно какие user stories и баги закрыты. А это инфа в трекере куда как в лучшем виде присутствует.

Удобнее для разработчика.

Идею о том, что изменения в сорсконтроле должны иметь взаимно-однозначное соответствие с изменениями тикетов в трекере придумана идиотами-менеджерами, которые сроду не писали софта.

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

Pzz>Идею о том, что изменения в сорсконтроле должны иметь взаимно-однозначное соответствие с изменениями тикетов в трекере придумана идиотами-менеджерами, которые сроду не писали софта.

Так про то и речь, что тикеты лучше.

Здравствуйте, Ночной Смотрящий, Вы писали:

Pzz>>Идею о том, что изменения в сорсконтроле должны иметь взаимно-однозначное соответствие с изменениями тикетов в трекере придумана идиотами-менеджерами, которые сроду не писали софта.

НС>Так про то и речь, что тикеты лучше.

Они не лучше и не хуже. Они другие.

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

Pzz>>>В общем, хороший проект был убит идиотским административным решением.
C>>Я его использовал (для работы с кодом MySQL). Он был ну уж очень неудобным.
Pzz>Хм. А Торвальдсу нравился.
Ему нужна была распределённая VCS, и на то время (2001-й год) не было выбора.

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

НС>>Так про то и речь, что тикеты лучше.
Pzz>Они не лучше и не хуже. Они другие.

Они больше подходят для release notes