О! Только вчера завёл первый проект в гите.

А пару недель назад посмотрел это видео. Доставляет, да. Какая-то из ссылок на него сопровождалось комментарием вроде "если вы хотите увидеть, как Линус Торвальдс объясняет, что такое мастурбация…" (имеется в виду эпизод с обсуждением сетей доверия). Действительно зажигательно. "Я уверен, что кто-то из разработчиков SVN сейчас присутствует в зале. Так вот, вы дураки".

Из русскоязычных текстов про git, на мой взгляд, ещё хорош вот этот:
http://freesource.info/wiki/RuslanHihin/gitusermanual

Signed-Off зачем?

я полагаю, чтобы не терять оригинального автора после грязного выдёргивания коммита. В git это автоматизировано и называется cherry-pick, видимо часто используется. При этом, в отличие от правильного merge, в метаданных коммита оригинальный автор заменяется на того, кто произвёл эту процедуру. Ну а коммент остаётся.

Без cherry-pick'а сложно было бы реорганизацию патчей делать.

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

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

http://kerneltrap.org/node/3180

Где связь между "пользованием git-ом" и "пользованием git-ом для отправки патчей в ядро Linux"? :-)

Так вопрос "зачем механизм вообще" или "зачем он использован в приведённом примере"?

В примере. Зачем начинающему задумываться о подписи.

Ну, может, чтобы сразу приобретать хорошие привычки…

Знаешь, когда обучают вождению, то с самого начала обращают внимание на необходимость пристегнуть ремень безопасности. При этом первые занятия проходят обычно на полигоне, где скорость движения 5–10 км/ч и ремень там ну никак не нужен. Но потом он понадобится, поэтому лучше сразу научить его использовать.

Наверное, поэтому я добавил опцию -s

Ну просто нужно было сказать в посте :-)
При обучении вождению тренер же говорит зачем нужны ремни :-)

когда знакомишься с vcs, главное - понять нафига оно надо.

(тут мы какбы забываем что сам Линус долго пользовался тарами и диффами)

Тут кагбы надо понять, что диффы с тарами — это тожэ vcs. Более того, технически git от него мало отличается (ну, чуть-чуть syntactic shugar добавили).

Это да, умеющих пользоваться RSC (любой!) у нас преступно мало.
Год назад ещё жаловался на это: http://blog.vnaum.com/2008/04/revision-control-basics.html

Ну а git, ИМХО, не сильно подходит для начинающих.
Сильно быстро его чинят-ломают-меняют. Половина мануалов/введений на интернете (которые отличаются от установленного git-а на полгода хотя бы) могут просто не работать. Вот твоё введение, например, не заработает у людей на debian etch - там 'git config --add user.name "John Doe"' нету ещё.

GIT под виндами пока что сосёт.

Да ладно, я нормально работаю.

case sensitivity напрягает, но в обычном режыме это не так часто попадается.

git-svn не работает. TortoiseGIT - пре-бета

Это венда сосёт, потому что там Git'а нет.

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

Мне на работе венда не нужна.

Молодец, возьми с полки пирожок

Я с ливером не люблю, спасибо.

Ну это ты сильно переупростил. Что будет если git pull сделать, не показал. А в етом как бы главное. Все что перечислено в постинге, и RCS может. Так что думаю многим читателям будет непонятно зачем все это, и чем это лучше чем CVS или SVN.

Кстати, лекция Линуса мне не понравилась. Ну, поругался, а толком ничего не объяснил. А я как-то был на FreedomHEC, там Джеймс Баттоломью очень все толково объяснил, мне все стало ясно. С тех пор и пользуюсь git-ом.

> А я как-то был на FreedomHEC, там Джеймс Баттоломью очень все
> толково объяснил, мне все стало ясно.

Я видел его выступление на ту же тему на LinuxConf Europe в Кембридже (это было то ли прямо до, то ли сразу после кернель саммита) — хорошо рассказывал. Правда, в середине вышел Линус :) и давай Джеймса ругать, что он ни разу за полтора года не запускал git-gc, и поэтому у него всё тормозит. Они запустили git-gc, после чего Линус перехватил эстафетную палочку и долго рассказывал про git вместо Джеймса.

