_>и конечно же для таких юзкейсов нужно использовать бажное говноподелие, которое "масштабируется до масштабов огромных корпораций"

Мне удобно, как и многим другим. А что не бажное?

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

BFE>>Часто встречающаеся задача: есть файл, который используется в двух проектах. Оба проекта лежат в своих каталогах. Как с помощью git обеспечить, чтобы этот файл был одним и тем же? Т.е. если его меняют в одном проекте, то при заборе новой версии другого проекта этот файл должен быть обнавлён.
S>Сейчас submodule вроде умеет следовать за HEAD, а не указывать на определенный коммит,
Заводить целый репозитарий для одного файла? Ну допустим...
В документации пишут что-то странное: если сделать изменение и взять новую версию, то git отрежет себе голову:

Однако, использование подмодулей не обходится без загвоздок. Во-первых, вы должны быть относительно осторожны, работая в каталоге подмодуля. Когда вы выполняете команду git submodule update, она возвращает определённую версию проекта, но не внутри ветви. Это называется состоянием с отделённым HEAD (detached HEAD) — это означает, что файл HEAD указывает на конкретный коммит, а не на символическую ссылку. Проблема в том, что вы, скорее всего, не хотите работать в окружении с отделённым HEAD, потому что так легко потерять изменения.

В английской версии похожее:

If you change a submodule reference at the same time as someone else, you may run into some problems. That is, if the submodule histories have diverged and are committed to diverging branches in a superproject, it may take a bit of work for you to fix.

S>но вообще это противоречит самой идее управления версиями.

Как так? В чём противоречие? Всё что мне нужно — это одна версия файла лежащего в двух разных каталогах. Это то, что я называю управление версией файлов, когда я могу сказать, что вот здесь и вот здесь должна быть одна и та же версия файла. А что вы называете системой управления версиями?

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

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

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

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

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

Не человечнее. Значительно путанее. Хотя по сравнению с каким-нибудь SVN он почти нормальный.

В>Bitbucket даже его снимает с мая вообще. Ужас в квадрате.

Ну, ещё куча времени.

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

M>>Но да, гит — это прям иллюстрация того, что делают программисты, дай им волю. Пользоваться без мата им нельзя.
Б>По-моему, сделали оптимальный интерфейс для распределенной VCS.
Б>Можно пример, что не так? И как это могло бы быть лучше.

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

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

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

BFE>>>Часто встречающаеся задача: есть файл, который используется в двух проектах. Оба проекта лежат в своих каталогах. Как с помощью git обеспечить, чтобы этот файл был одним и тем же? Т.е. если его меняют в одном проекте, то при заборе новой версии другого проекта этот файл должен быть обнавлён.
S>>Сейчас submodule вроде умеет следовать за HEAD, а не указывать на определенный коммит,
BFE>Заводить целый репозитарий для одного файла? Ну допустим...
Слово "целый" в этом предложении должно как-то особенно пугать? Количества кода/файлов тут роли не играет вообще.

BFE>В документации пишут что-то странное: если сделать изменение и взять новую версию, то git отрежет себе голову:
BFE>

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

Глупость пишут. Если понимать, как работают сабмодули, то никаких проблем нет. Гит автоматически не мердит изменения в сабмодулях.

S>>но вообще это противоречит самой идее управления версиями.
BFE>Как так? В чём противоречие?
Вот в этой постановке задачи:

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

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

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

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

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

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

Пару примеров, пожалуйста

В>Ведь ломкое, не для средних умов и относительно нормально работает только в консоли. Ужас.
По той же причине, по чему считают жаваскрипт самым популярным яп: он везде тк модно и удобно для мелких проектов.

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

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

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

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

Б>>Можно пример, что не так? И как это могло бы быть лучше.

BFE>Часто встречающаеся задача: есть файл, который используется в двух проектах. Оба проекта лежат в своих каталогах. Как с помощью git обеспечить, чтобы этот файл был одним и тем же? Т.е. если его меняют в одном проекте, то при заборе новой версии другого проекта этот файл должен быть обнавлён.

А как это решается в других системах?

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

В>Ну, если про консоль. Ты качаешь, а там конфликты с тобой, причём как впереди, так и сзади!!! Они показываются неврубительным ТЕКСТОВЫМ списком. Далее открывается какой-нить дебильный vim или что-то нить подобное и предлагается их исправить.

А что должно открываться в консольной утилите при конфликтах?

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

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


N>Дело даже не в консоли и необходимости помнить команды, а в том что при большом количестве веток, коммитов и участников уже через год работы там образуется Ж.

А в других VCS как эта проблема решается?

Для порядка существует git flow и т.п.

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

В>Не знаю, для меня это часто. Один раз качнул (в свой гит) исходник чего-то, а там в исходнике, в глубине оказался конфиг-файл другого гита — только конфиг!. У меня упало всё так здорово, что не помогло вообще ничего.

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

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

В>>Ведь ломкое, не для средних умов и относительно нормально работает только в консоли. Ужас.
K> Абсолютно солидарен с оценкой этого г****вноподелия.
Я понимаю, моск испорченный SourceSafe'ом или другими поделиями MS годится только на свалку. Сочувствую.

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

В>Ведь ломкое, не для средних умов и относительно нормально работает только в консоли. Ужас.
У git офигительно простая ментальная модель. Весь git — это просто связный список коммитов, а ветки — просто указатели на коммиты. Хэш коммита однозначно идентифицирует его содержание.

