Релиз Git 1.7.10

хм както никогда не работал с гит напрямую всё через плагины к иде.. зачем ему морда гуишная то?

статистическое конечно падает ибо иде помимо удобства снижает порог вхождения програмистов что позволяет 5 хорошим програмистам писать эффективнее и вводит в статистику 20 непрограмистов которые писать особо не умеют но HallowWord осилили

Да уж. Бросается в глаза.

Какой-то сборник бреда.

Кстати, Git сам Линус рекомендует.

Конечно, он же ее писать начинал. Почему он не должен его рекомендовать :-)

То что после hg pull нужно сделать hg up это охрененно интуитивно.

hg pull -u

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

Ой, а нам в Mercurial новая веточка времена нужна, что же делать? Да. Давайте заведем отдельную папочку и выберем туда репозиторий и будем бегать туда сюда.

hg cat -r номер файл

или hg qnew ... hg qpop ... hg up ... hg qpush ...

или .... еще и другие варианты ...

в общем, выбирай на свой вкус

Фу нафиг так делать есть же плагин Х, давайте для веток его юзать. И ой, а как мне теперь историю коммитов в порядок привести?

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

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

А куда пропал мой код?

а это про что?

И ой, а как мне теперь историю коммитов в порядок привести?

hg transplant ...

или

hg qimport hg qpop ... hg up hg qpush hg qfin

и так далее. че сказки сочиняем? гит и меркариал ничем по функциональности не отличаются. но у меркариал есть тяжеловесные ветки, и дополнительный 'язык' выборки нужных ченджесетов.

Ой, а нам в Mercurial новая веточка времена нужна, что же делать? Да. Давайте заведем отдельную папочку и выберем туда репозиторий и будем бегать туда сюда.

Ну, справедливости ради, git new-workdir - это то средство, при помощи которого удобнее всего вести работу в нескольких логически несвязанных бранчах. Репозиторий при этом, ессно, один.

«зато в гите нету тежеловесных бранчей»

Грамма-наци очень обрадованы этим фактом ;) Остальные пользователи тоже, надо сказать, не особо расстроены.

Ты тупой, что ли? Для создания ветки в меркуриале требуется 0 команд.

Пользователи HG такие няшки!

Ну, строго говоря, не бог весть какая ракетная наука

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

И слава богу. У нас один тип бранчей и для локальной разработки и для пуша в удаленную репу.

ну-ну, а если у тебя куча веток от разных разработчиков, и надо понять, кто в какую ветку коммитил или почему возникло несколько голов - это всё через консольный log смотреть?

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

И после подобного кто-то еще находит в себе наглости говорить что в Mercurial простые и понятные команды?

1000 и 1 один способ создать бранч и следствие этого я везде где работаю с репозиторием должен включать екстеншены, иначе получитца полная лажа.

1000 и 1 один способ создать бранч и следствие этого я везде где работаю с репозиторием должен включать екстеншены, иначе получитца полная лажа.

Если экстеншена нет, то и функциональности нет. Позвольте уточнить - так в чем собственно заключается лажа?

И слава богу. У нас один тип бранчей и для локальной разработки и для пуша в удаленную репу.

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

«зато в гите нету тежеловесных бранчей»
Грамма-наци очень обрадованы этим фактом ;) Остальные пользователи тоже, надо сказать, не особо расстроены.

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

Может кто нибудь внятно объяснить, почему гит для него супер-пупер инструмент, аналогов которому нет? Без эмоций, а именно фактами?

Я одинаково профессионально пользуюсь и гитом и меркариалом. И могу заявить - она идентичны. Но у меркариала: 1. минимум проблем с уникодом. если нужен гит репозиторий, и нужен уникод - hggit самое оптимальное решение. 2. минимум гемора с настройками общего репозитория - когда народу много (> 100), и все в домене, все прямо вах как легко и удобно. про гит я подобного сказать не могу. 3. есть тяжеловесные бранчи - удобнее прослеживать историю. 4. просто крутой язык поиска изменений с помощью revset

Чем гит так крут, что вы на нем циклитесь???? Объясните внятно.

И слава богу. У нас один тип бранчей и для локальной разработки и для пуша в удаленную репу.

