LINUX.ORG.RU

Git 2.1.0

 ,


0

3

Представлен релиз системы контроля версий Git v2.1.0.
Основные изменения:

  • Нарушающие совместимость изменения:
    • Для переменной LESS установлено значение по умолчанию «FRX» вместо «FRSX». Удалён флаг «S», отрезающий длинные строки вместо их переноса;
    • Некоторые каталоги в contrib/ отнесены к категории устаревших и исключены;
  • Логика вычисления длины строк обновлена в соответствии со стандартом Unicode 7.0;
  • git clone при клонировании репозитория с локального диска применяет копирование с использованием жёстких ссылок;
  • При использовании HTTP-транспорта обеспечено более полное информирование о передаваемых сервером ошибках;
  • git commit --date=<date> теперь поддерживает больше форматов временных меток, в том числе --date=now;
  • В git replace добавлена опция --graft для перезаписи родительского коммита;
  • Оптимизирована работа git diff при сравнении трёх и более деревьев;
  • В git svn добавлена возможность работы с некорректно сформированными временными метками;
  • git mergetool может использовать в качестве бэкенда vimdiff3.

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

★★★★

Проверено: fallout4all ()
Последнее исправление: maxcom (всего исправлений: 4)

Ответ на: комментарий от Pyzia

Как развернуть гит у себя?

git init # новый репозиторий с исходниками

git init --bare # новый "голый" репозиторий, обычно используется на сервере VCS

Что такого почитать по нему?

Pro Git. А ещё в интернета есть куча хороших туториалов, погугли git branch interactive tutorial

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

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

Pinkbyte ★★★★★
()

Для переменной LESS установлено значение по умолчанию «FRX» вместо «FRSX». Удалён флаг «S», отрезающий длинные строки вместо их переноса;

Годнота! Задолбался уже удалять этот флаг руками... теперь по дефолту =)

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

Да ладно, hg сделан для инопланетян с subversion головного мозга. Что там вообще сейчас такого хорошего по сравнению с git, кроме patch queues?

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

Да ладно, hg сделан для инопланетян

О, представитель внеземного разума в треде.

Что там вообще сейчас такого хорошего по сравнению с git, кроме patch queues?

Еще hg умеет показывать историю.

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

Будет, но отрицательный.

Ясно, я так и думал.

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

Еще hg умеет показывать историю.

Для того, для чего разрабатывался git, а именно сверх большой распределенный проект, типа ядра линукс, подход hg неудачен. Все эти большие и мелкие хаки в гит сильно упрощают жизнь Линусу, а hg это, на мой взгляд, удачная замена svn, но не git.

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

эти большие и мелкие хаки в гит сильно упрощают жизнь Линусу

Именно. Git - это система лично для Линуса, поддерживающая именно его стиль работы.

hg это, на мой взгляд, удачная замена svn, но не git.

Я бы сказал, что Mercurial - это именно распределенная система управления версиями. А Git - это система для обмена патчами.

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

Именно. Git - это система лично для Линуса, поддерживающая именно его стиль работы.

Учитывая что на нем можно все, то стиль работы на Git любой.

Я бы сказал, что Mercurial - это именно распределенная система управления версиями. А Git - это система для обмена патчами.

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

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

Я бы сказал по другому. Git система для выстраивания красивых деревьев разработки.

«Красивые деревья разработки» - это иерархия разработчиков или результирующий граф ревизий? Если второе, то в Mercurial с этим всё нормально, а с доведением evolve станет еще лучше.

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

Я бы сказал, что Mercurial - это именно распределенная система управления версиями. А Git - это система для обмена патчами.

А можно подробнее эту мысль или ссылку?

gv
()
Ответ на: комментарий от unclechu

Ага, и commit date тоже перепишешь?

Бесполезная опция, очень легко проверить что ты задним числом комиты делал.

Не люблю когда люди что-то задним числом делают.

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

«Красивые деревья разработки» - это иерархия разработчиков или результирующий граф ревизий? Если второе, то в Mercurial с этим всё нормально, а с доведением evolve станет еще лучше.

Таки нет. Формально порядок. Неформально, дополнения в разных комбинациях не тестируются. Поэтому активном перекалбашивании постоянные крахи репозитария.

Проблема в том, что все дополнения официально рекомендовано делать методами, которые непитонисты считают хаками.

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

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

Ага, и commit date тоже перепишешь?

Бесполезная опция, очень легко проверить что ты задним числом комиты делал.

Не люблю когда люди что-то задним числом делают.

Вообще то она для формирования дерева из других (негит) источников.

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

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

Какие именно дополнения?

