LINUX.ORG.RU

Git 2.0

 , , ,


1

3

Git — распределённая система управления версиями файлов. Проект был создан Линусом Торвальдсом для управления разработкой ядра Linux, первая версия выпущена 7 апреля 2005 года. На сегодняшний день его поддерживает Джунио Хамано.
Git используют такие проекты как Linux, Android, Debian, Libreoffice, Systemd, X.Org, Wayland, Gnome, KDE, Perl, Drupal, Cairo, GNU Core Utilities, Mesa, Wine, Chromium, Compiz Fusion, FlightGear, jQuery, PHP, NASM, MediaWiki, DragonFly BSD.

Неполный список изменений:

  • Изменён префикс по умолчанию с refs/remotes на refs/remotes/origin/ для команды git svn.
  • Из команды git diff-files исключена опция -q.
  • В git request-pull прекращена поддержка нескольких эвристических выводов при выборе ветки для pull-запроса, которые часто приводили к ошибкам.
  • Теперь remote-hg/bzr — отдельный плагин, не входящий в состав request-pull.
  • В файлах .gitignore появилось игнорирование пробелов в хвосте путей.
  • Обеспечение поддержки опций --depth в git gc --aggressive --show-linear-break в git log, --gpg-sign в командах, создающих коммиты.
  • В git rebase опция "-" разбирается как указание на прошлую ветку.
  • Команда git push при работе через интерфейс transport-helper теперь поддерживает инициирование принудительного обновления ссылок.
  • В git push раньше использовалась семантика «matching» теперь поведение изменено и по умолчанию применяется семантика «simple».
  • Указание "-" вместо имени входного файла в команде git config --file позволяет организовать загрузку данных из входного потока.

>>> Подробности

★★

Проверено: mono ()
Последнее исправление: Dendy (всего исправлений: 5)
Ответ на: комментарий от anonymous

Очень похоже на вопрос про семки.

Развернутый ответ, ога

WindowsXP ★★
()
Ответ на: комментарий от hibou

Не понял.

До сих пор нельзя работать с разными бранчами одновременно. Разве что копируя полностью репозиторий.

Тут есть какой-то минус? Или это ты о плюсе сказал?

anonymous
()

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

GblGbl ★★★★★
()
Ответ на: комментарий от GblGbl

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

А в чем сложность создания бранча в mercurial?

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous

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

hibou ★★★★★
()
Ответ на: комментарий от hibou

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

Интересный юзкейс. А как его реализовать без физического копирования сорцов (и/или поддержки со стороны ФС)?

KennyMinigun ★★★★★
()
Ответ на: комментарий от hibou

а там несколько гигов сорсов или репозитория?

если сорсов не очень много, то можно просто checkout сделать куда-нибудь и там компилять?

anonymous
()
Ответ на: комментарий от tailgunner

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

GblGbl ★★★★★
()
Ответ на: комментарий от GblGbl

меркуриал у меня копировал всё пространство целиком.

Копировал пространство? O_o

Хотя, может я что-то неправильно делал.

Очень похоже на то.

tailgunner ★★★★★
()
Ответ на: комментарий от KennyMinigun

В ClearCase как-то реализовано. Там я мог сразу с 2-мя бранчами в разных вкладках терминала работать.

hibou ★★★★★
()
Ответ на: комментарий от hibou

Копировать несколько гигов репозитория - не вариант.

Репозитории в рамках одной ФС никогда не копировались ни в одной современной DVCS.

tailgunner ★★★★★
()

Для больших проектов типя ядра оно всё ещё не пригодно т.к качать 2 гига непрерывно не каждый может себе позволить.

mittorn ★★★★★
()
Ответ на: комментарий от hibou

ClearCase

Выписка из википедии

The networked filesystem provided by MVFS allows for build auditing.

Use of MVFS allows derived objects built in one dynamic view to be automatically «copied over» to another dynamic view requiring «exactly the same» derived object. Two derived objects are deemed to be «exactly same» if they have the same configuration record (ClearCase terminology, also called bill of materials). Shared derived objects will be physically present on the VOB server, and not in the views that reference them. The process of «copying over» is called winking in in ClearCase terminology. This feature requires that the clearmake or omake tools are used instead of other build systems.

Реализовано, вестимо, с помощью поддержки ФС. В теории можно нечто подобное и с гитом сделать с помощью AUFS. C network filesystem сложнее будет — тут нужна поддержка с удалённого хоста (например «центральный» VCS сервер).

KennyMinigun ★★★★★
()
Ответ на: комментарий от tailgunner

Репозитории в рамках одной ФС никогда не копировались ни в одной современной DVCS.

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

