Управление исходным кодом с помощью Git

$ git-pull
bash: git-pull: команда не найдена

и так везде

несвежая статья, как обычно у IBM. Теперь команды через черточку deprecated.

git pull

> git-1.4.0

как раз вовремя перевели

> Создание файлов различий (diff) Наконец, может потребоваться создать текстовый файл, содержащий только отличия между измененным кодом и первоначальным. Это файл обычно создается с помощью утилиты diff и называется diff.

Мда. Впрочем, может во времена git 1.4.0 команды git diff еще не было?

Git штука хорошая и самая быстрая, удобная. Однако, статья видимо старая - о нем не упоминается, я предпочитаю Mercurial - 1) практически идентичный git-у командный интерфейс 2) поддержка в NetBeans + хороший плагин к eclipse 3) удобные виндовые клиенты (а что, виндузятники они как дети малые, им надо чтобы все через окошечки, только так удобно) - если работаете над кроссплатформенным проектом и коллеги пользуются оффтопиком 4) настраивается из консоли просто, быстро, элементарно 5) проще отсылать коммиты - это делается быстро, просто, удобно (меня знакомый спец по git-у консультировать какие танцы он выполняет для отправки патча в основной репозиторий... это жесть - поправьте если ошибаюсь) 6) Mercurial под GNU GPL v2 (имеется ввиду что пользуйтесь на здоровье)

> 5) проще отсылать коммиты - это делается быстро, просто, удобно (меня знакомый спец по git-у консультировать какие танцы он выполняет для отправки патча в основной репозиторий... это жесть - поправьте если ошибаюсь)

git format-patch, git send-email, куда уж проще? А по ssh так и вообще нефиг делать.

> 6) Mercurial под GNU GPL v2 (имеется ввиду что пользуйтесь на здоровье)

как ни странно, git тоже под GPL.

Интерфейсов git сильно не хватает, да. Но эта ситуация исправляется.

> Git штука хорошая и самая быстрая, удобная. Однако, статья видимо старая - о нем не упоминается, я предпочитаю Mercurial

Git для инопланетян, Mercurial - для людей.

"Git можно использовать для управления локальными хранилищами, не зеркалируя [!!! сейчас это лингвистическое открытие подсвечено Firefox'ом, на gramota.ru тоже такого слова нет - B.] работу кого-то другого. Например, если нужно использовать Git для управления своим собственным вкладом в открытый проект, можно начать, создав хранилище Git на основе копии проекта." (c) IBM EE/A

"You can use Git to manage local repositories without mirroring someone else's work." (c) в оригинале

"mirror (REPRESENT)

1 to represent something truthfully:

2 to be very similar to something:

(с) Cambridge Advanced Learner's Dictionary

Ну и "грамотны" же "переводчики" в IBM EE/A. "Подстрочник" доставляющий. Чисто "Новояз" ( "Newspeak" (с) G.Orwell )

------

Есть нормальная документация http://www.kernel.org/pub/software/scm/git/docs/user-manual.html и безграмотный пересказ от on-line переводчика не нужен.

Почти четыре года бойану, а LOR только узнал...

> Git для инопланетян, Mercurial - для людей.

Git для тех, кто может осилить интерфейс и workflow, не похожие на SVN/CVS.

> Git для инопланетян, Mercurial - для людей.

Git для разработчиков ядра, Mercurial и SVN - для жабабыдлокодеров (типа меня).

> Git для тех, кто может осилить интерфейс и workflow, не похожие на SVN/CVS.

Угу. Кто с трех раз угадает, как в гите удалить удаленный (в смысле remote) бранч? Хорошо, что инопланетян много и гугл их индексирует.

Ну не в жисть бы не догадался, что git push origin :branch_name

P.S. Гитоюзер, на меркуриал не хочу ибо с марсом уже переписываюсь.

>> Git для инопланетян, Mercurial - для людей.

> Git для разработчиков ядра

Изначальным Git даже разрабы ядра пользоваться не хотели :) Говорят, правда, за несколько лет его облагородили... но нафиг надо? PR не в счет.

> 3) удобные виндовые клиенты (а что, виндузятники они как дети малые, им надо чтобы все через окошечки, только так удобно)

А что, под Windows нет git gui (на Tk)?

> 4) настраивается из консоли просто, быстро, элементарно

git также просто настраивается. git config --help

> 5) проще отсылать коммиты - это делается быстро, просто, удобно (меня знакомый спец по git-у консультировать какие танцы он выполняет для отправки патча в основной репозиторий... это жесть - поправьте если ошибаюсь)

