git и прочие, 2 года спустя

[netch80]

Убедился, что упорно предпочитаю git остальным средствам, но это никак не связано собственно с распределённостью, а с несколькими фишками:
1. Понятие отдельного "индекса" и удобство управления им. Особенно рулит возможность частичного коммита из файла и даже с ручной рихтовкой патча перед его вносом, если add --interactive недостаточно.
2. Лог со включённым в него диффом (git log -p), или описанием изменений (--stat)

Несколько раз натыкались на merge, который таинственным образом поднимал старые, давно неактуальные состояния чего-то, причём сделавший этот merge ничего плохого не заметил (и конфликта, по его словам, не было). Эргономика слияний явно недодумана.

Зато несколько раз ошибся в SVN, сделав svn update в подкаталоге и решив, что и остальная часть дерева тоже обновлена.

Comments

[p1r4nh4.livejournal.com]

Так нихрена кайфа отдельного индекса и не понял. Пользуюсь crecord'ом и доволен им, а индекс в гите в основном скрыт командой commit -a.

Про мерж странно, однако.

[p1r4nh4.livejournal.com]

Я в смысле себе его скрываю, чтоб не путался под ногами, когда не надо. alias ci="commit -a" и всë.

[anatoly borodin (from livejournal.com)]

> Несколько раз натыкались на merge, который таинственным образом поднимал старые, давно неактуальные состояния чего-то, причём сделавший этот merge ничего плохого не заметил (и конфликта, по его словам, не было). Эргономика слияний явно недодумана.

Как это выглядит?

[gegmopo4.livejournal.com]

Зато несколько раз ошибся в SVN, сделав svn update в подкаталоге и решив, что и остальная часть дерева тоже обновлена.
От этого помогает svnversion в сборочных скриптах.

[gegmopo4.livejournal.com]

Например:
$ cat makebranch

#!/bin/sh
if [ $# -lt 1 ]
then
	echo "Usage: $0 BRANCH"
	exit 1
fi
BRANCH="$1"
echo "version=$BRANCH" >branch.version
BASE="https://путь_к_хранилищу"
SRC="$BASE/trunk"
DST="$BASE/branches/$BRANCH"
svnmucc -m "Creating branch $BRANCH" \
	cp "$(svnversion)" "$SRC" "$DST" \
	put branch.version "$DST/build.properties"

С незакоммиченными изменениями или частично апдейтнутое просто не поедет.

[nuclight.livejournal.com]

В hg, говорят, еще более удобно сделали: http://pqr7.wordpress.com/2011/01/07/a-git-users-guide-to-mercurial-queues/

[nuclight.livejournal.com]

Правда, нахрена нужно что оно, что в git - всё равно непонятно. Зачем задерживать и укрупнять коммиты? Понимаю, в CVS с этим было сложно, а сейчас-то завести на такой случай ветку и потом смержить - не проблема.

[http://users.livejournal.com/_slw/]

а как борьба с сабпроектами в git?
методом тотального запрета?