Всё, больше для использования git'ом ничего знать не надо.

Абсолютно логически выводятся алгоритмы слияния — просто находим общего предка и сливаем то, что разошлось. Rebase — это просто проигрывание изменений поверх нового коммита. Так как ветки — это просто указатели, то логически следует, что нет никаких скрытых зависимостей от имени ветки. Отслеживающие ветки просто перематывают указатель синхронно с веткой-источником.

Всё просто и понятно. Для совершения операции просто строим ментальную модель того, что надо сделать, и находим нужный синтаксис команды в документации.

Реальные минусы git'а:
1. Система команд непоследовательная. Например, "git checkout" очень сильно перегружен.
2. Submodules сделаны немного неочевидно.

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

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

Это уже подробно обсуждалось здесь http://www.rsdn.org/forum/flame.comp/6833707. Там можно увидеть множество таких примеров, в том числе и от меня.

M>>Но да, гит — это прям иллюстрация того, что делают программисты, дай им волю. Пользоваться без мата им нельзя.

Б>По-моему, сделали оптимальный интерфейс для распределенной VCS.
Б>Можно пример, что не так? И как это могло бы быть лучше.

Пример во всех командах гита. Любая команда — это свой уникальный набор возможностей с рандомно вставленными шорткатами. При этом логически парные команды называются как угодно, и интернет пестрит вопросами типа how to unstage a commited file. Потому что полноценный ответ на это — «изучите структуру данных, в которых гит хранит данные об изменениях, и все поймете, и тогда будете использовать только rebase и reflog».

Много обсуждения, например, тут: https://tonsky.livejournal.com/287646.html и тут: https://tonsky.livejournal.com/312123.html

Многие вещи, которые я делаю не приходя в сознание, например, в GitUp типа «призвольно разбить коммит на любое количество коммитов, переименовать, перенести вверх-вниз по ветке/веткам», в CLI git'а требуют вдумчивого сидения и аккуратного прописывания магических комбинаций буковок.

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

M>Многие вещи, которые я делаю не приходя в сознание, например, в GitUp типа «призвольно разбить коммит на любое количество коммитов, переименовать, перенести вверх-вниз по ветке/веткам», в CLI git'а требуют вдумчивого сидения и аккуратного прописывания магических комбинаций буковок.
git rebase что ли? Она там одна. Через неё разве что только разбитие коммитов не делается нормально.

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

M>Пример во всех командах гита. Любая команда — это свой уникальный набор возможностей с рандомно вставленными шорткатами. При этом логически парные команды называются как угодно, и интернет пестрит вопросами типа how to unstage a commited file. Потому что полноценный ответ на это — «изучите структуру данных, в которых гит хранит данные об изменениях, и все поймете, и тогда будете использовать только rebase и reflog».

M>Много обсуждения, например, тут: https://tonsky.livejournal.com/287646.html и тут: https://tonsky.livejournal.com/312123.html

Сходил по первой ссылке.

Вопрос на засыпку: «Что делают эти команды?»:

git reset --mixed
git checkout --cached

У обеих команд нет ключа --cached. Какой смысл в подобных испытаниях "на засыпку"?
Давайте я тогда спрошу, что делает команда "rm --exec". А что, тоже метод засыпать кого-нибудь на интервью.

По второй, да, чуть более осмысленно. Интересный взгляд на Git Flow. В то же время принципиально проблема "а что у нас получилось в результате мержа" ничуть не специфична для Git по сравнению с тем же Hg. Кто не умеет в DAG — что ж, CVS к вашим услугам. Или SVN, если хипстер.

M>Многие вещи, которые я делаю не приходя в сознание, например, в GitUp типа «призвольно разбить коммит на любое количество коммитов, переименовать, перенести вверх-вниз по ветке/веткам», в CLI git'а требуют вдумчивого сидения и аккуратного прописывания магических комбинаций буковок.

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

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

C>Всё, больше для использования git'ом ничего знать не надо.

Ну таки ещё моменты есть. Я бы добавил то, в чём тоже путался, пока не сформулировал:
Отличие checkout, branch и reset: если команда меняет текущую рабочую копию — это checkout или reset, иначе — branch. Reset — ограниченный вариант такого изменения, иначе — checkout. В идеале надо было бы разнести в checkout переключение на другой базовый коммит и без переключения, тогда было бы совсем банально. А его смешанный вариант (вытащить файл по состоянию на другой коммит) — как-то обозначить особой опцией.

Ещё я в упор не понимаю, почему merge.conflictstyle=diff3 не просто не включён по умолчанию, а вообще не сделан единственным вариантом. Совместимость с какой-то старой херью?

После таких правок — да 90% жалоб, думаю, ушло бы.

C>Реальные минусы git'а:
C>1. Система команд непоследовательная. Например, "git checkout" очень сильно перегружен.

Во-во.

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

N>Отличие checkout, branch и reset: если команда меняет текущую рабочую копию — это checkout или reset, иначе — branch. Reset — ограниченный вариант такого изменения, иначе — checkout. В идеале надо было бы разнести в checkout переключение на другой базовый коммит и без переключения, тогда было бы совсем банально. А его смешанный вариант (вытащить файл по состоянию на другой коммит) — как-то обозначить особой опцией.
Кстати, они по ходу начинают это причёсывать: https://git-scm.com/docs/git-switch и https://git-scm.com/docs/git-restore