Зависит от апстрма. У нас на git.alt проблем с отправкой файлов нет.

Всё же Mercurial IMHO не так распространён как Git. У нас в ALT Linux вообще сборка пакетов сделана только через Git (http://www.altlinux.org/Git.alt/Краткое_руководство). Красота!

> У нас в ALT Linux вообще сборка пакетов сделана только через Git

Вот тут бы и перечислить преимущества, но... нет перечисления :D

> Git для инопланетян, Mercurial - для людей.

Вы, конечно же, можете адекватно описать различия между этими продуктами? Или так, пришли лозунгом помахать?

> Git для тех, кто может осилить интерфейс и workflow, не похожие на SVN/CVS.

Для меня начать работать с Git оказалось гораздо проще, чем с CVS и SVN.

Раз ядром пользовались, то и Git должны были использовать. Так сказать, "в нагрузку". :)

Для ядра, в принципе, нормально. "Прикладникам", действительно, не совсем подходит. Или, точнее, совсем не подходит. Хотя для Eclipse плагин есть http://repo.or.cz/w/egit.git.

>> Git для инопланетян, Mercurial - для людей.

> Вы, конечно же, можете адекватно описать различия между этими продуктами?

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

> Или так, пришли лозунгом помахать?

Симметрично.

> Раз ядром пользовались, то и Git должны были использовать. Так сказать, "в нагрузку". :)

Я не настолько серьезный пользователь ядра, чтобы осваивать такое поделие, как Git.

> Хотя для Eclipse плагин есть http://repo.or.cz/w/egit.git.

Это тот, где Git реализован на Яве? %)

> Вот тут бы и перечислить преимущества, но... нет перечисления :D

Преимущества http://www.altlinux.org/Gear и http://www.altlinux.org/Git.alt/Введение прямо проистекают из достоинств Git:
- распределённая разработка
- транзакционный подход в управлении пакетами
- простота управления исходным кодом
- простота и удобство создания патчей
- интеграция в VCS апстрима, в том числе и по истории
- прозрачная сборка как локально, так и на сервере (в последнем случае нужно лишь создать подписанный тег и задать команду на сборку по ssh)
- быстрое бэкпортирование
- малый трафик при постановке на сборку в репозиторий
- разнообразные проверки собираемых пакетов

В общем, у нас теперь всё собирается только из Git, минуя геморрой с управлением помойкой файлов и ручного создания патчей.

>Красота!

ненене. собрка пакетов в альте это просто полный пиздец. несколько руководств, все неполноценные. то ли дело наваять ебилд ;)

Тема Git не раскрыта.

> CLI в Mercurial более удобный (CLI git - это ужоснах и кошмар)

Что в нём кошмарного?

> есть приятные мелочи вроде локальных номеров ревизий

А что, номера коммитов Git слишком сложные?

> конфигурация Mercurial проще

Хм. Мне понадобилось настроить ~/.ssh/config и прописать имя, email и GPG-ключ. Что может быть проще?

> Симметрично.

А я не делал утверждений. Перечитайте мой пост ещё раз.

>> Вот тут бы и перечислить преимущества, но... нет перечисления :D

> Преимущества http://www.altlinux.org/Gear и http://www.altlinux.org/Git.alt/Введение прямо проистекают из достоинств Git:

Мне не нужно рекламы Gear. После фразы "Всё же Mercurial IMHO не так распространён как Git. У нас в ALT Linux вообще сборка пакетов сделана только через Git" я лично ожидал сравнения Mercurial и Git.

А в рекламном блоке о Gear внимания заслуживает только "интеграция в VCS апстрима, в том числе и по истории" - здесь у Git дела обстоят лучше (по слухам).

> ненене. собрка пакетов в альте это просто полный пиздец. несколько руководств, все неполноценные. то ли дело наваять ебилд ;)

Помойку для ebuild без VCS держите? Мне искренне вас жаль!

На до же, до чего дошли Жаба-технологии, уже и git на Java пишут! Да еще назвали egit - ирландцы обидятся. :)

+много. Чего альтам не хватает, так это разумной документации, а не эти записки на манжетах по дороге в биореактор.

> я лично ожидал сравнения Mercurial и Git.