Т.е. Без физической копии сорцов это сложно сделать. Тут разве что СoW может спасти, ext4 (к примеру) его поддерживает?

KennyMinigun ★★★★★
()
Ответ на: комментарий от KennyMinigun

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

Вот именно две копии репозитория, а не две рабочих копии? Объясни, мне реально интересно, зачем такое может понадобиться.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Вот именно две копии репозитория, а не две рабочих копии? Объясни, мне реально интересно, зачем такое может понадобиться.

Git 2.0 (комментарий)

Т.е. надо иметь

  • «Слепок файлов» для компилятора с одной ветки (R/O)
  • И чекаутнутую другую ветку с возможностью вносить правки в неё (R/W)

Как это сделать?

KennyMinigun ★★★★★
()
Ответ на: комментарий от KennyMinigun

Для Mercurial:

hg clone http://example.com/hg/supaproj supa-ro

hg clone supa-ro supa-rw

«Под капотом» supa-ro и supa-rw используют одну копию репозитория через CoW, реализуемый средствами Mercurial. Git принципиально очень похож на Mercurial, так что «под капотом» в нем будет то же самое, просто я не могу так сразу привести команды для него.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

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

GblGbl ★★★★★
()
Ответ на: комментарий от GblGbl

Ну, три года с Git не гарантируют понимания. И я никогда не понимал людей, которые пользуются Mercurial без mq.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Сейчас сделал вот так:

mkdir ro && cd ro

# "подопытный объект"
dd if=/dev/urandom of=file bs=200M count=1
git init
git add *
git commit -m Initial

df /tmp # эталонный замер

cd ..
git clone ro rw

df /tmp # контрольный замер

В первом замере было использовано 417248 во втором 622132. Путём нехитрых подсчётов имеем наши же 200М:

622132 - 417248 = 204884
204884 / 1024 = 200

KennyMinigun ★★★★★
()
Последнее исправление: KennyMinigun (всего исправлений: 1)
Ответ на: комментарий от tailgunner

А есть какая-то популярная система контроля версий более простая и понятная чем GIT. Он может быть и крут, но ИМХО излишне сложен.

Xroft ★★
()

Хорошие, годные изменения. Рад, что разработчики не цепляются за обратную совместимость, как за священную корову.

lucentcode ★★★★★
()
Ответ на: комментарий от tailgunner

Я даже не заметил, что дополнительная папка .git совершенно не заняла места :) Круто.

KennyMinigun ★★★★★
()
Ответ на: комментарий от Xroft

А есть какая-то популярная система контроля версий более простая и понятная чем GIT

Mercurial. Есть еще bzr, который, по отзывам, еще дружественнее, но Canonical на него забил.

tailgunner ★★★★★
()
Ответ на: комментарий от Pinkbyte

Не только, перл там еще для каких-то штук используется. Не помню точно, вроде для git add --patch нужно.

anonymous
()
Ответ на: комментарий от wayland_systemd

а что - это модно делать clone всей репы чтобы посмотреть один файлик ? или название одного файлика? или вы фанатег ?

WindowsXP ★★
()
Ответ на: комментарий от anonymous

Я имел ввиду, что выход новой версии git - хорошо. Но могло бы быть лучше, если-бы изменения были полезными.

Deleted
()
Ответ на: комментарий от WindowsXP

Организация данных внутри репозитория Git не позволяет «посмотреть один файлик», не прочитав весь репозиторий. Например, данные могут находиться внутри pack-файла (дельта-архива). Поэтому, если мы хотим передать от сервера клиенту только один файлик, на сервере нужна программа, которая сама посмотрит в репозиторий и отдаст этот файлик клиенту по какому-нибудь другому (не Git) протоколу. Такие программы есть: называются веб-интерфейсами.

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

данные могут находиться внутри pack-файла (дельта-архива)

А давно он стал дельта-архивом? В начале славного пути это был просто zip.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

А давно он стал дельта-архивом? В начале славного пути это был просто zip.

Как только перешел в руки япошки. То есть очень давно.

anonymous
()
Ответ на: комментарий от WindowsXP

Web морда - ненужная сущность... моглибы и git протокол расширить....

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

anonymous
()
Ответ на: комментарий от tailgunner

Я с Git-ом имею дело достаточно недавно — последние два года точно.

intelfx ★★★★★
()

что можно сказать про vcs, которую изучать в несколько раз дольше, чем используемый язык

wxw ★★★★★
()
Ответ на: комментарий от WindowsXP

А зачем добавлять в протокол то, что не имеет к нему никакого отношения? git-протокол создавался для push и pull. «Посмотреть файлик, не скачивая репозиторий» — это задача просто другого уровня, и веб-интерфейс здесь как раз в тему.

intelfx ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.