Поэтому активном перекалбашивании постоянные крахи репозитария

За последние несколько лет у меня «падала» только рабочая копия. От заведомо сырого evolve. Каким образом у тебя падал аж репозиторий, от какой комбинации плагинов?

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

Во-первых, в Mercurial всё так же. Во-вторых, у git нижний уровень, как мы все знаем, тупая content-addressable FS, а выше - говно, не умеющее в историю.

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

Ну хорошо,а смысл? Рядом будут стоять две даты. Если это для истории, то переливать из одного источника особого смысла нету. Проще старую разработку оставить там где она есть, а новую начать уже в гите например. Если для текущей разработки, то можно просто слить как есть.

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

Я бы сказал, что Mercurial - это именно распределенная система управления версиями. А Git - это система для обмена патчами.

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

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

Бесполезная опция, очень легко проверить что ты задним числом комиты делал.

Мне тоже кажется что отключиться от сети и временно поменять системную дату проще. Ещё для этого надо утилитку сделать которая просканирует каталоги и поменяет даты у слишком новых файлов:)

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

Во-первых, в Mercurial всё так же. Во-вторых, у git нижний уровень, как мы все знаем, тупая content-addressable FS, а выше - говно, не умеющее в историю.

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

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

Ну хорошо,а смысл? Рядом будут стоять две даты. Если это для истории, то переливать из одного источника особого смысла нету. Проще старую разработку оставить там где она есть, а новую начать уже в гите например. Если для текущей разработки, то можно просто слить как есть.

С помощью таких опций, кстати, воссоздали дерево разработки первоначального ядра линюкс, так сказать для истории. Все более наглядно и удобно для изучения.

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

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

Тех, кого заставляют писать комментарии и описания коммитов только на английском в итоге вырабатывют свою терминологию, которую не знает никто, кроме тех, кто писал. Это на порядок хуже просто русского. Лучший вариант, работают на русском, если надо продать забугор, проводиться подготовка исходников и дерева разработки. Да, дополнительные затраты. Но они не велики и их может вообще не оказаться.

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

Ну если кому-то дата чем то поможет, пусть пользуются:) Для истории это может быть важно.

vitalikp
()
Ответ на: комментарий от actionless

Сравниваешь свои изменения с оригиналом и с изменениями, которые сделала третья сторона.

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

Не стоит хаять гит только потому, что вы им не пользуетесь.

Я им пользуюсь. Немного, но мне хватает.

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

В меркуриале рекомендуют заменять стандартные реализации своими. При работе нескольких таких заменяльщиков проболемы неизмебжны.

А при работе через API, конечно же, нет. Ага, верим.

И ты так и не назвал список расширений, которые ломали тебе репозиторий.

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

А при работе через API, конечно же, нет. Ага, верим.

При работе через АПИ нет подмены стандартных реализаций своими.

И ты так и не назвал список расширений, которые ломали тебе репозиторий.

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

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

При работе через АПИ нет подмены стандартных реализаций своими.

Это неважно. Да и никто не требует, чтобы плагин обязательно модифицировал существующие команды - можно вводить свои. Да хоть через command server работать.

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

reset? Я даже не припомню, какое расширение его предоставляло %) И как-то сомневаюсь, что оно ломало репозиторий - это операция над рабочей копией.

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

Да и никто не требует, чтобы плагин обязательно модифицировал существующие команды - можно вводить свои. Да хоть через command server работать.

Проблема в том, что это рекомендованный метод.

reset? Я даже не припомню, какое расширение его предоставляло %) И как-то сомневаюсь, что оно ломало репозиторий - это операция над рабочей копией.

В гите операция называется ресет. Откат изменений. Можно на неопределенное количество комитов. Как сейчас это реализуется в hg не знаю.

Да сначало это в твоем дереве. Но после заливки на сервер и там.

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

никто не требует, чтобы плагин обязательно модифицировал существующие команды - можно вводить свои. Да хоть через command server работать.

Проблема в том, что это рекомендованный метод.

Если надо менять поведение существующих команд - да, естественно. Но тот же mq изначально был сделан без перекрытия команд, не знаю, как сейчас.

В гите операция называется ресет. Откат изменений. Можно на неопределенное количество комитов

В git это тоже тупо изменение рабочей копии.

Да сначало это в твоем дереве. Но после заливки на сервер и там.

okay.jpg

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

Одному мне гит кажется не юзабельным без SourceTree/Tortoise Git/Tower в командных проектах?

Да. Как показывает практика, GUI для Git — вещь из раздела «умному не надо, дураку не поможет». Либо знаешь как что работает, пользуешься и GUI только тормозит процесс, либо не знаешь и будешь лажать на каждом шагу вне зависимости от интерфейса.

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

Бессмысленно. Вообще важен не vcs как таковой, а платформа.

Это сущая правда.

Например, github/bitbucket (у которых, кстати, имеются корпоративные версии с возможностью установки на собственном сервере).

А вот это — «эталонное нинужно». Доверять непубличный код помойкам вроде GitHub или BitBucket может только завзятый стартапщик. Ни первый, ни второй не обладают сколько-нибудь полезными уникальными функциями, которые бы могли перевесить все их недостатки, включая юридические.

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

Доверять непубличный код помойкам

Почему «помойкам»? Твой непубличный код останется на твоем собственном сервере. А разводить там помойку или не разводить это твое собственное дело.

полезными уникальными функциями

Обладают, иначе бы бесплатных клонов не было.

Reset ★★★★★
()

А докачку так и не запилили?

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

Почему «помойкам»? Твой непубличный код останется на твоем собственном сервере. А разводить там помойку или не разводить это твое собственное дело.

Потому, что программисты GitHub не умеют в безопасность. А программисты Atlassian и в безопасность, и в программирование. Пускать этот ужас внутрь собственной сети? Спасибо, есть альтернативы у которых и грехов за душой меньше, и стоят ноль, и внимания к себе требуют максимум столько же, а порой и меньше.

Обладают, иначе бы бесплатных клонов не было.

Кто чей клон — вопрос интересный и неоднозначный. Но это будет совершенно бессмысленный спор, мне всё же нужно, чтобы работало, а не кто первый придумал.

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

Потому, что программисты GitHub не умеют в безопасность

Безопасность должны обеспечивать админы. Если твои админы выставляют жопой в интернет корпоративный vcs, то гнать их сцаными тряпаками надо, а не жаловаться на «плохих» программистов!

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

Можно посмотреть список альтернатив?

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

Git система для выстраивания красивых деревьев разработки.

вот я где-то так и предполагал, да

С возможностью менять все и вся без возможных проблем.

линус подтверждаэ http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html

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

Я тоже в *своих* проектах использую исключительно hg, несмотря на каждодневные пляски с гит :-)
Имхо, прелести git сильно преувеличены.

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

Проблема в том, что это рекомендованный метод.

ссылку в студию

Как сейчас это реализуется в hg не знаю.

hg bookmark name --force --rev abcd1234
littlechris ★★★
()
Ответ на: комментарий от littlechris

Анонимные бранчи, это что-то легче букмарков? Если да, то зачем, чем это лучше git checkout -b experiment_foo? Что такое фазы? Маркеры, я так подозреваю, это чтобы нормальные (не легкие) закрытые бранчи метить?

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

Гитоводы как раз не любят это делать, потому, чтобы понять гит достаточно посмотреть пару картинок (http://eagain.net/articles/git-for-computer-scientists/), а дальше всё интуитивно. Это в меркуриале всё сделано странно, и объясняется это тем, что в отличие от гита у них есть «куча отличной документации, которую можно читать».

По ссылкам, первую смотрел когда-то давно, там вроде рассказывалось про тяжелые («нормальные») бранчи и легкие, как у нас (букмарки). Чем это «лучше», чем в гите там не объясняется. В остальном, если не можешь в двух словах объяснить зачем это надо и чем оно лучше, не звезди.

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

Гитоводы как раз не любят это делать,

аа, это они просто других людей в маны чуть что посылают. понятно.

чтобы понять гит достаточно посмотреть пару картинок (http://eagain.net/articles/git-for-computer-scientists/), а дальше всё интуитивно

в народе ходит такая пословица — какую мурзилку прогит не читай, а за ответами всё равно на stackoverflow идти

первую смотрел когда-то давно,

короче, она немного устарела, да

в общем коммиты от detached HEAD как раз и образуют анонимные ветки. легче некуда, как по мне.

фаза — свойство коммита, определяющее, встречался ли коммит во внешнем мире и можно ли его туда выпускать вообще. помогает предотвращать инциденты вроде http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html и позволяет иметь приватные локальные ветки. В гите такого нет, несмотря на спрос.

obsolescence markers — свойство коммита. перечисляет, которые коммиты отменяет рассматриваемый. позволяет спокойно переколбашивать историю на одном конце, и при этом не доставлять головняков коллегам (коллеги забирают правленую историю, говорят «хм», командуют hg evolve, решают конфликты при наличии оных и работают дальше). https://www.youtube.com/watch?v=4OlDm3akbqg наглядно это демонстрирует.

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