Не использовал Mercurial, не могу сравнить. Просто по работе как в ALT, так и апстриме, Mercurial не встречался ни разу. Вон, transifex (https://translate.fedoraproject.org/) работает с Git, куча очень больших проектов. Мне было достаточно посмотреть на то, кто использует Git, а кто — Mercurial, чтобы появились определённые выводы. Я против противопоставления Git и Mercurial, но лично отдаю предпочтение первому.

> Чего альтам не хватает, так это разумной документации, а не эти записки на манжетах по дороге в биореактор.

Есть такое. Но положение исправляется. Чего Вы такой злой? Девушка бросила?

Нет, просто намучался и теперь упоминание альтов вызывает негатив :)

Не обращайте внимания - пройдёт.. наверное.

> Мне было достаточно посмотреть на то, кто использует Git, а кто — Mercurial, чтобы появились определённые выводы

Собственно, об этом и речь. Но мне лично распространенность системы важна мало, в отличие от ее удобства.

О, вовремя, как раз ищу туториалы по git

> О, вовремя, как раз ищу туториалы по git

лучше почитать http://book.git-scm.com/, по ссылке устаревший примитив

> 3) удобные виндовые клиенты (а что, виндузятники они как дети малые,

http://nathanj.github.com/gitguide/tour.html ( An Illustrated Guide to Git on Windows )

> transifex

К слову говоря, этот самый transifex разрабатывается как раз с помощью mercurial.

>Помойку для ebuild без VCS держите? Мне искренне вас жаль!

прежде чем делать выводы, нужно дождаться ответа. тот оверлей что я мейнейню сейчас использует svn, планируется переход на гит. как можно держать оверелй без vcs я себе просто не представляю. после того как я не так давно узнал о силе git init, то теперь использую его везде. даже субтитры для аниме в нем храню. не говоря о всяких етс, хом и пр.

дефолтное форматирование на лоре просто ужас :(

о, а мне счас как раз нужно VCS под винду. Спасибо за информацию.

> Не обращайте внимания - пройдёт.. наверное.

Заварите корней валерианы — говорят, помогает.

> К слову говоря, этот самый transifex разрабатывается как раз с помощью mercurial.

Неудивительно, судя по его корням (Python). Только вот используется он для Git-репозиториев.

> прежде чем делать выводы, нужно дождаться ответа.

Прощу прощения.

а я это... SVN использую...

git сейчас, ИМХО, просто в моде.

> git сейчас, ИМХО, просто в моде.

Так и есть.

> http://nathanj.github.com/gitguide/tour.html ( An Illustrated Guide to Git on Windows )

Хммм... я вообще-то git люблю и больше с ним знаком, но это руководство мне поздно попалось на глаза. К счастью я пока еще на стадии выбора VCS для работы, и у меня коллега - виндузятник... Подумаю на счет гита...

На сколько стабильный и удобный плагин под Eclipse для Mercurial?

Для Git плагин пока не юзабелен совсем :(

PS
Git-GUI тоже крив до невозможности.

>Для меня начать работать с Git оказалось гораздо проще, чем с CVS и SVN.

++
Сам недавно озаботился выбором VCS для хранения конфигов. Сначала попробовал RCS, но дойдя до конфигов FVWM'а понял, что надо чтото более удобное. Попробовал SVN, но так и не понял идеологию его хранилища (да да, ниасилил). После этого почитал гитовский ман (точнее его html версию) и gittutorial, все сразу стало ясно и понятно. Сейчас просто в восторге от него.

>Это тот, где Git реализован на Яве? %)
Точно так же как и SVN.

Только SVNKit работает за частую быстрее и безглчней чем JavaHL(он через бинарники svn работает)

А вот гитовый плагин работает мягко говоря плохо.
Лучше чем Git-GUI но все равно мало юзабелен.

Традиционно:
- Распределённые VCS не нужны. По крайней 95% тех, кто их исползует.
Неполхая критика http://web.mit.edu/ghudson/thoughts/bitkeeper.whynot
Критикуется не сам bitkeeper а сама модель разработки применительно к линуксу.
Для Ъ
* Limited development speed: even with the best tools, a single integrator can only achieve a certain level of throughput.

* Single point of failure: if the single integrator of a branch suffers an accident, goes on vacation, or simply burns out, development is disrupted until a new integrator can be selected and comes up to speed.

* Opinionated maintainers: it is a rare individual who is always right. For instance, the mainline Linux kernel does not contain a kernel debugger because Linus won't allow it. "I don't think kernel development should be 'easy'. I do not condone single-stepping through code to find the bug." [2]

* Limited filtering: work done by (or approved by) an area maintainer is only subject to review by the branch integrator, and such review may be cursory or nonexistent. Of course, anyone can review all the changes that go into a branch, but only two people are in a position to say "no, this change does not meet our standards; it cannot go in" and make it stick.