как я развертываю несколько ответвлений на различных каталогах через нажатие мерзавца?
Спасибо за ответы это работает!
И так как исходные файлы находятся в смешанных форматах, я добавил список исходных форматов, которые попробуют в последовательности (sourceFormats), и на UnicodeDecodeError я пробую следующий формат:
from __future__ import with_statement
import os
import sys
import codecs
from chardet.universaldetector import UniversalDetector
targetFormat = 'utf-8'
outputDir = 'converted'
detector = UniversalDetector()
def get_encoding_type(current_file):
detector.reset()
for line in file(current_file):
detector.feed(line)
if detector.done: break
detector.close()
return detector.result['encoding']
def convertFileBestGuess(filename):
sourceFormats = ['ascii', 'iso-8859-1']
for format in sourceFormats:
try:
with codecs.open(fileName, 'rU', format) as sourceFile:
writeConversion(sourceFile)
print('Done.')
return
except UnicodeDecodeError:
pass
def convertFileWithDetection(fileName):
print("Converting '" + fileName + "'...")
format=get_encoding_type(fileName)
try:
with codecs.open(fileName, 'rU', format) as sourceFile:
writeConversion(sourceFile)
print('Done.')
return
except UnicodeDecodeError:
pass
print("Error: failed to convert '" + fileName + "'.")
def writeConversion(file):
with codecs.open(outputDir + '/' + fileName, 'w', targetFormat) as targetFile:
for line in file:
targetFile.write(line)
# Off topic: get the file list and call convertFile on each file
# ...
(РЕДАКТИРУЮТ Rudro Badhon: это включает исходную попытку несколько форматов, пока Вы не получаете исключение, а также альтернативный подход, который использует chardet.universaldetector)
4 ответа
В статье Git push хуже, чем безнадежно есть интересное обсуждение аналогичной проблемы.
Одно из ее решений и выводов включает:
- голый репозиторий на производственном сервере
- клонированный репозиторий с крюком, чтобы вытащить то, что было вставлено в пустой
Итак, в вашем случае
- одно голое репо, на которое вы можете отправить бета-версию и выпустить ветки
- два клонированные репо «beta» и «release» с помощью крючка, чтобы вытащить их соответствующие ветви из чистого репо.
Вкратце: один шаг: git push . Больше нет ссылки для управления (поскольку каталог больше не представляет собой ветку в Git, в отличие от SVN)
Что касается части ловушки, ловушка после получения в чистом репо может быть всем, что вам нужно
См. Совет Git:
Чтобы исправить это, просто отключите GIT_DIR .
'env -i' делает именно это : он полностью игнорирует унаследованную среду и использует только предоставленные переменные и значения.
Я использую такой хук post-receive для публикации моего веб-сайта, потому что Git не касается рабочего каталога при выполнении push. Удаленный репозиторий - это не чистый репозиторий, то есть у него есть рабочий каталог.
if [ -n $GIT_DIR ]; then
# Current dir is "<reporoot>/.git/", but we need to run reset at "<reporoot>/".
# Clearing GIT_DIR is needed, or reset will fail with "fatal: Not a git repository: '.'"
unset GIT_DIR
cd ..
fi
git reset --hard
(Кстати, обратите внимание, что я не могу нажать на "myapp-beta.git" - это не удается, я должен нажать на имя каталога. Меня беспокоит, что это часть проблемы, но я не знаю, что я здесь сделал не так.)
При создании пустого репозитория Git ( git init --bare ), который не имеет рабочего каталога, это соглашение называть каталог «something.git». При наличии репозитория, отличного от чистого, он фактически находится в подкаталоге «.git», поэтому полный путь - «something / .git».
Я не совсем в отличие от других решений, но я думаю, что есть менее хакерский "способ Git" для этого. Вот что я бы сделал:
- На своем сервере я бы установил своего рода централизованное хранилище (для управления Gitosis или чего-то подобного).
- Со стороны клиента я постоянно извлекал из репозиторий, внесите изменения и вернитесь назад. Филиалы, конечно, управляются автоматически.
- I ' d перетащите нужную ветку из Gitosis в public_html / beta_public_html сервера. Я бы периодически синхронизировал его с Gitosis, используя задание Cron. Если вам не нравится идея работы Cron, вы всегда можете использовать какой-нибудь крючок + скрипт, как указывали другие.
Решение состоит в том, чтобы отправить сообщение в единый репозиторий, который будет использовать ловушку update или post-receive .
Есть несколько отдельных возможностей для создания двух касс, которые можно использовать в хуке (на сервере). Переход от самого легкого:
Если вам не нужно, чтобы эти два извлеченных каталога (проверенные версии) на самом деле были репозиториями git, вы можете просто использовать git-archive в экспортировать два снимки состояния (две ветки)
git archive --format = tar --prefix = public_html / master | (cd / var / www / html && tar xf -) git archive --format = tar --prefix = beta_public_html / devel | (cd / var / www / html && tar xf -)где «master» и «devel» - это имена ветвей, которые вы хотели проверить. Обратите внимание, что
- format = tar, строго говоря, не требуется, поскольку формат tar используется по умолчанию для «git archive». Вы также можете удалить старое содержимое («rm -rf public_html /»перед «tar xf -» в первой строке, соединенное с «&&», и аналогично для второй строки).Альтернативный способ экспорта файлов - использовать низкоуровневые команды «
git read-tree» (которые записывают дерево в индекс) и «git checkout -index"(который копирует файлы из индекса в рабочую область).В этом решении репозиторий, в который вы вставляете, может (и должен) быть пустым, т.е. без самого рабочего каталога.
Другим решением было бы, чтобы репозиторий, в который вы нажимаете, имел два рабочих каталога , которые можно создать с помощью сценария git-new-workdir из
contrib / workdir. Каждая из этих рабочих областей должна была быть проверкой соответствующей ветви этого репозитория.Затем хук
updateилиpost-receiveотключил быGIT_DIR, перейти в эти рабочие области (public_htmlиbeta_public_html) и выполните там «git reset --hard».В этом решении «checkouts» будут иметь некоторые связанные с git метаинфо в них (в скрытом каталоге
.git).Еще одним решением было бы иметь два (дополнительных) подчиненных репозитория . После этого нажатие в главный (главный) репозиторий будет (через ловушку) либо протолкнуть эти два подчиненных репозитория, где их хуки будут выполнять «
git reset --hard» или эквивалентный, либо перейти в эти два подчиненных репозитория и выполните там «git pull» от мастера.Эти два подчиненных репозитория будут не голыми и могут быть [непосредственно в]
public_htmlиbeta_public_html]. В этом решении «проверки» будут самими полноценными репозиториями git.Вы можете улучшить эту настройку, сделав эти подчиненные репозитории «альтернативными» (альтернативной базой данных объектов), указывающими на главный репозиторий (т. Е. Клонируемыми с помощью "
git clone --shared ..."); без этого объекта база данных в ведомых устройствах запускается с жесткой привязкой к мастеру. Это, конечно, возможно только в том случае, если ведущее и ведомое устройства находятся в одной файловой системе.Обратите внимание, что это решение позволяет главному репозиторию быть на другом хосте, чем подчиненные репозитории. (хотя я думаю, что такая гибкость вам не нужна).
Наконец, вы можете вместо текущей настройки развернуть gitweb или какой-либо другой веб-интерфейс git (см. InterfacesFrontendsAndTools и ] Gitweb вики-страницы для частичного списка), чтобы ваши пользователи могли просматривать разные версии и разные ветки вашего репозитория в свое удовольствие.
В gitweb (и, я думаю, также в другом веб-интерфейсе git) благодаря поддержке URL-адреса path_info вы можете просматривать файлы в браузере и правильно переходить по ссылкам (если они локальные), см., Например, git.html из 'html 'ветка репозитория git.git на repo.or.cz .
PS »