Заготовки — это другая спецификация. В этой же предлагается писать свои призвольные шейдеры на GLSL. Видите в custom два первых параметра? Это как раз url для своих собственных шейдеров.
RIP. C — мой первый язык программирования. Практически все языки, языки которыми я сейчас пользуюсь или прямая надстройка над ним или так или иначе основанны на нем
На самом деле да, возможность работы без центрального сервера лично для меня далеко не самая главная причина перехода с svn.
Основные причины:
1) Лучшая защита от дурака. C git гораздо сложнее забыть добавить файл в индекс или потерять свои изменения. Однажды в svn во время мерджа по ошибке ввел tf вместо mf — потерял довольно большой кусок кода, восстановить не смог (да, я знаю, что я сам криворукий дебил и меня к компьютеру вообще подпускать нельзя). В git же на момент pull все локальные изменения всегда закоммичены и их всегда можно восстановить.
2) Более удобная работа с ветками. Про это уже сказали
3) git stash. Тоже упоминался
4) git автоматически распознает переименования, перемещения и удаления файлов в ФС без использования собственных комманд
5) github
6) Быстрый просмотр истории, переключение между ветками, чекаут отдельных ревизий — не нужно идти за этим на сервер
7) Более чистая рабочая директория. Нет отдельных папок для веток и тегов, всего одна папка .git (рад что в .svn теперь также)
Вам уже говорили, есть ssh-ключи, есть различные методы авторизации.
Дело в том что git-репозиторий, в отличие от svn — это не какой-либо серверный процесс, это просто директория на диске с определенной структурой. Если у злоумышленника нет доступа к этой директории коммитить он туда не сможет. Так что проблема «злоумышленник может любому валидному пользователю закомитить в его реп код от имени кого угодно» довольно таки сомнительная. А для центрального репозитория вам несколько решений уже показали
Извините, эта уже какая-то совсем надуманная проблема. Кто вас заставляет шарить локальные репозитории дальше личного компьютера? Такими темпами мы дойдем до того, что гит небезапасасен, потому что злоумышленник может с компьютера валидного пользователя коммитить пока тот покурить вышел
1) У вас есть не только локальная история (ваши изменения) но и полная история всех изменений до времени последнего pullа. Чтобы посмотреть историю, вам не надо обращаться к центральному серверу, вся история есть уже у вас на машине. Просмотр истории в git/hg банально быстрее.
1-2-3) Выясняется, что не только синхронизация нужна
Да и в целом по поводу синхронизации. Если у вас по каким-то причинам нет доступа к центральному svn-серверу, у вас нет никакой возможности передать код коллегам. В git же вы в таком случае можете добавить репозиторий своего коллеги себе как remote и синхронизироваться напрямую с ним.
Доступ к удаленному git репозиторию выполняется тремя способами:
1) По HTTP. В основном используется для read-only доступа. Push делать можно, но это не удобно. В этом случае можете различать пользователей по имени/паролю или любым другим удобным способом для HTTP-авторизации;
2) Собственный протокол git:// — только read-only;
3) ssh — в 99% случаев используется для read-write доступа, идентификацировать пользователей можно по имени/паролю или публичному ключу.
В git нет понятия сервера. У каждого из членов команды есть своя копия всего репозитория. Некоторые локальные ветки могут ссылатся на ветки на удаленных машинах, но все операции (коммиты, просмотр истории, ветвления и слияния — все кроме синхронизации локальных и удаленных веток) выполняются с локальным репозиторием
Основные причины:
1) Лучшая защита от дурака. C git гораздо сложнее забыть добавить файл в индекс или потерять свои изменения. Однажды в svn во время мерджа по ошибке ввел tf вместо mf — потерял довольно большой кусок кода, восстановить не смог (да, я знаю, что я сам криворукий дебил и меня к компьютеру вообще подпускать нельзя). В git же на момент pull все локальные изменения всегда закоммичены и их всегда можно восстановить.
2) Более удобная работа с ветками. Про это уже сказали
3) git stash. Тоже упоминался
4) git автоматически распознает переименования, перемещения и удаления файлов в ФС без использования собственных комманд
5) github
6) Быстрый просмотр истории, переключение между ветками, чекаут отдельных ревизий — не нужно идти за этим на сервер
7) Более чистая рабочая директория. Нет отдельных папок для веток и тегов, всего одна папка .git (рад что в .svn теперь также)
Дело в том что git-репозиторий, в отличие от svn — это не какой-либо серверный процесс, это просто директория на диске с определенной структурой. Если у злоумышленника нет доступа к этой директории коммитить он туда не сможет. Так что проблема «злоумышленник может любому валидному пользователю закомитить в его реп код от имени кого угодно» довольно таки сомнительная. А для центрального репозитория вам несколько решений уже показали
1-2-3) Выясняется, что не только синхронизация нужна
Да и в целом по поводу синхронизации. Если у вас по каким-то причинам нет доступа к центральному svn-серверу, у вас нет никакой возможности передать код коллегам. В git же вы в таком случае можете добавить репозиторий своего коллеги себе как remote и синхронизироваться напрямую с ним.
1) Никогда не просматриваете историю изменений
2) Не пользуетесь ветками
3) Никогда не откатываете свои или чужие изменения
то вам и система контроля версий-то в принципе не нужна. Хватит и diff+patch. Но я что-то сомневаюсь, что вам действительно нужна только синхронизация
1) По HTTP. В основном используется для read-only доступа. Push делать можно, но это не удобно. В этом случае можете различать пользователей по имени/паролю или любым другим удобным способом для HTTP-авторизации;
2) Собственный протокол git:// — только read-only;
3) ssh — в 99% случаев используется для read-write доступа, идентификацировать пользователей можно по имени/паролю или публичному ключу.
> а мне надо было вытащить 1 сраный файл из прошлой ревизии
> прошлой
Все началось с небходимости посмотреть прошлую ревизию, закончилось «как получить последнюю вресию файла»
git config user.email «vasyaivanov@ivanovs.com»
Не работает, если вы полные тезки с одним email-адресом на двоих
«Как зародилась жизнь на Земле?»
«Жизнь на Земле?»