Товарищи git'исты и hg'исты!

[nataraj]

Мне похожа нужна консультация по распределённым системам контроля версий:

как я правильно понимаю, и в git и в hg система меток и веток скорее похожа на cvs'ную, а не на svn'ную, то есть они не часть пространства директорий, а некий совсем отдельный вектор.

Соответственно вопросы:

1. Если я единожны создам branch(head) или tag то смогу ли я его потом удалить

2. Если удалить смогу, то как будет осуществляться доступ к тому что было удалено

3. Если не смогу, то как поддерживать порядок, и не копаться в куче древних ветвей

4. У меня в git вся иерархия svn импортировалась деревом c branches/trunk/tags. Мне что теперь чтобы сохранить эту идеологию надо от этой иерархии насоздавать требуемое кол-вто веток, переместить требуемое поддерево в корень и поименовать этот бранч/ затагить? И в результате окажется та же структура но уже в понятиях git/hg?

5. В hg импортировать svn мне не удалось, она пытается иерархию branches/trunk/tags воспринимать как свои ветки и метки, и не осиливает того безобразия которе там творилось за всю историю, и часть истории не импортирует... Вилидимо если xtodin так хочет hg буду ее мигрировать через git

Comments

[wrar.livejournal.com]

Почему annotate, а не blame? Зачем -C три раза? Но это так, мелочи.
Истории изменений может не быть локально только если об этом специально попросили. Можно конкретику, что именно не работает и как?

[shaplov.livejournal.com]

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

Зачем -C три раза?
Чем больше -С тем больше глубина поиска

Можно конкретику, что именно не работает и как?
Тут даже не то чтобы что-то работает не так, скорее я не понимаю как добиться того что мне надо.

Мне нужен репозиторий со всей историей проекта. Если импортировать без ключа -s то тогда в репозиторий попадает вся svn'ая структура директорий /tags/branches/trunk, и в ней если сказать git blame -M -C -C -C то оно покажет авторство каждой строки начиная с начала времен.

Если же импортировать с ключем -S то в репозиторий попадает то что лежит в /trunk а ветки и таги попадают оный remotes Соответственно если в таком репозитории сказать git blame -M -C -C -C на ченджлог, то оно покажет изменения начиная с того места когда были какие-то сильные телодвежения в рамках ветвления...

Чело мне в этом не хватает: Надо научится как это remote ветки перевести в не remote состояние. либо при импорте, либо уже после.

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

[wrar.livejournal.com]

-C вообще говоря нужен для поиска перемещённых кусков кода, а не переименованных файлов.

git log -M докуда изменения показывает?

[shaplov.livejournal.com]

-C вообще говоря нужен для поиска перемещённых кусков кода, а не переименованных файлов.
Гм... однако на скопированных файлах он как минимум дает нужный эффект...

git log -M докуда изменения показывает?
До момента переименования.

git log --follow до начала времен.

[wrar.livejournal.com]

blame -C/-M и log -C/-M это разные ключи.

А log -M это "If generating diffs, detect and report renames for each commit. For following files across renames while traversing history, see --follow."

[shaplov.livejournal.com]

Да, я знаю что разные... Ты попросил log -M я показал ;-)

[wrar.livejournal.com]

Я к тому что blame ни -C ни -M не нужны.

[shaplov.livejournal.com]

$ git blame ChangeLog.old | tail
638a4af2 (wrar 2006-05-27 17:45:20 +0000 180) - The effect "strange sound" is corrected, that is it was really started to 
638a4af2 (wrar 2006-05-27 17:45:20 +0000 181)   play twice
638a4af2 (wrar 2006-05-27 17:45:20 +0000 182) - Are corrected acinclude - now normally is going on KDE 2 and does not require 
638a4af2 (wrar 2006-05-27 17:45:20 +0000 183)   of a key - disable-kde if KDE is not present 
638a4af2 (wrar 2006-05-27 17:45:20 +0000 184) 
638a4af2 (wrar 2006-05-27 17:45:20 +0000 185) Version 0.4 (11.06.2002)
638a4af2 (wrar 2006-05-27 17:45:20 +0000 186) 
638a4af2 (wrar 2006-05-27 17:45:20 +0000 187) Configure with iconv bug fixed (const keyword missed)
638a4af2 (wrar 2006-05-27 17:45:20 +0000 188) Owner info dialog bug fixed 
638a4af2 (wrar 2006-05-27 17:45:20 +0000 189) 

$ git annotate -M -C -C -C  ChangeLog.old | tail
db37f34b        (   shutoff     2002-07-06 23:59:27 +0000       180)- The effect "strange sound" is corrected, that is it was really started to 
db37f34b        (   shutoff     2002-07-06 23:59:27 +0000       181)  play twice
db37f34b        (   shutoff     2002-07-06 23:59:27 +0000       182)- Are corrected acinclude - now normally is going on KDE 2 and does not require 
db37f34b        (   shutoff     2002-07-06 23:59:27 +0000       183)  of a key - disable-kde if KDE is not present 
db37f34b        (   shutoff     2002-07-06 23:59:27 +0000       184)
db37f34b        (   shutoff     2002-07-06 23:59:27 +0000       185)Version 0.4 (11.06.2002)
db37f34b        (   shutoff     2002-07-06 23:59:27 +0000       186)
db37f34b        (   shutoff     2002-07-06 23:59:27 +0000       187)Configure with iconv bug fixed (const keyword missed)
db37f34b        (   shutoff     2002-07-06 23:59:27 +0000       188)Owner info dialog bug fixed 
db37f34b        (   shutoff     2002-07-06 23:59:27 +0000       189)

Это на git'е в которой все единой структурой директорий засосалось...

[wrar.livejournal.com]

Хм, it follows Git ophilosophy that it is contents that matters; see how git blame (and graphical frontends to it like "git gui blame") can follow movement of blocks of code across file boundaries, something that is more generic than wholesame renames of files похоже на правду (но это надо -C -C -C)

[shaplov.livejournal.com]

Более точные вопросы:

1. Правильно ли я понимаю, что оные remote ветки пока в гите не хратятся и будут при обращении к ним затянуты в репозиторий?

2. Как эти remote ветки привратить в обычные локальные, чтобы этот репозиторий можно было вынести на внешний хостинг? Я что-то не осилил.

[wrar.livejournal.com]

1. Хранятся, с содержимым на момент последнего вызова fetch.
2. git checkout -b branch remotebranch