The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Релиз распределенной системы управления исходными текстами Git 1.7.10

07.04.2012 21:08

Представлен релиз распределенной системы управления исходными текстами Git 1.7.10. Git является одной из самых эффективных, надёжных и высокопроизводительных систем управления версиями, предоставляющей гибкие средства нелинейной разработки, базирующиеся на ответвлении и слиянии веток. Для обеспечения целостности истории от изменений задним числом используются криптографические методы, также возможна привязка цифровых подписей разработчиков к тегам и коммитам. Из проектов, разрабатываемых с использованием Git, можно отметить ядро Linux, DragonFly BSD, Perl, Eclipse, GNOME, KDE, Qt, Ruby on Rails, Android, PostgreSQL, X.org.

Некоторые изменения:

  • При выполнении "git merge" отныне вызывается интерактивный редактор для добавления пояснения о результирующем слиянии, по аналогии с "git commit". В случае использования "git merge" в скриптах, для отмены нового поведения следует установить переменную окружения GIT_MERGE_AUTOEDIT в значение "no" или использовать опцию "--no-edit";
  • В настоящее время, если не указать какие ветки и теги использовать при выполнении "git push", используется правило "matching refs" (push.default=matching), которое выбирает для обновления все внешние ветки и теги с именами, совпадающими с локальными. В будущих версиях Git поведение будет изменено и изменения будут затрагивать только текущую ветку (push.default=upstream или push.default=current);
  • Обновлён интерфейс gitk, например, переработан диалог настройки и добавлена поддержка наглядного сравнения двух коммитов;
  • В "gitweb" реализована подсветка результатов поиска, осуществлено чтение из репозитория только необходимых для текущей задачи данных (а не всех которые могут понадобиться для различных задач), обеспечен вывод списка проектов, размещённых в указанной директории;
  • В HTTP-транспорте реализована поддержка работы через прокси с аутентификацией;
  • В конфигурации добавлена поддержка директивы "include", позволяющей включать в текущую позицию содержимое других файлов;
  • Возможность подключения обязательных к применению фильтров контента;
  • В "git clone" добавлена поддержка опции "--single-branch" для ограничения клонирования одной веткой;
  • При выполнении "git clone" c указанием тега через опцию "--branch" (например, "--branch=v1.0") теперь осуществляется отсоединение HEAD из результирующего репозитория;
  • Вывод "git diff --stat" теперь автоматически подстраивается под широкоформатные терминалы и использует максимально возможную ширину строки;
  • Обновлён фильтр "diff-highlight" из contrib, который теперь генерирует более эстетически приятный вывод;
  • В "fsck" добавлена опция "--no-dangling" для пропуска информации о висящих объектах;
  • В операциях "git log -G" и "git log -S" добавлена поддержка опции "-i" для поиска без учёта регистра символов;
  • В "git push" добавлена опция "--prune" по аналогии с "git fetch";
  • Содержимое директории, используемой для хранения первичного проекта, обслуживаемого через "git submodule", теперь может быть перенесено в другое место;
  • При выполнении "git tag --list" появилась возможность ограничения вывода только для объекта, указанного через "--points-at object";
  • Добавлен скрипт "diffall", предназначенный для выполнения за один проход сравнения двух ревизий на уровне содержимого директорий;
  • В "git difftool/mergetool" добавлена поддержка DeltaWalker;
  • Улучшена работа инструментов для интеграции со сторонними системами: "git-p4", "git-svn", "vcs-svn";
  • Увеличена производительность "git fetch" для репозиториев с чрезмерным числом ссылок, за счёт избавления от ненужных вызовов функций парсинга объектов;
  • В тестовом пакете реализована поддержка параллельного выполнения заданий, что является первым шагом к созданию фреймворка для оценки производительности.


  1. Главная ссылка к новости (https://lkml.org/lkml/2012/4/6...)
  2. OpenNews: Релиз распределенной системы управления исходными текстами Git 1.7.9
  3. OpenNews: Релиз распределенной системы управления исходными текстами Git 1.7.7
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/33556-git
Ключевые слова: git
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (70) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, добрый дядя (?), 23:58, 07/04/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • –15 +/
    может git мощнее и у него больше функций, которые важны очень крупным проектам, однако для простых смертных разработчиков в небольших коллективах удобнее Mercurial + TortoiseHG :)

    а про git пока так: http://www.youtube.com/watch?v=CDeG4S-mJts - баян, но ржака

     
     
  • 2.2, Дмитрий Радужный (?), 00:18, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +10 +/
    У нас абсолютно противоположный опыт. Git подошел лучше чем Mercurial, ветвления рулят :)

    Хотя на старых проектах оставили Mercurial.

     
     
  • 3.6, Kim (?), 00:38, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    hg bookmarks?
     
     
  • 4.11, Аноним (-), 00:45, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +4 +/
    hg kostily-kostiliki


     
  • 4.16, Дмитрий Радужный (?), 01:03, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Перейти на git оказалось проще чем использовать bookmarks в Mercurial. В git это изначально заложено и очень прозрачно используется. Хотя bookmarks в одном или двух старых проектах используются сейчас, но что-то ни кто от них не в восторге.
     
     
  • 5.21, Аноним (-), 01:23, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Гит вообще для тех кто хотя-бы hello world написать может и представляет себе как выглядит процесс разработки - ощущается столь же естественно как воздух. Вы просто не задумываетесь когда дышите. В гите я точно так же не задумываюсь насчет типовых операций потребных разработчикам. Они сделаны очевидно и естественно,
     
     
  • 6.26, Аноним (-), 01:43, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Такое ощущение что я читаю рекламу ВидалСасунВошНГо.

     
     
  • 7.28, Аноним (-), 05:54, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Такое ощущение что я читаю рекламу ВидалСасунВошНГо.

    Хороший товар - рекламируют благодарные пользователи. Хреновый - куча маркетологов. Видал, Сасун? :)

     
     
  • 8.31, anonimouse (?), 10:07, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    к сожалению, в случае с гитом, рекламировать могут и толпы восторженных хомякидо... текст свёрнут, показать
     
     
  • 9.32, tamerlan311 (?), 10:54, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +7 +/
    Ну да, чтобы kernel хакеров обозвать восторженными хомякидами это надо быть как ... текст свёрнут, показать
     
     
  • 10.36, Аноним (-), 13:10, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Это ты тут кернел-хакер ... текст свёрнут, показать
     
  • 10.39, poplar (?), 15:17, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Так они его для себя создавали А так да, толпа леммингов не может ошибаться А ... текст свёрнут, показать
     
     
  • 11.47, Аноним (-), 17:37, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Правильно И кому как не программистам лучше всего знать свои потребности, да ... текст свёрнут, показать
     
  • 10.41, kurokaze (ok), 15:56, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Чего ты хочешь от любителей Пишут свой простенький проект и хвалят свои костыли... текст свёрнут, показать
     
  • 9.44, Аноним (-), 17:33, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Им повезло что не видели - меньше блевать от результатов сравнения и сожалеть о ... текст свёрнут, показать
     
  • 2.4, Василий (??), 00:25, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Хватит сказки рассказывать про Mercurial и TortoiseHG. Ты либо с винды не слез, либо система контроля версий тебе не нужна. В общем видели, знаем, ставим Mercurial, а потом его в git превращаем, только вот ветвлений нормальных там нет и вообще ничего нормального нет.
     
     
  • 3.5, Дмитрий Радужный (?), 00:34, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > Хватит сказки рассказывать про Mercurial и TortoiseHG. Ты либо с винды не
    > слез, либо система контроля версий тебе не нужна. В общем видели,
    > знаем, ставим Mercurial, а потом его в git превращаем, только вот
    > ветвлений нормальных там нет и вообще ничего нормального нет.

    Если бы не Mercurial я бы с svn бы на git сразу не слез, не тот у меня возраст что бы привычки менять, так что не надо на Mercurial наговаривать, достойная система контроля версий.

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

     
     
  • 4.8, Аноним (-), 00:42, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >И посмотрел бы я на вас как вы без Tortoise будете учить дизайнеров, художников, и других не программистов которые над контентом проекта работать комиты делать.

    Мордаладонь. А создать им батник/ скрипт вида git add .&&git commit -am "From designer" религия не позволяет? Аналогично для пула/ пуша.
    Кстати наблюдения показазывают, что среди дизайнеров/художников дибилов не больше чем в других случаях.

     
     
  • 5.19, Дмитрий Радужный (?), 01:12, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А мержить они как через такие скрипты будут? Нет уж, пусть лучше понимают что делают, а не скрипты запускают, был у нас такой резвый, который скрипты для художников писал, через два дня репозиторий в змея горынычя превратился, только не обычного, а из Чернобыля, с 1000 и 1 головой.
     
     
  • 6.33, tamerlan311 (?), 10:57, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Мерджить должен старший, а не абы кто, предварительно проверив накоммиченную лажу.
     
  • 6.35, Аноним (-), 12:18, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Зачем им вообще что-то мержить? Для таких кадров придумали системы резверного копирования. А большего от VCS им и не нужно, ибо такие же заложники привычек по своей воле.
     
     
  • 7.53, Аноним (-), 17:59, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Зачем им вообще что-то мержить?

    Более того - объясните мне что с логической точки зрения есть "мерж" двух вариантов растровой картинки? :)

     
  • 4.9, Аноним (-), 00:43, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > И посмотрел бы я на вас как вы без Tortoise будете учить дизайнеров, художников, и других не программистов которые над контентом проекта работать комиты делать.

    Интересно посмотреть на commitdiff при изменении гаммы растровой картинки :)

     
     
  • 5.12, Аноним (-), 00:45, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Интересно посмотреть на commitdiff при изменении гаммы растровой картинки :)

    Вообще, использование sourcecode-oriented vcs художниками - это очень загадочная и интересная тема.

     
     
  • 6.57, all_glory_to_the_hypnotoad (ok), 18:38, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    душа рэндомщика загадочна...
     
  • 6.58, Аноним (-), 19:57, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Вообще, использование sourcecode-oriented vcs художниками - это очень загадочная и интересная
    > тема.

    Пусть тогда расскажет что должен делать мерж 2 растровых картинок? Давать на выходе рандом? :)

     
  • 5.14, Xasd (ok), 00:47, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    git: 'commitdiff' is not a git command. See 'git --help'.
     
  • 5.17, Дмитрий Радужный (?), 01:08, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Интересно посмотреть на commitdiff при изменении гаммы растровой картинки :)

    Дизайн макетов в xml, а графика в svg. :) А для бинарных форматов только svn. Идиотизм пихать в git или mercurial такие вещи. Они по дню раз сто меняются, пришлось бы дата центр арендовать хранись это под vcs :)

     
     
  • 6.37, Аноним (-), 13:18, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    svn это типа уже не vcs? Кстати, есть хорошая вещь для просто наколеночных бэкапов - git-annex
     
     
  • 7.54, Аноним (-), 18:00, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > svn это типа уже не vcs?

    Жалкое подобие таковой. Даже на прошлую ревизию не отмотаешь если сети нет.

     
  • 4.22, Аноним (-), 01:25, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • –4 +/
    > Если бы не Mercurial я бы с svn бы на git сразу не слез, не тот у меня возраст

    Ваш возраст и привычки - ваши проблемы. А я вот смотрел их примерно одноврменно. Ну и гадость же hg на фоне git. Одного того что гит в разы быстрее типовые операции отрабатывает уже достаточно. Пока фанаты svn/cvs/git ффтыкают как оно проматывает запрошенную операцию, git уже давно закругляется.  

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

    Нафига козе баян?

     
     
  • 5.29, Аноним (-), 09:28, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >Пока фанаты ...git ффтыкают как оно проматывает запрошенную операцию, git уже давно закругляется.  

    это все происходит с одним и тем же гитом, или с разными)

     
     
  • 6.48, Аноним (-), 17:40, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > это все происходит с одним и тем же гитом, или с разными)

    В первом случае разумеется hg/svn/cvs. Во втором - гит. После гита эти тормозилки ничего кроме отвращения не вызывают.


     
     
  • 7.68, MaMoHT (?), 05:05, 09/04/2012 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > В первом случае разумеется hg/svn/cvs. Во втором - гит. После гита эти тормозилки ничего кроме отвращения не вызывают.

    Ты этой товарищам из фейсбука расскажи. :-) Они, почему с тобой не советовавщись, рещили, что гит редкое тормозилово :-)

     
     
  • 8.73, Василий (??), 08:24, 09/04/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Товарищи из фейсбука еще PHP свой написали, потому что в свое время решили что о... текст свёрнут, показать
     
     
  • 9.84, Geol (??), 12:04, 09/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Товарищи из фейсбука как раз эксперты - они поддерживают и разрабатывают свехвыс... текст свёрнут, показать
     
     
  • 10.86, arisu (ok), 12:32, 09/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    товарищи из мордокниги 8212 они таки да, эксперты по костылям и количеству м... текст свёрнут, показать
     
  • 8.74, Аноним (-), 08:25, 09/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    AFAIK, другие варианты они даже не тестировали... текст свёрнут, показать
     
  • 8.79, Аноним (-), 11:12, 09/04/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это тем которые сначала на пыхпыхе написали а потом подорвались через эн лет дел... текст свёрнут, показать
     
  • 4.85, Алексей Поляков (?), 12:22, 09/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > И посмотрел бы я на вас как вы без Tortoise будете учить дизайнеров, художников, и других не программистов которые над контентом проекта работать комиты делать.

    Так вот, специально для такого случая написано:
    http://hoth.entp.com/output/git_for_designers.html

    На очень понятном для "гуманитариев" языке.

     
     
  • 5.87, arisu (ok), 12:41, 09/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > На очень понятном для «гуманитариев» языке.

    в принципе, там было бы достаточно слова «DON'T!» за очень небольшим исключением там не нужны дифы, мержи, бранчи и прочие страшные слова. всё, что надо — это, фактически, коллекция бэкапов с возможностью дёрнуть любой. то бишь, что-то ещё даже примитивней, чем svn.

     
  • 3.65, Crazy Alex (ok), 02:30, 09/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Дизайнерам и подобному народу лучше давать централизованный версионник - как правило у них не хватает компетенции нормально администрировать локальный, да и не нужно им оно. Всё что там требуется - место, куда будет валиться очередная версия "нетленки" с подписью, и средства вытащить нужную версию - при это всё это реализованное так, чтобы необратимо поломать будо нереально. То есть либо svn либо если git и иже с ним - то скрипты, которые будут использовать локальный репозиторий исключительно как кэш центрального и пушить на любой чих.
     
  • 3.107, gaga (ok), 12:57, 13/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Не надо вот этого, пожалуйста. Возможностей ветвтления в ртути в два раза больше, чем в гите, при этом способов выстрелить себе в ногу вдвое меньше, а интерфейс в разы проще, понятнее и логичнее, что видно даже по мануалам - они втрое короче гитовских. Освоение ртути после CVS у меня заняло полчаса, в гите путаюсь до сих пор, хотя использую и то и другое параллельно.
     
     
  • 4.110, arisu (ok), 03:10, 16/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > после CVS

    это просто последствия травмы. меркуриал тоже травмированые делали.

     
  • 2.20, Аноним (-), 01:18, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > проектам, однако для простых смертных разработчиков в небольших коллективах

    Я уж не знаю чем вам git не угодил, но hg по сравнению с ним - довольно противная штука. Мне категорически не понравился. Типовые операции в гите намного резвее.

     
  • 2.30, Привет (?), 09:50, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > однако для простых смертных разработчиков в небольших коллективах удобнее Mercurial + TortoiseHG :)

    Настолько удобнее, что мы используем SVN в нашем небольшом коллективе? ;(

     
  • 2.34, Аноним (-), 12:03, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > TortoiseHG :)

    "разработчик" под пиндой это не разработчик.

     
     
  • 3.40, poplar (?), 15:19, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Только вот их подавляющие большинство. Так что не живите в мире иллюзий.
     
     
  • 4.42, kurokaze (ok), 16:00, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Дадада. А еще большинство слушает попсу и блатняк и жрет всякую гадость.
    У нас в конторе вантузятников хорошо если 3% наберется, так что не надо расписываться за всех.
     
     
  • 5.52, Аноним (-), 17:57, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Дадада. А еще большинство слушает попсу и блатняк и жрет всякую гадость.

    Оно же ломится програмить на VB и прочих питонах и считает что это модно и круто, а всякие там гиты не лицом к пользователю :)

     
  • 4.49, Аноним (-), 17:42, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Только вот их подавляющие большинство.

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


     
  • 4.56, all_glory_to_the_hypnotoad (ok), 18:18, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    АйТи, и кодинг в частности, сейчас стало доступнее. Вполне нормальное явление появление кучи быдлокодеров в профессии. Ну и что что их там куча?
     
     
  • 5.80, Аноним (-), 11:13, 09/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Самое смешное что и такие осваивают гит. Потому что гладиолус^W гитхаб...
     
  • 3.45, добрый дядя (?), 17:35, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> TortoiseHG :)
    > "разработчик" под пиндой это не разработчик.

    TortoiseHG написан на Python + Qt и в 100% полной мере реализован на windows и Linux

    мое мнение таково - скорее Mercurial обрастет фичами из git-а в удобоваримой форме, чем git повернется лицом к пользователю, потому что команды hg - просты и очевидны и всегда работают как задумано, однако заставить git работать как надо - это много гугления, и нет аналога TortoiseHG под Linux

     
     
  • 4.50, Аноним (-), 17:48, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > мое мнение таково - скорее Mercurial обрастет фичами из git-а в удобоваримой
    > форме, чем git повернется лицом к пользователю,

    Писать проект на питоне - это лицом к кому угодно, кроме собственно пользователя программы. Разработчики гнали как на пожар (других вменяемых причин юзать питон нет, ибо тормозное угребище со страшным синтаксисом). Гонка на пожар - была приоритетом #1. Все остальное было вторичным. И да, угребище на питоне никогда не будет быстрым.  

    Хуже адептов питона только програмеры на VB. Давайте еще расскажем что они ща подорвутся и напишут нормальную VCS. Сразу после питонистов, ага.

     
  • 4.61, arisu (ok), 20:30, 08/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > TortoiseHG написан на Python + Qt

    уже после этого его можно выкидывать.

    > чем git повернется лицом к пользователю

    а зачем *пользователю* гит? O_O

    > потому что команды hg — просты и очевидны и всегда работают как задумано

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

    > однако заставить git работать как надо — это много гугления

    O_O

    > и нет аналога TortoiseHG под Linux

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

     
     
  • 5.81, Аноним (-), 11:19, 09/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    О, Капитан Я собственно так и делаю - я теперь по зависимостям чекаю до инсталл... большой текст свёрнут, показать
     
  • 4.76, Аноним (-), 10:46, 09/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    новость не читаем, про gitk ничего не знаем... но неистово комментируем!
     
     
  • 5.78, Andrey Mitrofanov (?), 10:50, 09/04/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это же Вы не понимаете! Тортуаз - интеграция с Майкрософт Уиндоуз Эксплорером. Нету этой интеграции для линуксов. ОМГ, не-ту!!! </нипанятнаа>
     
     
  • 6.82, Аноним (-), 11:21, 09/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Тортуаз

    Название то какое. Сантехнический узел прямо.

     
  • 2.77, Аноним (-), 10:48, 09/04/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    GUI удобен только как смотрелка дерева коммитов, не более.

    > для простых смертных разработчиков в небольших коллективах удобнее Mercurial + TortoiseHG

    феерично каждый день мержить головы

     
     
  • 3.83, MaMoHT (?), 11:29, 09/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > феерично каждый день мержить головы

    как будто у гита нету голов. сказки то че рассказываем? нужен бы был glog в гите, если бы там ветвлений истории не было.


     

  • 1.89, Kibab (ok), 20:02, 10/04/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Тем кто и сейчас ничего не понял, вот в помощь несколько выдержек:
    ****
    We immediately lose the concept of version numbers. A downstream consumer has to use the git tools to query if a particular change is present in their stream. That has implications for security alerts as you have to be a git consumer. (Unless they're on a release CDROM image cycle of course.)

    ...

    Or the tree is locked while somebody is uploading from a 28.8k modem in the back of Nigeria.

    It's not so much an issue for Linus because there are so few committers to the root tree. It's a pull model.

    ***

    Basically, committing to a shared repo with git is really really hostile and not a design feature. It assumes there is somebody like Linus to receive patches in email and merge them into their repo locally and publish the results, rather than having 300 people racing each other to try and get a commit in before their rebased work is invalidated or branches go stale.

    ****
    But git is not designed for hundreds of people pushing to a shared repo with branches.
    ****
    git really is designed with a single committer who publishes their work in mind.

     
     
  • 2.90, anonimous (?), 23:19, 11/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Тем кто и сейчас ничего не понял, вот в помощь несколько выдержек:
    > ...

    А можно примеры VCS, которые решают приведённые Вами задачи лучше, чем git, по каждому Вашему пункту?

     
     
  • 3.91, Kibab (ok), 00:44, 12/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >> Тем кто и сейчас ничего не понял, вот в помощь несколько выдержек:
    >> ...
    > А можно примеры VCS, которые решают приведённые Вами задачи лучше, чем git,
    > по каждому Вашему пункту?

    SVN, скажем. Поскольку она централизованная, то там как раз используется push model.
    Номера версий в SVN, как мы помним, тоже есть. Причём нумеруется там именно репозиторий в целом, а не отдельные файлы (как в CVS). То есть номер версии однозначно определяет состояние репозитория.
    Я не уверен насчёт случая с Нигерией, поэтому не буду врать.
    Однако то, что пушить в SVN можно действительно сразу нескольким людям, и это не будет вызывать конфликтов (если они не трогают одни и те же файлы) -- это действительно чистая правда :-)

    Со скоростью у SVN неважно по сравнению с гитом, это да. Но это тот случай, когда в целом годную модель можно извратить до состояния SVN. Это отнюдь не означает, что все централизованные VCS -- зло. Просто каждый инструмент решает свою задачу.
    К сожалению, многие этого понять не могут, отсюда -- такое количество фанатов git.

     
     
  • 4.94, anonimous (?), 11:40, 12/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    >>> Тем кто и сейчас ничего не понял, вот в помощь несколько выдержек:
    >>> ...
    >> А можно примеры VCS, которые решают приведённые Вами задачи лучше, чем git,
    >> по каждому Вашему пункту?
    > SVN, скажем. Поскольку она централизованная, то там как раз используется push model.
    > Номера версий в SVN, как мы помним, тоже есть.

    Принято. (только я не понимаю в чём прелесть именно r12345; это хоть сколько-нибудь информативно только при линейной истории).

    > То есть номер версии однозначно определяет состояние репозитория.

    Ну, это как бы сильно на любителя: толи нет бранчей, тэгов, etc., толи side-эффект --- как неявно зацепить все ветки.

    > Однако то, что пушить в SVN можно действительно сразу нескольким людям, и
    > это не будет вызывать конфликтов (если они не трогают одни и
    > те же файлы) -- это действительно чистая правда :-)

    Любимый пример: пробовали ли Вы работать с чем-нибудь монструозным типа boost's (boost.org) SVN? Мне не понравилось (мягко скажем).

    > Со скоростью у SVN неважно по сравнению с гитом, это да. Но
    > это тот случай, когда в целом годную модель можно извратить до
    > состояния SVN. Это отнюдь не означает, что все централизованные VCS --
    > зло. Просто каждый инструмент решает свою задачу.

    Любую DVCS можно использовать в режиме 'с центральным репозиторием'.

    > К сожалению, многие этого понять не могут, отсюда -- такое количество фанатов
    > git.

    Я не обнаружил разумных вариантов, когда SVN имел бы преимущество над git. А когда он принёс кучу проблем --- довольно много.

     
  • 2.92, Cub (ok), 06:46, 12/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Спасибо за ссылку выше. Прискорбно, что разрабы от FreeBSD имеют такую точку зрения. Классная система и команда, но взляды немного закостенели.

    > ... shared repo ...

    Этим всё сказано. Просто чуваки привыкли работать с централизованым репозиторием. А когда постомрели на git - поняли, что он им не подходит. А почему не подходит? А потому, что заточен для де-централизованной работы. Вот ведь неожиданность: средство для де-централизованной работы не подходит для централизованной работы!  Удивительно, да?

    Вывод вполне ожидаем - если хотите централизации, то git не для вас. Впрочем, вывод не нов, и об этом уже везде много раз сказано.

     
     
  • 3.93, Kibab (ok), 10:17, 12/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Классная система и команда, но взляды немного закостенели.

    В чём это выражается?
    Простая истина состоит в том, что инструмент выбирается под задачу, а не наоборот. При переходе на $NEWVCS модель работы не должна кардинально меняться.

    >> ... shared repo ...
    > Этим всё сказано. Просто чуваки привыкли работать с централизованым репозиторием. А когда
    > постомрели на git - поняли, что он им не подходит. А
    > почему не подходит? А потому, что заточен для де-централизованной работы. Вот
    > ведь неожиданность: средство для де-централизованной работы не подходит для централизованной
    > работы!  Удивительно, да?

    Не очень понятен Ваш сарказм. Была поставлена задача -- уйти с CVS и найти что-то более удобное для работы централизованной команды.
    Было проведено исследование: http://wiki.freebsd.org/VersionControl
    Из него видно, что наиболее подходящие кандидаты -- это SVN и git.
    Далее уже обсуждение достоинств и недостатков. В итоге -- SVN был выбран, и не в последнюю очередь из-за GitDrawbacks.

    > Вывод вполне ожидаем - если хотите централизации, то git не для вас.
    > Впрочем, вывод не нов, и об этом уже везде много раз
    > сказано.

    Да. Только, тем не менее, воены Света и git-а так и продолжают флудить в темах про новые версии VCS на Опеннете :-) Хорошо, что это так и остаётся флудом в форумах. Иначе мир бы давно был порабощён GPL, Linux и Бог знает чем ещё.

     
     
  • 4.108, anonymous (??), 14:25, 13/04/2012 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Не очень понятен Ваш сарказм. Была поставлена задача -- уйти с CVS и найти что-то более
    > удобное для работы централизованной команды.
    > Было проведено исследование: http://wiki.freebsd.org/VersionControl
    > Из него видно, что наиболее подходящие кандидаты -- это SVN и git.
    > Далее уже обсуждение достоинств и недостатков. В итоге -- SVN был выбран, и не в
    > последнюю очередь из-за GitDrawbacks.

    Порадовало:

    <snip>
    Ability to work offline -- like on a plane -- without requiring too much work: not only being able to list differences but also to commit
    </snip>

    --- твёрдое Yes для SVN. ;-)

    В http://wiki.freebsd.org/VCSWhy есть очень эмоциональная заочная полемика с Линусом.
    Из неё получается, что "Линус в общем-то прав, но мы испытываем к нему такую неприязнь, что кушать не можем; поэтому что угодно, только не git; а если возьмём hg, то там есть ещё несколько проблем, но самое неприятное, он идеологически сходен с git, а нам неприятен не только Линус, но и идеи, похожие на идеи Линуса".

    Как-то так, а GitDrawbacks ни разу не означают, что этих недостатков нет у других VCS.

     
     
  • 5.109, poplar (?), 15:18, 14/04/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Не знаю где они в Git углядели идеи Линуса. Все идеи Git, да и mercurial тоже, были взяты из monotone и bitkeeper. Линус обычно не создаёт чего-то принципиально нового.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру