Доступен (https://lkml.org/lkml/2012/8/19/196) релиз распределенной системы управления исходными текстами Git 1.7.12 (http://git-scm.com/). Git является одной из самых эффективных, надёжных и высокопроизводительных систем управления версиями, предоставляющей гибкие средства нелинейной разработки, базирующиеся на ответвлении и слиянии веток. Для обеспечения целостности истории и устойчивости к изменениям задним числом используются криптографические методы, также возможна привязка цифровых подписей разработчиков к тегам и коммитам. Из проектов, разрабатываемых с использованием Git, можно отметить ядро Linux, DragonFly BSD, Perl, Eclipse, GNOME, KDE, Qt, Ruby on Rails, Android, PostgreSQL, X.org.
Из изменений можно выделить:
- Пользовательские настройки $HOME/.gitconfig теперь могут сохраняться в $HOME/.config/git/config, также автоматически будут задействованы файлы $HOME/.config/git/attributes и $HOME/.config/git/ignore, при их наличии;
- В команде "git apply" появилась поддержка выполнения трёхступенчатого слияния патча на основании базовой версии, если к текущей версии данный патч неприменим;
- Экспериментальная поддержка "git clone --local $path" для использования ссылок или копий из заданного пути при клонировании репозитория на диск;- "git rebase [-i] --root $tip" может использоваться для перезаписи всей истории от момента $tip до корневого коммита;
- В "git rebase -i" добавлена поддержка опции "-x cmd" для вставки в историю результата выполнения "exec cmd" после каждого коммита;
- В "git status" улучшена классификация состояний конфликтов;
- В "git submodule" появилась поддержка работы с вложенными субмодулями;- В contrib-модуле для взаимодействия с mediawiki появилась поддержка вложений;
- Обновлён модуль vcs-svn, в котором устранены проблемы сборки и ограничения при работе на 32-разрядных системах;
- В "git svn" проведена реорганизация операций выборки кода из репозитория, что привело к увеличению скорости работы;
- Проведена оптимизация производительности кода сравнения путей и выполнения команд "git log -n 1 -- rarely-touched-path", "git index-pack", "git pack-objects", git am --rebasing".
URL: https://lkml.org/lkml/2012/8/19/196
Новость: http://www.opennet.ru/opennews/art.shtml?num=34642
джит радует.
Mercurial проще и удобнее для небольших проектов и для командной разработки
дада, кто последний закоммитил, тот и мержит головы!
лишние головы нужно отрубать (ci --close-branch)
Кому нужно и почему? Git как раз удобен тем что каждый может локально делать что угодно, а это все можно вмержить нормально без головняка. Множественные головы - фича а не баг. Способствует разнообразию видов и процветанию проектов.
Больше чем одна голова в ветке - не нужны. Имеется ввиду публичная ветка. Если нужно поддерживать разный функционал, использовать именованные ветки (разные).
Hg тоже позволяет локально делать что угодно.
> Больше чем одна голова в ветке - не нужны.Вам не нужны - не пользуйтесь. А как по мне - при совместной разработке очень удобно, что все желающие могут пользовать свои головы, никому не мешать и при этом вполне себе перекидываться кодом.
> Имеется ввиду публичная ветка. Если нужно поддерживать разный функционал,
> использовать именованные ветки (разные).Ну то-есть, закат солнца вручную, с эмуляцией фичи при помощи костылей и подпорок.
> Hg тоже позволяет локально делать что угодно.А git позволяет иметь по сути множественные параллельные процессы разработки между которыми налажено взаимодействие-синхронизация. Так что если Вася пилит один фич, Петя другой, а Слава третий - они вполне себе живут и не мешают друг другу, имея возможность перекинуться кодом когда наступает подходящий момент. В git это сделано так что естественно накладывается на более-менее типовые практики разработки без каких либо костылей. Ибо писано участниками большой распределенной команды. А вот вы тут начинаете лечить - "туда не ходи, сюда ходи". Система контроля версий должна решать задачи а не создавать проблемы и строить под себя.
> дада, кто последний закоммитил, тот и мержит головы!
> А как по мне - при совместной разработке очень удобно, что все желающие могут пользовать свои головыВас не поймёшь: то не удобно, то удобно. Определитесь!
работайте в разных ветках, чо в общую лезть? не говори что при твоем сценарии git работает иначе
> работайте в разных ветках, чо в общую лезть? не говори что при
> твоем сценарии git работает иначеОн просто позволяет это делать проще и без установки костылей. Те кто его делал в распределенной разработке знают толк. И заботились прежде всего о удобстве своих собственных окороков. Так что кому надо то же что и им (разработка распределенной командой) - очень удобно получается как раз.
вы сударь прямь как секс меньшинства которые вечно кричат о дискриминации. ну нравится вам меркуриал, ну пользуйтесь бога ради. зачем лезть с такими смешными комментариями в пост про гит? наболела? нам плевать.
> смешными комментариями в пост про гит? наболела? нам плевать.Это как ребенок в песочнице пыжится доказать что его игрушечная машинка - почти как настоящая.
ну ето вы перегнули уже
А вы прямо как "православное большинство", которое вечно недовольно тем, что кто-то высказывает мнение, отличное от их собственного. Не нравится комментарий? Не читайте. Есть что возразить по существу? Возразите.
> А вы прямо как "православное большинство"Казалось бы, при чём техническое обсуждение DSCM и просчитанные провокации. Давайте всё-таки мух отдельно.
> просчитанные провокацииС верующими людьми всё-таки интересно общаться. В том числе из-за их способности видеть то, чего нет. :)
> В том числе из-за их способности видеть то, чего нет. :)Докажите.
Что доказать? :)
Что нет.
> Что нет.wrong. доказывает тот, кто заявляет существование. докажи, что ты не рептилоид?
Доказывает тот, кто утверждает.
кто вводит новую сущность, тот и доказывает, что она нужна. отказ это доказать принимается за невозможность сие сделать.p.s. я тебе про рептилоида ведь не зря упомянул. глупый вопрос был, не так ли? вот и не тупи, пожалуйста.
>Я не знаю $TOPIC, но не могу не похвастаться тем, что знаю $OFFTOPIC.
> Я не знаю $TOPIC, но не могу не похвастаться тем, что знаю $OFFTOPIC.я пользуюсь $TOPIC-ом вполтную, и предпочитаю Mercurial
Ну главное чтоб не коз.
> я пользуюсь $TOPIC-ом вполтную, и предпочитаю Mercurialgit для вас слишком быстрый? А пока меркуриал коммиттит, можно перекур устроить.
Единственное преимущество меркуриала.
> А пока меркуриал коммитит, можно перекур устроить.Меркур уж тогда.
>> я пользуюсь $TOPIC-ом вполтную, и предпочитаю Mercurial
> git для вас слишком быстрый? А пока меркуриал коммиттит, можно перекур устроить. Единственное преимущество меркуриала.Мне вот не случалось замечать разницу в скорости отработки команды commit. Очевидно потому, что я Всё Делал Не Так.
нифига он не проще, всё напильником нужно допиливать
> Mercurial проще и удобнее для небольших проектов и для командной разработкиНе знаю что в нем проще. Тормозной какой-то. Git явно делался хардкорными разработчиками под свой рабочий процесс. А hg - "чтобы попрограммить на питоне".
гит
и гит тоже.
/'ɡɪt/
Я придаю большое значение красивому дизайну графического интерфейса, его удобству.
И по-этому, при прочих равных делах, выбрал Git из-за TortoiseGit, т.к. TortoiseHg на его фоне значительно уступал (дело было год назад). Как оно там сейчас, не знаю, но слезать не собираюсь.Так то вот.
> Я придаю большое значение красивому дизайну графического интерфейса, его удобству.
> И по-этому, при прочих равных делах, выбрал Git из-за TortoiseGit, т.к. TortoiseHg
> на его фоне значительно уступал (дело было год назад). Как оно
> там сейчас, не знаю, но слезать не собираюсь.
> Так то вот.молодец, может ты подскажешь адекватное GUI для git под Linux??? и для Mac OS X не забудь
разумеется что TortoiseGit под windows очень крут, я пользовался им
но нормальный, качественный для всех ОС GUI, это именно TortoiseHg, который за этот год был радикально переработан и доделан до состояния конфетки
а git GUI для Linux всё такой же убожеский, какой ни посмотри
git и из консоли весьма удобен, не говоря уже о том, что все его фичи доступны именно оттуда. Я даже на винде стал использовать его из консоли, TortoiseGit включаю только любоваться на граф ревизий
> git и из консоли весьма удобен, не говоря уже о том, что
> все его фичи доступны именно оттуда.Ну привык человек мышкой возякать. Такой вот "программер".
Если ты программист, то использовать GUI неудобно.Для артистов это система контроля версий совершенно не подходит. Есть куда более удобные, которые даже мержи и ветки нормальные для графических файлов поддерживают.
Создание GUI для git только пустая трата времени.
P.S. Пользователи TortoiseGit, без обид, вы хорошие ребята, просто не опытные :)
> P.S. Пользователи TortoiseGit, без обид, вы хорошие ребята, просто не опытные :)Да просто нынче каждая гламурная киса хочет ощутить себя крЮтым разработчиком. Но выглядит в лучшем случае как унылый скрипткидь, каковым и является.
> Если ты программист, то использовать GUI неудобно.Да уж, тоже gitk --all пускаю посмотреть, что как нынче взаимосвязано и как лучше расшивать. Для остального -- zsh и алиасы.
> Для артистов
Английское "artist" на русский переводится как "художник", но не именно "артист" :-)
>Для остального -- zsh и алиасы.Зачем вообще консоль?
Если ваше ide не поддерживает достаточную интеграцию с вашей системой контроля версий - выкидывайте обоих.
>Английское "artist" на русский переводится как "художник", но не именно "артист" :-)Подавляющее большинство artist -ов еще те артисты.
а зачем нужно это самое ide, и что там есть такого суперубойного? кроме фич для быдлокодеров.переключаться между разными файлами позволяет любой нормальный редактор. синтаксис сейчас тоже не подсвечивают только три с половиной инвалида. поддержка ctags тоже есть практически везде. так что такое «ide» и зачем это надо?
IDE: http://ru.wikipedia.org/wiki/%D0%98%D0%B...
/как вы сами любите говорить/ Можете не благодарить
ясно: ответа нет, но решил Блеснуть. ну, блести, мне не жалко.
> /как вы сами любите говорить/ Можете не благодаритьДумаешь, он не знает что такое IDE? Он спрашивал нафиг оно нужно и чего такого уникального там можно делать чего нельзя делать без IDE.
> переключаться между разными файлами позволяет любой нормальный редактор. синтаксис сейчас тоже не подсвечивают только три с половиной инвалида. поддержка ctags тоже есть практически везде. так что такое «ide» и зачем это надо?Меня в своё время IDEA купила с потрохами вот этим — http://tv.jetbrains.net/videocontent/issue-trackers-integrat...
inbefore «мышкопрограмминг» — для всего показанного на экране есть настраиваемые клавиатурные комбинации. Как это делается в этом вашем nano^W vim?
> Меня в своё время IDEA купила с потрохами вот этим — http://tv.jetbrains.net/videocontent/issue-trackers-integrat...классный пустой белый экран.
> inbefore «мышкопрограмминг» — для всего показанного на экране есть настраиваемые
> клавиатурные комбинации. Как это делается в этом вашем nano^W vim?ну, цвета для создания белого фона настраиваются.
> Зачем вообще консоль?1) Потому что в текстовых программах может быть столько фич что они в жизни не уместятся ни на какой GUI в сколь-нибудь юзабельном виде.
2) В гуе невозможно сколь-нибудь быстро найти вон ту редко нужную фичу, зарытую черт знает где. А вот вывод консольных программ подвержен grep'ингу. GUI такое не светит. Так что там где быдлокодер битый час дрюкается перебирая все менюхи и кнопочки, нормальный разработчик просто грепнет встроенный хелпарь и/или ман и за 20 секунд и получит желаемое.
3) Многие операции в консоли делаются быстрее и проще. Бывают ретарды, которые настолько впились зубами в одну парадигму что в принципе не хотят новые осваивать. Но это ошибка природы. С таким мышлением лучше сразу в дворники идти - меньше мучений.> Если ваше ide не поддерживает достаточную интеграцию с вашей системой контроля версий
> - выкидывайте обоих.А еще лучше уволить нафиг идиотов которые без супер-пупер IDE пузыри пускают. Конечно можно маскировать общую некомпетентность индивида крутизной IDE, но какой код такие умники выдают - думаю понятно. Можно на govnokod.ru посмотреть.
> Подавляющее большинство artist -ов еще те артисты.
А мышевозилы в большинстве случаев просто унылы. Мышка - далеко не самый удобный интерфейс для прогарммирования.
> удобный интерфейс для прогарммирования.p.s.: I hate bugs!
> Если ваше ide не поддерживает достаточную интеграцию с вашей системой контроля версий
> - выкидывайте обоих.Мой vim поддерживает, но мне удобней и гибче по старинке. Можно? :)
> но нормальный, качественный для всех ОС GUI, это именно TortoiseHg,Инструменты контроля версий - они для разработчиков а не гламурных кис и скрипткидисов. Первым консоль повышает эффективность работы. А остальным вообще в программирование нефиг лезть.
> молодец, может ты подскажешь адекватное GUI для git под Linux???запросто: любой удобный терминал.
Если вдруг вас действительно интересует GUI для Git под Linux (а не просто опустить его на форуме) - посмотрите Git-плагин к Eclipse (eGit). Хотя использовать его, вероятно, имеет смысл только если вы пользователь Eclipse. Так то вот.
Докачку уже запилили?
Скорее google проспонсирует прокладку оптики по всему миру, чем в git докачку сделают :)
Гит очень не интуитивен и потому очень не удобен. Ощущение что он писался как система управления хранилищем версий, вместо того чтобы быть простым и удобным инструментом для программиста.
> Гит очень не интуитивен и потому очень не удобен. Ощущение что он писался как система управления хранилищем версий, вместо того чтобы быть простым и удобным инструментом для программиста.Слишком субъективно. Мы перешли на GIT именно потому что он был интуитивно понятнее и философия там была четко обозначена с самого начала. В Mercurial только поняли что же они все таки делают.
Меркуриал не пробовал. Народ на гит валит, понятно что возможностей дофига... плохо что философией "простые вещи делать просто, сложные возможно" там и не пахнет =(
>Меркуриал не пробовал.А сравнивая с чем вы сделали вывод, что гит сложен? С кофеваркой что ли? Да, git сложнее кофеварки.
Меня в последнее время начали забавлять стенающие, под копирку, о том что дескать "git сложен" У гитхаба вот 2 000 000 пользователей, у остальных git хостингов наберется под пол миллиона сверху. Заявлять в таких условиях что гит неимоверно сложен для понимания все равно, что заявлять что вы тупее чем пара миллионов человек.
>А сравнивая с чем вы сделали вывод, что гит сложен? С кофеваркой что ли? Да, git сложнее кофеварки.Я сравниваю с CVS и SVN в большей степени. А вы явно клоун.
> о том что дескать "git сложен" У гитхаба вот 2 000 000 пользователей
Вы опросили всех 2000000 чтобы узнать что для них гит не сложен? О чем вообще можно говорить с человеком не отделяющего гитхаб от гита?
> все равно, что заявлять что вы тупее чем пара миллионов человек
Обычно клоуны любят разбрасываться громкими словами, не понимая сути дела. И вы тоже...
>>А сравнивая с чем вы сделали вывод, что гит сложен? С кофеваркой что ли? Да, git сложнее кофеварки.
> Я сравниваю с CVS и SVN в большей степени. А вы явно
> клоун.Клоун здесь как раз ты. Ибо сравниваешь Dvcs с простыми vcs. С тем же успехом можно сравнить DOS с Linux(без иксов) и прийти к выводу о том, что первый проще, забыв при этом сравнить возможности.
Подозреваю, что основная сложность для тебя состоит в понимании концепции dvcs как таковой. После cvs/svn понять dvcs вообще и git в частности действительно сложнее, чем сделать это без знаний о каких-либо vcs вообще. Также в случае с git сильно сбивает с толку похожие на svn названия команд для очень разных по сути действий.
Не пытайтесь показаться умнее чем вы есть на самом деле. И да, вы подтвердили все мои слова:-)
Распределенная система контроля версий не сильно сложнее обычной. Вопрос в том что интерфейс гита сделан как для сисадминов, а не для программистов (при этом кстати для сисаминов он не подходит по нескольким важным фичам, например не умеет полностью сохранять права на файл)
> Не пытайтесь показаться умнее чем вы есть на самом деле. И да,
> вы подтвердили все мои слова:-)
> Распределенная система контроля версий не сильно сложнее обычной. Вопрос в том что
> интерфейс гита сделан как для сисадминов, а не для программистов (при
> этом кстати для сисаминов он не подходит по нескольким важным фичам,
> например не умеет полностью сохранять права на файл)Можете уже наконец сформулировать что в нем такого ужасного ?
> Можете уже наконец сформулировать что в нем такого ужасного ?несовпадение «интуитивностей». а также да — непонимание принципов гита, и потому удивление системе команд.
очередное из серии «почему это я должен понимать, как работает инструмент, чтобы эффективно ним пользоваться?!»
> Распределенная система контроля версий не сильно сложнее обычной.Дело не только в реализации, а и в workflow. Распределённый действительно сложнее, некоторые по этому поводу устраивают "SVN" и из гита.
> Вопрос в том что интерфейс гита сделан как для сисадминов, а не для программистов
Как сисадмин и программист несколько удивлён и был бы благодарен за пояснение такого мнения.
> (при этом кстати для сисаминов он не подходит по нескольким важным фичам,
> например не умеет полностью сохранять права на файл)Не то что "не умеет", а "сознательно не обучали"; доводы или не знаю, или уже забыл. Но если надо -- посмотрите etckeeper :)
> Я сравниваю с CVS и SVN в большей степени. А вы явно клоун.С таким же успехом можно этажерку братьев Райт с аэробусом сравнить.
> А сравнивая с чем вы сделали вывод, что гит сложен? С кофеваркой что ли? Да, git сложнее кофеварки.С меркуриалом, ясенпень. Он и фичастее и проще (как ни парадоксально).
> Меня в последнее время начали забавлять стенающие, под копирку, о том что дескать "git сложен" У гитхаба вот 2 000 000 пользователей, у остальных git хостингов наберется под пол миллиона сверху.
Ну действительно, ведь не могут же ошибаться миллионы мух.
> Заявлять в таких условиях что гит неимоверно сложен для понимания все равно, что заявлять что вы тупее чем пара миллионов человек.
Тупо заучить 5-10 команд может и обезьяна. 90% из этих миллионов так и сделали.
Из ваших посылок
1. Пользователи меркуриал заявляют что "гит сложный"
2. "Даже обезьяна может пользоваться Гитом" - цитата
непосредственно следует что пользователи hg тупее обезьян.
Вы не различаете понятия "сложный" и "неасилил"? Можно пользоваться несколькими инструментами, и одни из них обязательно будут сложнее, другие проще. Это как-то говорит об умении пользоваться?
Кто спорит что компьютер сложнее чем открывалка для пивных бутылок? Так что не напрягайте себя, пользуйтесь тем чем вам легче.
<ванга> ваш путь программировать в машинных кодах
> <ванга> ваш путь программировать в машинных кодахА ваш путь - не понимать как работает написанный вами код и почему это происходит именно так.
> Из ваших посылок
> 1. Пользователи меркуриал заявляют что "гит сложный"
> 2. "Даже обезьяна может пользоваться Гитом" - цитата
> непосредственно следует что пользователи hg тупее обезьян.притянуто за уши.
заучить десяток команд ≪ осознанно пользоваться.
Эта штука называется логика, сынок. Сначала ты кричишь, что 90% пользователей гита обезьяны, потом, что - гит сложный. Вывод - для тебя сложно даже то, с чем справляется обезьяна.
Поэтому и говорят не рой яму другому.
Вы явно из тех 90%. Перечитывать фразу до просветления.
> заучить десяток команд ≪ осознанно пользоваться.Если кто хоть немного понимает как обычно выглядит распределенная разработка, в git он себя ощущает как рыба в воде: все что хотелось бы делать при распределенной разработке - делается просто и удобно. За одно это Торвальдсу медаль дать надо - он вывел взаимодействие открытых проектов на новый уровень.
> Меркуриал не пробовал. Народ на гит валит, понятно что возможностей дофига... плохо что философией "простые вещи делать просто, сложные возможно" там и не пахнет =(А я вот Mercurial пробовал, и по сравнению с GIT он более "детский". В GIT нет многих проблем свойственных Mercurial и под Windows сейчас он куда более стабильнее чем Mercurial, и об этом я к сожалению не могу не думать, так как о братьях наших меньших забывать не могу, не все могут сидеть под Linux, или хотя бы MacOS.
Некоторые вещи под Mercurial до сих пор делаются очень не тривиально и с помощью напильника. В других случаях при нормальном процессе разработки в 99 случаях из 100 разницы нет.
> А я вот Mercurial пробовал, и по сравнению с GIT он более "детский". В GIT нет многих проблем свойственных Mercurial и под Windows сейчас он куда более стабильнее чем Mercurial, и об этом я к сожалению не могу не думать, так как о братьях наших меньших забывать не могу, не все могут сидеть под Linux, или хотя бы MacOS.Ссылок бы на багрепорт(ы) или не было.
> Некоторые вещи под Mercurial до сих пор делаются очень не тривиально и с помощью напильника.
как например?
> В других случаях при нормальном процессе разработки в 99 случаях из 100 разницы нет.
разумно.
> философия там была четко обозначена с самого началаагаконечно. с *самого* начала git представлял собой «dvcs framework на шеллскриптах» и концы этой «философии» торчат из него по сей день.
> агаконечно. с *самого* начала git представлял собой «dvcs framework на шеллскриптах»
> и концы этой «философии» торчат из него по сей день.А меркуриал разве не написан на скриптовом языке?
>> агаконечно. с *самого* начала git представлял собой «dvcs framework на шеллскриптах»
>> и концы этой «философии» торчат из него по сей день.
> А меркуриал разве не написан на скриптовом языке?логическое ударение — на слове «framework». ну и вообще это не имеет значения, потому как hg работает и не путается под ногами.
да, mercurial хорош. стоишь в коридоре, куришь, и завсегда отмазка есть: «а всё равно там hg репозиторий ворочает, жду.» и народ сочувственно кивает.
> агаконечно. с *самого* начала git представлял собой «dvcs framework на шеллскриптах» и концы этой «философии» торчат из него по сей день.Прелесть моя, а ты когда в его исходники заглядывал глаза рукой прикрывал?
>> агаконечно. с *самого* начала git представлял собой «dvcs framework на шеллскриптах» и концы этой «философии» торчат из него по сей день.
> Прелесть моя, а ты когда в его исходники заглядывал глаза рукой прикрывал?Рот. Потому как тошнило.
> Рот. Потому как тошнило.Ну да, вот с тормозной питонятины вас не тошнит зато. Свое - не пахнет? :)
>> Рот. Потому как тошнило.
> Ну да, вот с тормозной питонятины вас не тошнит зато. Свое - не пахнет? :)А я в исходники mercurial и не смотрел никогда. Не было необходимости. В отличие от.
> с *самого* начала git представлял собой «dvcs framework на шеллскриптах»С самого начала он представлял собой lowlevel storage.
--
для поклонников каверов Рабиновича
> агаконечно. с *самого* начала git представлял собой «dvcs framework на шеллскриптах»Вообще-то он представлял собой набор скоростных низкоуровневых утилит связанных между собой шеллскриптами. Нормальный такой кондовый unix way. Лучше поделий от быдлокодеров на голову - все сделано с умом. Решения приняты "потому что вот так - лучше работает". А не "потому что питон рулит" и "что-то зудит попрограммить на моем любимом питончике, фап-фап-фап".
> Гит очень не интуитивен и потому очень не удобен.Возможно, пригодится для понимания: http://los-t.livejournal.com/tag/git%20guts
Т.е. некоторая разношёрстность и впрямь имеет место быть, а stage/index может быть не совсем "в лоб" понимаем при наличии опыта работы только с системами, где либо закоммичено, либо нет -- но концепция и впрямь полезная, без такого "накопителя в коммит" не представляю себе, как бы получалось делать перекройку временных разработочных коммитов в стройную документированную историю перед публикацией: http://tomayko.com/writings/the-thing-about-git
Вообще же неплохая подборка ссылок на документацию, в т.ч. русскоязычную, водится на (изрядно захламившейся) страничке http://www.altlinux.org/git -- внизу там.
угу, git add -p и git add -e нереально рулят. жаль, что мне, например, обычно лень этим заморачиваться. как бы себя приучить…
О. Спасибо, классные вещи.
Да манов много не спорю. Вопрос как раз в том что если хочется сделать что-то ПРОСТОЕ то все равно без ГЛУБОКОГО изученям манов и статей не обойтись.
Я пользуюсь гитом давольно давно, и пока что не сталкивался с задачами которые гит не может решить. Вопрос в том что основные вещи приходиться просто запоминать, они не очевидны. Напримерсоздание бранча через branch и checkout
git init --bare для создания пустого репозитария на сервере. wtf?
а если лезь дальше в дебри то там вообще надо ман открывать параллельно, автодополнение команд совсем не спасает - совершенно неплнятно какая команда что толком сделает и какие параметры нужны.
и т.д. Собственно суть проблемы не в непонимании как гит работает. А в системе его команд, написанных "с нуля" неведомым сумрачным гением.
> хочется сделать что-то ПРОСТОЕ то все равно без ГЛУБОКОГО изученям манов
> и статей не обойтись.Ну так и скажите - "не хочу учиться, хочу жениться!". В общем понятно, hg это для быдлокодеров страдающих легким программизмом. Которым влом детально разбираться как и что работает :)
>> хочется сделать что-то ПРОСТОЕ то все равно без ГЛУБОКОГО изученям манов и статей не обойтись.
> Ну так и скажите - "не хочу учиться, хочу жениться!". В общем понятно, hg это для быдлокодеров страдающих легким программизмом. Которым влом детально разбираться как и что работает :)Если уж трахать мозг, то пусть это хотя бы окупается. Впрочем, есть люди, которые мало что позволяют сношать себя в мозг бесплатно, так ещё и добавки просят. Тут остаётся только посочувствовать.
Да, пистонщики они такие. Ловко ты их
> Если уж трахать мозг, то пусть это хотя бы окупается.Так гит весьма умеренно трахает мозг и воздает за это весьма даже. Просто он писался програмерами, для себя. А не скрипткидями. Поэтому "легкий программизм" - не пройдет. Придется как минимум понять как выглядит разработка в распределенной команде.
> если хочется сделать что-то ПРОСТОЕ то все равно без ГЛУБОКОГО изученям манов
> и статей не обойтись.Брр, для простого с головой достаточно http://www.kernel.org/pub/software/scm/git/docs/everyday.html
> а если лезь дальше в дебри то там вообще надо ман открывать параллельно
Обычное состояние дебрей...
>> Гит очень не интуитивен и потому очень не удобен.
> Возможно, пригодится для понимания: http://los-t.livejournal.com/tag/git%20gutsемнип, это пересказ содержимого первых глав каждой второй/третьей книги «прогит».
Ну и да — почему-то так получается, что ни мне лично, ни другим знакомым мне людям, осваивавшим hg, знания о внутреннем устройстве репозитория не потребовались ни разу, тем более «дляпонимания». Очевидно, я Всё Делаю Не Так.> Т.е. некоторая разношёрстность и впрямь имеет место быть, а stage/index может быть не совсем "в лоб" понимаем при наличии опыта работы только с системами, где либо закоммичено, либо нет -- но концепция и впрямь полезная, без такого "накопителя в коммит" не представляю себе, как бы получалось делать перекройку временных разработочных коммитов в стройную документированную историю перед публикацией: http://tomayko.com/writings/the-thing-about-git
индекс + stash суть кастрированный плагин MQ из поставки Mercurial. С ролью накопителя оно справляется идеально. А аналогом git add -i (не умеет разве что распиливать hunkи) является опять же искаробочный плагин record.
> индекс + stash суть кастрированный плагин MQ из поставки Mercurial.А чем он некастрированней?
> А аналогом git add -i (не умеет разве что распиливать hunkи) является опять же
> искаробочный плагин record.Он кому-то такой кастрированный нужен? (да, я несколько раз в год и hunks препарирую)
>> индекс + stash суть кастрированный плагин MQ из поставки Mercurial.
> А чем он некастрированней?* произвольным количеством patch queue
* возможностью положить patch queue под контроль версий с поведением идентичным обычному репозиторию (т.е. выпнуть patch queue в интернеты (bitbucket так вообще нативно их умеет) на предмет поделиться с единомышленниками/любопытствующими)
например>> А аналогом git add -i (не умеет разве что распиливать hunkи) является опять же искаробочный плагин record.
> Он кому-то такой кастрированный нужен? (да, я несколько раз в год и hunks препарирую)несколько раз в год можно и внешними инструментами пораспиливать
>>> индекс + stash суть кастрированный плагин MQ из поставки Mercurial.
>> А чем он некастрированней?
> * произвольным количеством patch queueЧто-то мне начало подсказывать, что Вы с яичницей перепутали. Пошёл почитать http://mercurial.selenic.com/wiki/MqExtension и вижу:
The patch queue extension integrates quilt functionality into Mercurial.
Занавес.
> * возможностью положить patch queue под контроль версий с поведением идентичным
> обычному репозиториюА для гита ещё и вот такое есть: http://wiki.etersoft.ru/GitUM
> несколько раз в год можно и внешними инструментами пораспиливать
Да, но напрягаться ещё и их вспоминать... там выше было про сохранение чести мозга, угу.
>>>> индекс + stash суть кастрированный плагин MQ из поставки Mercurial.
>>> А чем он некастрированней?
>> * произвольным количеством patch queue
> Что-то мне начало подсказывать, что Вы с яичницей перепутали. Пошёл почитать http://mercurial.selenic.com/wiki/MqExtension и вижу:
>> The patch queue extension integrates quilt functionality into Mercurial.
> Занавес.Пошёл почитать hg help mq и вижу:
> list of commands:
> …skip…
> qqueue manage multiple patch queuesЗанавес, да.
>> * возможностью положить patch queue под контроль версий с поведением идентичным обычному репозиторию
> А для гита ещё и вот такое есть: http://wiki.etersoft.ru/GitUMДа, а ещё и stgit. А в итоге — тот же MQ, только а) для гита, б) сверху (отдельной командой) в) и пото́м — когда ВНЕЗАПНО оказалось, что без patch queue на поверку не обойтись.
>> несколько раз в год можно и внешними инструментами пораспиливать
> Да, но напрягаться ещё и их вспоминать... там выше было про сохранение чести мозга, угу.О да. Ведь намного торвальдсоугоднее держать в уме «как удалить ветку на remote» или «не называть ветки/тэги так же, как файлы — может получиться конфуз при checkout» или «затереть изменения в файле — git checkout filename, а в репозитории — git reset --hard».