Чтобы добавлять сообщения и комментарии, .

@AlexVK:
AlexVK

@cancel составил очень неплохое руководство по git
blog.regolit.com
Не грех прорекламировать, практически то что надо

@max630:
max630

а чего это он в вебке путь до файла в урле не показывает?

@Self-Perfection:
Self-Perfection

Есть ли в природе VCS, которые умеют адекватно работать с файлами, которые фактически являются архивами (e.g. svgz, odt). Посмотрел как это предлагается делать в Fossil и что на эту тему умеет git — всё фигня, по треть решения от необходимого. Нужно:
* Хранить только дифф изменившихся внутри архива файлов
* Причём без дополнительных приплясываний внутри working directory для конвертации архивноформатных файлов между хранимым и редактируемым видом
* Было бы ещё здорово, если б оно в diff могло сравнивать распакованные данные.

@qnikst:
qnikst

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

Как такие вещи вообще принято решать?

@provaton:
provaton

Жаль, что меркуриал медленно помирает. Мне он всегда нравился гораздо больше гита. linux.org.ru

@max630:
max630

Вообще "зачем сохранять промежуточные версии" — вопрос нериторический. cvs — а её проприетарные аналоги ещё продаются за дикие бабки, и немалая доля тех кто принимает решения и обучает в вузах умеет только в них — в общем случае не гарантировала даже что ты сможешь счекаутить и собрать какую-то прошлую версию. Учитывая что писать внятные сообщения к коммитам они тоже не умеют и не учат — остаётся только функция "найти виноватого". Что, действительно, не так уж и ценно.

@ak:
ak

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

@ilardm:
ilardm

Тыщу лет с свном не работал. Как тут посмотреть историю нормально? С ветками. В черепахо-свн. Ну чтоб как в черепахо-хг.

@ilardm:
ilardm

Засовывать какой-нибудь git/mercurial/etc. во что-нибудь типа btsync/dropbox/etc. не самая хорошая идея ведь, да?
Помнится, попытка работать в таком синхронизируемом репозитории приводила к кровькишкирас*о этого самого репозитория.

Я тут пока что остался без домашнего серверка, а репозитории синхронизировать хочется. Но безо всяких там github/bitbucket/etc.

@k0st1x:
k0st1x

попытка залить централизованный репозиторий с исходниками (хрен знает с какой долгой историей) в mercurial — клонирование такого репозитория занимает 30 минут, а смена бранча почти 1 час (диск классический, не SSD).
git вообще не осилил столько гигов.

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

@Mendor:
Mendor

Commit message generator whatthecommit.com

@ilardm:
ilardm

А у вас переход с svn на git/mercurial тоже был, скажем так, не совсем гладким?

@qrilka:
qrilka

youtube.com а реально ли сейчас взлететь новой СКВ?

@beardog-ukr:
beardog-ukr

Сегодня 10 часов утра, практически без объявления войны, преспешники централизированных систем контроля версий, таких как SVN и TFS возглавляемые опытным и опасным полководцем Ярославом Германом, перешли в наступление на хорошо укреплённые баррикады последователей GIT и Mercurial, оборона которых подконтрольна вашему покорному слуге.
<бла-бла-бла>
Приходите в кафетерий офиса на Жилянской и поддержите светлую сторону разработки, блабла

Середина 2013 года, в епаме обсуждают преимущества git относительно SVN

@k0st1x:
k0st1x

лолшто?
youtu.be

@segfault:
segfault

А вот интересно, есть ли такие системы контроля версий, которые при слиянии учитывают синтаксис конкретного языка, то есть, если один разработчик поменял везде название переменной, а другой произвел изменения над кодом, в котором эта переменная (до переименовывания) участвует, то такая система сможет слить изменения автоматически (естестенно, если слияние не тривиальное она должна расценивать это как конфликт) и разрешать таким образом львиную долю конфликтов слияния.
Такое уже есть, или это нинужно ?

@ilardm:
ilardm

А в меркуриале можно как-то закоммитить только определённые строки в файле?
Типа git add --interactive

@qrilka:
qrilka

а это нормальная практика иметь дистро-зависимые файлы (e.g. папочку debian) в основном бранче/репе?

@wwarlock:
wwarlock

У меня тут гранитная табличка с золотыми буквами завалялась.
Баянистая, конечно, но может кто ещё не видел, подниму по-выше:
----
Новый проект (размер не имеет значения) — git init
Новая фича — новый бранч

@KpoxaPy:
KpoxaPy

Вот в svn есть удобная хрень под названием 'blame', чтобы посмотреть кто, что и когда изменял в файле на отрезке ревизий. Есть ли что-то подобное в git?

@Equidamoid:
Equidamoid

Эхх, до чего же хреново жить с свн...

@anton0xf:
anton0xf

фалй несколько раз перемещался по дереву.
как получить список его путей с комитами (на которых он эти пути получал)?

@KpoxaPy:
KpoxaPy

Отчего сениоры не доверяют контролю версий? Зачем комментить старый код, который может когда-нибудь пригодиться, но сейчас не должен использоваться, а не удалить его просто, а когда нужно просто вытащить его из истории? :(

@anton0xf:
anton0xf

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

@ilardm:
ilardm

mercurial 2.2.1 в squeeze-backports поломал авторизацию по http :( пришлось откатываться до древнего 1.6.4

@ilardm:
ilardm

вот смотрю на github и bitbucket и прямо даже теряюсь. у github большое community, у bitbucket куча фич более бесплатных , чем у github + поддержка git'а
чем пользоваться-то?

@Akademic:
Akademic

Как чинить ошибки целостности:
stackoverflow.com
mercurial.selenic.com

@Equidamoid:
Equidamoid

Ещё сильнее люблю dvcs, и начинаю любить git...

@Equidamoid:
Equidamoid

Кто-нибудь пробовал git-svn, как оно?

@neFormal:
neFormal

java@cjryesyes: да, и проблема в том что никто не хочет веток, всё в транк комитят
ne_formal: yesyes, сколько человек?
yesyes: больше 150
yesyes: некоторые даже не знают что такое ветки
ne_formal: эм, стой.. как 150 человек работают с одним транком?. они же тогда дожны перманентно пытаться что-то закоммитить
yesyes: да

@wwarlock:
wwarlock

Столкнулся с тем, что не могу вытащить из SVN-репозитория файл.
Файл закоммитили из под винды с NTFS, а достать пытаюсь под маком с HFS+.
Проблема в том, что его название сильной больше 256 знаков по длине.
Потому получаю ошибку от макоси, что с такими работать не умеет.
Но проблема получается фундаментальная и не зависит от средства контроля версий.
Такой файл можно получить даже просто по почте.

@sss:
sss

почему svn такое тормозное дерьмо ?

@vladimir-vg:
vladimir-vg

открыл для себя hg record, офигительное расширение позволяющее коммитить только часть изменений в файле.

@rakoth:
rakoth

Я не так давно радовался возможности коммита из IDE, а сегодня порадовался тому, что-таки не забываю консоль.
чарма весь день рапортует, что коммиты успешны, даже 2 раза пуш делал — всё супер!
Смотрю, в очередном коммите нет нового файла(обычно чарма их предлагала добавить тут же), лезу в консоль и...
$ hg st
M main/web_responses.py
? reportapp/__init__.py
? reportapp/tests.py
? reportapp/views.py
Это ли не чудо? Новый каталог вообще не добавлен! Не беда, добавляем, коммит, пуш и
abort: push creates new remote branches: dev_reports!
(use 'hg push --new-branch' to create new remote branches)
А мужики-то не знали!^W^Wчарма ничего не сказала.

@rakoth:
rakoth

Впервые за несколько лет воспользовался возможностью коммита из IDE(vim не считаем). И это... это работает!
он сам сумел hg commit -m "[+] new feature" && hg push
НЯ, товарищи!

@k0st1x:
k0st1x

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

@k0st1x:
k0st1x

вот поработал с git на github'е, поигрался с hg на досуге.
выводы (субъективные):
git для красноглазиков (даже используя TortoiseGit!!), юзает много чего из msys'а, под виндой это очень неудобно.
hg, по сравнению с git'ом, глоток свежего воздуха — работает все из коробки, кроме tortoisehg ставить больше ничего не надо, даже web сервер в комплекте идет

резюме: буду юзать git только если надо (как сейчас — патчи отсылать).
для себя, для своих новых мелких проектов буду юзать hg

@Elemir:
Elemir

Этот ваш hg не умеет скачивать с глубиной один? А нафига так жить?

@asmer:
asmer

Дайте мне сравнение современных vcs-систем с плюсами и минусами.

@k0st1x:
k0st1x

все-таки завел себе аккаунт на github'е....
к чему бы это