В меркариал оба типа бранчей нормально пушатся в удаленную репу, и нормально работают локально. В чем проблема то?

В меркариал оба типа бранчей нормально пушатся в удаленную репу, и нормально работают локально. В чем проблема то?

В том что они еще очень не удобны по сравнению с git. Сам использую Mercurial, но это факт, нет в нем удобных бранчей. То что сейчас есть это костыли, а не бранчи. Так что git тут нас уделывает, зато у нас локальный web сервер уже давно есть и в случии отката создаются резервные копии редактируемых файлов.

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

Не в Mercurial не Git нет проблем с большой историей, все прекрасно видно что откуда взялось. Да даже в svn с этим проблем не было. Как же ты историю изменений так умудряешься изгадить, что разобраться становиться тяжело?

Может кто нибудь внятно объяснить, почему гит для него супер-пупер инструмент, аналогов которому нет? Без эмоций, а именно фактами?

Кому интересны факты когда для Mercurial есть костыли которые через опу сделают из него Git?

Фактов уже было достаточно, только фанаты Mercurial все равно захлебываются слюной что бы в новости про новую версию Git оправдать свой выбор. Зачем вам это, сударь?

Я одинаково профессионально пользуюсь и гитом и меркариалом. И могу заявить - она идентичны. Но у меркариала: 1. минимум проблем с уникодом. если нужен гит репозиторий, и нужен уникод - hggit самое оптимальное решение. 2. минимум гемора с настройками общего репозитория - когда народу много (> 100), и все в домене, все прямо вах как легко и удобно. про гит я подобного сказать не могу. 3. есть тяжеловесные бранчи - удобнее прослеживать историю. 4. просто крутой язык поиска изменений с помощью revset

И я работаю с Mercurial и Git и все просто до безобразия, никаких проблем с настройкой репозиториев. Никаких проблем с юникодом, потому что: не нужен он в проекте, как и Windows в котором-то такие проблемы наблюдаются, причем и в Mercurial тоже с этим могут быть проблемы.

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

Напиши об этом принцессе Селестии

В чем проблема то?

Да бог с ними с бранчами, они нужны только для совсем уж специфичных вещей. mq — вот моя головная боль. Пришлось пилить обертки для повседневных вещей, например рефреш на конкретный патч или быстрофикс с пушем без qpop/qpush. Ну это ладно, самая назойливая беда — режекты. Почему в stgit (совсем уж сбоку приделанный костыль) можно воспользоваться штатными средствами резолвинга конфликтов (маркеры, mergetool), а в mq (казалось бы, изкоробочное решение) — нет?

Всё потому, что кривота на кривоте и кривотой погоняет.

Даже не читая тему могу предсказать, что здесь горит флейм на тему DVCS. :-)

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

тЯжеловесные. Грамма-наци негодуэ ровно по поводу грамматики, сюрпри-из.

Что же касается остальных - то им поровну. То, о чём Вы говорите, чудесно решается на уровне локальных полиси. Типа, для feature-branch'ей заводится (а куда ж без неё!) задача в редмайне, далее во все коммит-месседжи этого фиче-бранча пробивается стандартизованного вида метка (н-р, #12345), которая при просмотре через браузер конвертируется в нужный URL. В редмайне накапливается список коммитов, относящихся к, с фиксацией процента готовности - тоже определяется через соглашения в тексте меток. При мёрже в мастер об этом делается соотв. пометка (типа, мёржу в себя бранч feature/всякая_хрень), можно со списком коммитов (через git merge --log). Ну, в общем, и всё. Не бог весть как сложно придумать и научить остальных. Переезд с CVS/SVN давался сложнее. Замечу для особых ценителей - можно и проще, но описанное выше решение - оно комплексное, этим и хорошо.

Может кто нибудь внятно объяснить, почему гит для него супер-пупер инструмент, аналогов которому нет? Без эмоций, а именно фактами?

