Товарищи 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

[shaplov.livejournal.com]

Как его чекаутнуть? Мне в мане не удалось найти подходящей команды...

И он его предки тогда сборщиком мусора не соберутся?

[wrar.livejournal.com]

git checkout имя, точно так же как для всего остального.

Не соберутся.

[shaplov.livejournal.com]

git svn clone file:///.data/svn_convert/svn/ -t tags -b branches -T trunk

затащил мне в репозиторий только транк... :-/

$ git branch
* master

Я что-то не так сделал?

[wrar.livejournal.com]

А tags и branches в исходном репо точно были? Ещё можно почитать, что писалось в процессе клонирования.

[shaplov.livejournal.com]

Точно были...

Ага... ладно...
При следующей попытке запущу логгирование... Хотя вроде бы ничего криминального на stdin'е не было, когда я туда посматривал...

[shaplov.livejournal.com]

Еще...

при импорте в git'е все логи и все annotate'ы имеют историю вплодь до ближайшего копирования/перемещения. До этого история теряется...

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

С этим можно как-то бороться?

[wrar.livejournal.com]

-M

[shaplov.livejournal.com]

А tags и branches в исходном репо точно были? Ещё можно почитать, что писалось в процессе клонирования.

Сделал еще один подход:
В процессе клонирования писалось:

r8891 = 72c601768d80449921be01f365aa9ad461c871f5 (refs/remotes/build-files)
        A       0.9.5/altlinux/altlinux.spec
r8892 = cf523ae6fda276372184efdc5bbf1be080354da2 (refs/remotes/build-files)
        D       altlinux.spec
W: -empty_dir: trunk/altlinux.spec
r8892 = 3c892c3b631ddcd9746b19c51779740ee4c948bf (refs/remotes/trunk)
        M       plugins/spell/spell.cpp
        M       plugins/spell/spell.h
        M       plugins/spell/spellhighlight.cpp
r8893 = a182c4c9b068be4628ffd4d38ffe44f6f900c599 (refs/remotes/trunk)
        M       plugins/spell/spellhighlight.cpp
        M       plugins/spell/spellhighlight.h
r8894 = 81575b6ceb3a45f74936abb96dc5732cf972a4c4 (refs/remotes/trunk)

И так далее...

Внутри .git/info все ветки -- перечисленны:

b82c30fe6d7e7bad35a16a47505ad04761df03ad        refs/remotes/0.9.4
a2a8940468f4093f49fa77b0c72bb96fc4cf1346        refs/remotes/0.9.4-debian
aa8ec465d596bc44f64986938117e411bc273b1e        refs/remotes/0.9.4-windows
35c718750158c567ca1bfe0ad954875a928320ca        refs/remotes/0.9.4@5675
....

но однако на git remote -v оно не печатает ровным счетом ничего...
на git branch говорит что есть только master

[wrar.livejournal.com]

git remote -v смотрит в .git/config, и на svn-remote ему плевать.

git branch -a

[shaplov.livejournal.com]

Собственно через это не работает
git annotate -M -C -C -C
полной истории не показывает, видимо потому что у него нету локально всей истории изменений, и он по ней искать не может...

Как бы эти ветки вернуть на родину?

[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