Баянистая, конечно, но может кто ещё не видел, подниму по-выше:
----
Новый проект (размер не имеет значения) — git init
Новая фича — новый бранч
$ git svn rebase
…
File name too long
could not detach HEAD
rebase refs/remotes/git-svn: command returned error: 1
Можно это вылечить как-то ещё, а не скачивая каждую папку в отдельную свн-репку и потом объединяя через graft?
Джошуа Редстоун (Joshua Redstone) пожаловался в листе рассылки Git на некоторые проблемы с производительностью, которые возникли у Facebook на большом репозитории. Они создали синтетический репозиторий и провели тесты.
habrahabr.ru
Имею желание оптом заменить grep'ом вхождение какой-то строки (пути к директориям) на новое значение.
Понятное дело, что, раз это бинарный формат, то весь индекс разрушится к чёрту.
Может быть есть уже готовые решения?
С помощью "git svn" стянул внушительную репку.
Часть файлов постоянно находятся в состоянии untracked.
У меня такое бывало раньше из-за разницы в регистрах букв, однако опция core.ignorecase = true.
Конечно, если добавить эти файлы и закоммитить, то проблема как бы снимается, но я не могу отправлять этот коммит обратно в SVN.
Как такое побороть? Кто-нибудь сталкивался?
Попросил переименовать одну папку с сырцами в корне проекта BouncyCastle.
Вот уже около 5 часов грузит процессор на полную катушку и перемещает по одному файлику в секунду.
Мониторю изменения через git.
Пару часов назад файлики перестало выдавать, но нагрузка на прежнем уровне.
workflow обычно протекает довольно стандартно:
git checkout master
git svn rebase
git checkout -b newfeature
…
hack-hack-hack
…
git commit
…
hack-hack-hack
…
git commit
// Если коммитов несколько, то обычно объединяю в один
git rebase -i …
// Вливаем изменения
git checkout master
git merge newfeature
git branch -D newfeature
// Проверяем изменения в SVN
git svn rebase
git svn dcommit
И обычно у меня не бывает много коммитов в ветке newfeature.
И редкая ветка newfeature жила дольше недели.
Но сейчас у меня вырос целый куст возрастом полгода.
Чтобы не засорять SVN я опять смёржил все коммиты в один перед вливанием:
git checkout newfeature
git checkout -b newfeature-merge
git checkout master
git merge newfeature-merge
git branch -D newfeature-merge
И, вот, теперь чешу репу (не гита, а свою), что мне теперь делать со всем остальным добром в newfeature — жалко терять историю коммитов, но и лишние ветки тоже мозолят глаза.
Шумно падает в обморок от такого действа.
А встроенных средств переключения не имеет.
Приходится предварительно выходить из него.
AppCode потестировать руки не дошли, может там всё хорошо...
#1374908 написал свой первый скрипт на Руби )
Говнокод конечно, но может кому пригодится.
Скрипт считает хэш файла, так же как это делает гит.
И затем с этим хэшем возможны любые гитовые операции.
Например, просмотр содержимого блоба, через git show.
Для Говнокод конечно, но может кому пригодится.
Скрипт считает хэш файла, так же как это делает гит.
И затем с этим хэшем возможны любые гитовые операции.
Например, просмотр содержимого блоба, через git show.
И что делать, если файл, который находится под контролем вы меняете локально, и эти изменения нельзя коммитить.
В обоих случаях .gitignore не работает. А действовать надо так
stackoverflow.com
@alblue #inevitable
На сегодня, существуют два типа разработчиков: использующие #git, и те кому предстоит это в будущем То есть, если я хочу при перебазировании сохранить СВОИ изменения, то я должен написать THEIRS, например:
git rebase -s recursive -X theirs master
При обычном мёрже, эти понятия действуют as-is.
— Начал чистку значащего содержимого тэгов от невидимых знаков.