Их, в целом, немного. Где-то побыстрее. Где-то, например, в git add -i, Git реализован более толково, чем соотв. экстеншн в HG. Какой-то _внешний_ по отношению к самой DVCS функционал реализован более внятно (н-р, Gerrit и GitHub). При этом, у HG тоже есть плюсы, но они, плюсы из серии «плюс в пацанскую книжечку», а не киллер-фича. Любимый тов. тэйлганнером аргумент о консистентности набора команд для меня особенно убедительным не является. В git'е я помню базовые принципы построения и те команды, которые «в пальцах». HG'шных команд у меня «в пальцах» нет, поэтому мне точно так же приходится ползти в документацию, как и для редкоиспользуемых фич «нелогичного git'а».

когда народу много (> 100), и все в домене, все прямо вах как легко и удобно. про гит я подобного сказать не могу.

Чего-та? Собственно, git'у поровну на аутентификацию, это уровень транспорта/окружения. Хотите ssh (завязанный на LDAP, к примеру) - будет ssh. Хотите ещё чего - будет ещё чего. Если включается (а это неизбежно для команды в 100 человек) система Code Review, то Gerrit, и хоть через вконтактик аутентифицируйся :-)

Чем гит так крут, что вы на нем циклитесь???? Объясните внятно.

Мы не циклимся, мы используем. Типа, Хонда Клаб. А вот какого хрена HG'шники фактически в каждой теме про Git устраивают холивар - мне, чгря, не слишком понятно.

Так, надо бы подбросить дровишек в пламя флейма =)

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

Сделал git fetch, пытался запустить git checkout <tag>, он говорит: не, не буду делать checkout, а то у тебя, мил друг, два файла изменены, надо бы разобраться, почему. Смотрю я, что за те два файла - вроде, ничего нужного, ну я по дурости делаю git checkout -f <tag>. Так эта зараза не только те два файла переписала, но и ещё один, нужный мне...

Вот объясните, пожалуйста, где я маху дал?

Подскажите пожалуйста, как в гите указать ветке куда она пушит по умолчанию.

Например у меня есть локальная ветка feature_1, я хочу чтоб она пушила в удалённую origin/bugfix_1

То есть чтоб было как-то так:

$ git remote show origin
...
  Local branch configured for 'git pull':
    feature_1 merges with remote bugfix_1
  Local ref configured for 'git push':
    feature_1 pushes to bugfix_1 (fast-forwardable)

Во-первых man git-stash

Во-вторых - давайте для ясности скажем так: 1) Вы находились на ветке master и изменили 2 файла (о чём узнали с git status, например)
2) Вы переключились на <tag> git checkout -f <tag>, и поменялось 3 файла
3) Изменения в file1, file2 потеряны безвозвратно
3) file3 отличается в состояниях master и <tag> и, как выпоняли, надо всего-лишь вернутся на master

3) file3 отличается в состояниях master и <tag> и, как выпоняли, надо всего-лишь вернутся на master

то есть, правильно ли я понял, что мои незакомиченные изменения в file3 по-прежнему будут доступны, если я переключусь обратно на master? По-моему, это магия =)

Еще раз внимательно перечитал ответ и понял, что я не прав...

В общем, суть была в том, что я изменил на самом деле все три файла, но git checkout показал мне, что затрет только два из них. При этом сам поменял все три файла. Вот это для меня загадка...

В общем, суть была в том, что я изменил на самом деле все три файла, но git checkout показал мне, что затрет только два из них. При этом сам поменял все три файла. Вот это для меня загадка...

Тогда прощу прощения, нужно воспроизвести конкретную ситуацию ибо я такого не встречал :)

В общем, суть была в том, что я изменил на самом деле все три файла, но git checkout показал мне, что затрет только два из них. При этом сам поменял все три файла. Вот это для меня загадка...

Если третий не добавлялся в tracked, то может всё и логично.

Подброшу к общей теме: ваш гит разделение прав на ветки/каталоги всё так же не умеет? :)

Ой, а нам в Mercurial новая веточка времена нужна, что же делать? Да. Давайте заведем отдельную папочку и выберем туда репозиторий и будем бегать туда сюда.

4.2. http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/

А теперь хочется услышать все тоже самое, только про git rebase

В том что они еще очень не удобны по сравнению с git. Сам использую Mercurial, но это факт, нет в нем удобных бранчей. То что сейчас есть это костыли, а не бранчи.

В Mercurial, вообще-то, больше видов бранчей, чем в Git. Вы неосилили.