Как я преобразовываю простой не источник управляемые резервные копии проекта в имеющий версию репозиторий мерзавца?
MAR является деталью реализации. Конвейерный ЦП может не иметь MAR сам по себе или не иметь единственного MAR, особенно если он имеет многопортовый кеш, который может читать + записывать в одном цикле.
В архитектурах с регистром с именем X, X является архитектурным регистром , который хранит свое значение независимо от того, что еще обращается к памяти.
например. абсолютная неиндексированная нагрузка использовала бы MAR для управления адресной шиной, но ЦП все равно должен был бы сохранить то же значение для X. Кроме того, MAR должен быть таким же широким, как физические адреса в машине, но X является только 8-битным регистром в 6502. (Таким образом, вы можете индексировать только 256 байтов из данной базы).
Программный счетчик обычно не доступен напрямую, за исключением режимов адресации, относящихся к ПК, или инструкции вызова хранят где-нибудь адрес возврата. И прыгает, пишет ПК. Но в некоторых отношениях это также деталь реализации; конвейерный процессор не обязательно будет иметь один регистр ПК. Но скалярный конвейер порядка будет эффективно иметь ПК в стадии извлечения. (Или нетранслируемый ЦП, разумеется, будет иметь один ПК.)
Предположительно, выборка кода копирует ПК в MAR как часть загрузки машинного кода для следующей инструкции. [1121 ]
Архитектуры с регистром X включают в себя
- регистр индекса 6502/6510 (8-битный) , который можно использовать в режимах косвенной и абсолютной индексированной адресации. [ 1113]
- Z80 имеет 16-битный
IXрегистр (индекс X), состоящий из 2 8-битных половинок. См. https://retrocomputing.stackexchange.com/questions/6095/why-do-c-to-z80-compilers-produce-poor-code/ для некоторых интересных подробностей о том, как регистры и режимы адресации в 6502 и Z80 не отображаются на модель C указателей, которые можно индексировать целым числом. И нелегко поддерживать режимы адресации относительно стека, затрудняющие рекурсию. - https://en.wikipedia.org/wiki/Freescale_68HC11 имеет 16-битные индексные регистры IX и IY.
- AVR (X - 16-битная конкатенация
r27:r26): Регистры AVR XYZ . Это не ограничено тем, чтобы быть индексом.
8080 имеет HL, а не X.
4 ответа
Там это может быть уже автоматизированный способ сделать это, но git должен быть достаточно умен, чтобы позволить вам git init в вашей самой старой резервной копии, а затем повторно копировать папку .git для постепенно увеличивающихся резервных копий и создать коммит со всем для каждого. Сценарии должны быть довольно просты.
Еще лучше, вы можете передать параметр - git-dir = или переменную окружения $ GIT_DIR в git и использовать его в репозитории, сохранение шага копирования.
Примерно так:
cd $FINAL_DIR
git init
export GIT_DIR=$FINAL_DIR/.git
cd $NEXT_BACKUP
git add -A .
git commit
# rinse and repeat
Вы можете использовать пример Инструменты на основе git-fast-import , распространяемые в репозитории git.git: import-zips.py (на Python) или import-tars.perl (в Perl) , или используйте эти сценарии в качестве основы вашего собственного сценария импорта. Вы можете найти эти сценарии в каталоге contrib / fast-import / .
Я не совсем понимаю, почему вы не хотите просто фиксировать все снимки по отдельности. Я имею в виду, что для этого сценарий оболочки (или Perl, Python, Ruby, Tcl и т. Д.) Занимает менее 5 строк кода и менее 10 минут работы.
Также имеется git load -dirs , что позволит вам сократить его до 3 строк и 5 минут. Но вам все равно придется загружать каждый каталог по отдельности.
Но, если вы так склонны, есть инструмент git fast-import , предназначенный для облегчения написания конвертеров и импортеров репозитория. Согласно справочной странице, вы можете написать импортер примерно за 100 строк и пару часов.
Однако все это игнорирует самую большую проблему: значение VCS лежит не в содержимом - вы также можете использовать для этого регулярные резервные копии - но в сообщениях фиксации. И никакой магический инструмент не поможет вам в этом, вам придется печатать их все в себе… и, что более важно, вы должны будете точно помнить , почему вы делали каждое небольшое изменение за последние годы .
Также ознакомьтесь с разделом «Пользовательский импортер» в главе Переход на Git . который говорит именно об этой проблеме.