Действительно ли возможно определить, объединятся ли два ответвления мерзавца чисто, не влияя на рабочий каталог?
Невозможно достичь этого, используя структуру базы данных, поскольку между вашим корневым узлом и объектами, содержащими свойство name_mov, есть 4 дочерних элемента, mov, bolly, new и заданный идентификатор. .
Вы можете использовать следующий запрос:
Query firebaseSearchQuery = mDatabaseReference
.child("mov")
.child("bolly")
.child("new")
.orderByChild("name_mov")
.equalTo(s);
Но вы сможете получить только названия фильмов, которые существуют в узле new. Если вы хотите получить все титры, вам следует реструктурировать базу данных, добавив тип фильма (новый, популярный и т. Д.) В качестве свойства ваших объектов, а затем просто использовать:
Query firebaseSearchQuery = mDatabaseReference
.child("mov")
.child("bolly")
.orderByChild("name_mov")
.equalTo(s);
Таким образом у вас будет меньше уровень, и запрос будет работать отлично.
4 ответа
Там нет встроенного пути; рабочее дерево требуется для выполнения слияния. Понять, сработает ли слияние (в общем случае), означает попробовать стратегию и посмотреть, что произойдет.
Однако вы можете проверить тривиальный случай: две ветви не касаются одних и тех же файлов. Найдите базу слияния, а затем проверьте, имеют ли git diff --name-only $merge_base branchA и git diff --name-only $merge_base branchB что-нибудь общее.
В противном случае вам понадобится рабочее дерево, чтобы попытаться выполнить слияние. Вы можете легко создать второе - либо клонировать репозиторий, либо сэкономить место, просто создайте рабочее дерево. Сценарий git-new-workdir (из каталога contrib git.git) может помочь с этим; он создает новое хранилище, каталог .git которого заполнен символическими ссылками на исходный. Просто будьте осторожны, что в этом новом рабочем каталоге вы не модифицируете ветку, которую исходное хранилище извлекло - они выйдут из синхронизации, точно так же, как если бы вставка в текущую извлеченную ветку испортила ситуацию.
Я бы сделал это, создав третью временную ветвь. Допустим, вы хотите объединить ветку branchFrom в branchTo. Тогда это будет выглядеть следующим образом:
git checkout branchTo #only if not already at branchTo
git checkout -b branchTmp
git merge branchFrom
# see what happens
git checkout branchTo
git branch -d branchTmp
# act accordingly
Таким образом, вы получите точные результаты, не испортив ни одной из ваших ветвей.
TLDR
Предполагается, что ваша цель слияния извлечена, т. Е. HEAD, а ваш источник слияния равен $BRANCH:
git merge-tree `git merge-base $BRANCH HEAD` HEAD $BRANCH | grep "^<<<<<<<\|changed in both"
Подробности
Предполагая, что ваша цель слияния извлечена, т. Е. HEAD, а ваш источник слияния равен $BRANCH, сначала «найдите как можно больше общих предков для слияния» :
git merge-base $BRANCH HEAD
Выше следует вывести хеш-значение для фиксации; назвать это значение $merge_base.
Далее, «показать трехстороннее слияние без касания индекса» :
git merge-tree $merge_base HEAD $BRANCH
Вышеприведенное должно выводить «тривиальные результаты слияния и конфликтующие этапы на стандартный вывод».
Если HEAD уже обновлен по отношению к $BRANCH, выходных данных не должно быть.
Если есть конфликты слияния, вывод должен содержать маркеры конфликта Git. Вы можете определить, есть ли какая-либо команда, например:
git merge-tree $merge_base HEAD $BRANCH | grep "^<<<<<<<"
Вы также можете найти текст «изменено в обоих»:
git merge-tree $merge_base HEAD $BRANCH | grep "changed in both"
Все вышеперечисленные команды как ( Баш) однострочник:
git merge-tree `git merge-base $BRANCH HEAD` HEAD $BRANCH | grep "^<<<<<<<\|changed in both"
Это был адаптирован из этот ответ на этот вопрос:
Вы не можете сделать это, не затрагивая рабочий каталог, но вы можете сделать это, не затрагивая ваши текущие изменения.
git stash
git merge ...
woops
git reset --hard HEAD
git stash apply
Получится то, что вам нужно.