> Ну это ты сильно переупростил.
> Что будет если git pull сделать, не показал.

Ну это уже тогда будет не трёхминутный курс. Я считаю, что тут главное — начать. Чтобы люди увидели, что source control (хотя бы какой-нибудь) — это не сложно, а просто и удобно, чтобы начали пользоваться, а там уже разберутся потихоньку. Да, хочется и push/pull показать, и branch/merge, и даже bisect.

Но я показал только init/commit/log/diff, потому как мой вопрос человеку «а у вас есть source control?» был задан в ответ на «я тут что-то в коде поломала, вчера работал, а сегодня перестал». Вот я и показал, что можно поглядеть, что меняли.

У git'а, как и у любой принципиально децентрализованной системы, есть оченб серьёзный минус: поддерживающему какую-то ветку крайне сложно сказать "этот баг зачинен начиная с такой вот ревизии проекта в целом" - нет централизованной неубывающей сущности, и она крайне криво эмулируется.

Кроме того, не стоит забывать, что большинство моделей разработки как раз таки centric by design. У этого есть свои плюсы, минусы, но недаром ведь Perforce так в мире популярен (а система разработки M$, кстати, сделана perforce'ом специально под MS на основе p4*)

> нет централизованной неубывающей сущности

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

Да, в гите нет технического ограничения, что вот это вот — центральный репозиторий. Однако, никто не мешает ввести такое ограничение административно, взяв и объявив таковым любой подходящий для этой роли репозиторий.

Собственно, у самого линукс-ядра так и есть — центральным считается репозиторий самого Линуса.

> и она крайне криво эмулируется

Криво? Эмулируется? Поясни.

Я, разумеется, biased, потомушто потому ;)

http://wiki.freebsd.org/VersionControl

Я пользовался Perforce, мне понравилось. CVS фтопку, потому что дрянь, даже лень объяснять. SVN лучше, чем CVS, но тоже кривой (теги там, к примеру, ещё хуже, чем в CVS). Mercurial нормальный (он вообще очень похож на git по интерфейсу), только на некоторых операциях ужасно тормозной. Базар и монотон не пробовал, не знаю.

В hg какие-то довески на haskel'е написаны... Вот уж.
А rebase, как утверждают коллеги, вынесен из базовых операций, что странно.

Да, в нашем случае, судя по всему, ещё и не нашлось достаточно активного девелопера, который бы взял на себя координацию git'а, в отличие от svn.

Под коодинацией ты имеешь в виду администрирование? Или решение вопросов, кто что куда как коммитит?

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

Оба аспекта.

В head коммиттят и так все, кто имеют доступ - с риском получить по шапке от сначала developers@, а потом от core@ ;-)

Я, собственно, о том, что security officer'у придётся придумывать, внедрять и энфорсить какие-то процедуры. В отличие от централизованных схем, в которых оно есть бай дизайн.

А дальше - всё зависит от организации проекта, разумеется.

Пусть расцветают все ;)

> собственно, о том, что security officer'у
> придётся придумывать, внедрять и
> энфорсить какие-то процедуры.

Да ну перестань… То, что с git можно организовать разные модели, вовсе не означает, что нельзя сделать так, как в CVS/SVN, или что с гитом это будет как-то сложнее. Это могут быть ровно те же процедуры, как и в CVS или SVN, то есть даём всем право коммита (пуша, в случае гита) в центральный репозиторий. Всё, чего нет в этом самом центральном репозитории — не считается.

> крайне сложно сказать "этот баг зачинен начиная с такой вот ревизии проекта в целом"

Вообще-то принято тэги ставить. Commit id - это исключительно для разработчиков, а "проект в целом" - это tag, которым пользуются релиз-инженеры.

Спасибо, очень полезное введение.

Начал смотреть видео: "He created the version control system that was specially designed to make you feel the less intelligent, than you thought you are..." LOL!

На самом деле, я для себя сформулировал примерно такое правило:

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