, который был доступен с 1.6.2.

ел бы знать, как вы справляетесь с такой ситуацией в Git:

создать ветку task001 от мастераmaster: измените foo.c и переименуйте его в bar.ctask001: измените foo.c и переименуйте его в moo.cобъединить task001 с мастером

Git говорит мне:

CONFLICT (rename/rename): Rename "foo.c"->"bar.c" in branch "HEAD" rename "foo.c"->"moo.c" in "task001"
Automatic merge failed; fix conflicts and then commit the result.

Как мне это решить? Я имею в виду, что я все еще хочу объединить два файла после разрешения конфликта имен.

Благодарю.

 Gauthier13 янв. 2011 г., 14:00
Что находится в вашей области после возникновения конфликта?
 pablo18 янв. 2011 г., 23:51
Это. Исправлю это.
 Cascabel13 янв. 2011 г., 19:35
Являетсяfoo.cs опечатка?

Ответы на вопрос(2)

Простой способ исправить это Сначала отменить текущее слияние

<,code>git merge --abort

Теперь решите, какую версию файла вы хотите использовать, и используйте стратегию слияния (с флагом -s).

Вы на ветке мастера. Если вы хотите сохранить имя, которое вы задали в мастере, используйте эту команду

git merge -s ours task

Если вы хотите использовать версию из задачи

git merge -s theirs task
 Cascabel13 янв. 2011 г., 18:56
Что этоgit merge --abort ты говоришь о? Возможно, вы имеете в видуgit reset --merge? В любом случае вам не нужно прерывать все слияние, чтобы сделать это, и при этом вам не нужно сохранять нашу или их версию длявсе файлы. Просто, после того, как вы достигнете конфликтов, используйтеgit checkout [--ours|--theirs] <path>.
 Abizern13 янв. 2011 г., 21:02
git merge --abort отступает из конфликтующего состояния слияния. Я нахожу это полезным, поскольку это позволяет мне начать снова. А такжея знаю сброса слияния и методы проверки git
 Abizern13 янв. 2011 г., 16:09
Это разрешит конфликты, используя основную ветвь версии файла. Это означает имена и конфликты.
 Benjol13 янв. 2011 г., 14:31
@Abizem, будет ли эта стратегия принимать переименование только с одной стороны, или она также будет принимать содержимое вместо слияния?
 Mark Longair13 янв. 2011 г., 22:19
git merge --abort только в v1.7.4-rc0 и позже - это описано в 35d2fffdb857836 как синонимgit reset --merge, который был доступен с 1.6.2.

что ваш вопрос означает нечто отличное от того, что вы пояснили в комментариях, но первоначальный ответ может оказаться полезным, поэтому я оставляю это как первую часть, но добавляю альтернативу ниже:

1. Просто разрешите конфликт, чтобы у вас были только разошедшиеся moo.c и bar.c

Здесь я предполагаю, что вы хотите получить результатbar.c а такжеmoo.c, с их изменениями из каждой ветки, в объединенной версии. Я бы справился с этим путем разрешения конфликта в индексе и фиксации. Ситуация, которую вы описываете, выглядит следующим образом:

$ git log --pretty=oneline --graph --decorate master task001
* fce127471ab5d1ef55b1d16412a75a7129782517 (task001) Rename to a different file on task001
* 8edbc1357a3c0484dc077f6f7ce43de91d21e794 A small change on the task001 branch
| * d10e9020d147a4bbd3688744823380322bf37718 (HEAD, master) Rename on master to bar.c
| * f952617645456a551df07f219bfdc95e00c8ac9b Added a small change in master
|/  
* e8602eef46af744defd4fb4073ecdb6a7afbfd28 Initial version of foo.c

Если я тогда сливаюtask001 вmaster, он выдает ту же ошибку, которую вы видите:

$ git merge task001 
CONFLICT (rename/rename): Rename "foo.c"->"bar.c" in branch "HEAD" rename "foo.c"->"moo.c" in "task001"
Automatic merge failed; fix conflicts and then commit the result.

затемgit status покажет вам краткое изложение проблем:

$ git status
# On branch master
# Unmerged paths:
#   (use "git add/rm <file>..." as appropriate to mark resolution)
#
#   added by us:        bar.c
#   both deleted:       foo.c
#   added by them:      moo.c
#
no changes added to commit (use "git add" and/or "git commit -a")

Теперь вам просто нужно использоватьgit add а такжеgit rm разрешить конфликты:

$ git add bar.c
$ git rm --cached foo.c
foo.c: needs merge
moo.c: needs merge
rm 'foo.c'
$ git add moo.c
$ git status
# On branch master
# Changes to be committed:
#
#   new file:   moo.c
#

(Я использовал--cached для удаленияfoo.c потому что его больше нет в рабочей копии, и--cached означает, что команда смотрит только на индекс, иначе вы получите сообщение об ошибкеfoo.c не существует.)

Тогда вы просто фиксируете результаты:

$ git commit
[ save the prepopulated commit message ]

И вы разрешили конфликты иbar.c а такжеmoo.c в слитой версии.

(Мимоходом отмечаю, чтоgit merge -s resolve работает для меня в простом примере ситуации, описанной здесь, но я надеюсь, что это в целом полезно.)

2. Объединение bar.c и moo.c обратно в один файл

Из ваших комментариев ниже видно, что на самом деле вы хотели бы объединить эти файлы обратно в один, с изменениями в файле в обеих ветвях. Если вы хотите, чтобы стратегии слияния git помогли вам в этом, файлы в каждой веткедолжен перед объединением используйте один и тот же путь, поэтому перед слиянием необходимо переименовать хотя бы один из них. Предположим, вы хотите, чтобы объединенный файл вызывалсяquux.cхотя вы могли бы сделать этоfoo.c опять же конечно. Затем вы можете выполнить следующие шаги, которые переименуют файл в каждой ветви перед слиянием:

# Rename the file on master:

$ git checkout master
Already on 'master'
$ git mv bar.c quux.c
$ git commit -m "Rename bar.c to quux.c on branch master"
[master f9b3f49] Rename bar.c to quux.c on branch master
 1 files changed, 0 insertions(+), 0 deletions(-)
 rename bar.c => quux.c (100%)

# Rename the file on task001:

$ git checkout task001 
Switched to branch 'task001'
$ git mv moo.c quux.c
$ git commit -m "Rename moo.c to quux.c as well on branch task001"
[task001 c71ad89] Rename moo.c to quux.c as well on branch task001
 1 files changed, 0 insertions(+), 0 deletions(-)
 rename moo.c => quux.c (100%)

# Switch back to master, and merge in task001:

$ git checkout master
Switched to branch 'master'
$ git merge task001

Если изменения не вступают в конфликт, то в этот момент это слияние должно просто работать. В примере, который я пробовал, они конфликтовали, поэтому мне нужно было отредактировать файл,git add файл и зафиксируем результат:

Renaming foo.c->quux.c
Auto-merging quux.c
CONFLICT (content): merge conflict in quux.c
Automatic merge failed; fix conflicts and then commit the result.
$ emacs -nw quux.c 
$ git add quux.c
$ git commit
[master 8baa7cb] Merge branch 'task001'
$ ls
quux.c
 Mark Longair13 янв. 2011 г., 22:21
@pablo: я спрашивал о том, что выхотеть чтобы увидеть :) Но я думаю, что теперь понимаю - я обновлю свой ответ завтра ...
 Mark Longair13 янв. 2011 г., 21:35
@pablo: полученная ошибка указывает на то, что файл был переименован по-разному. Одна последняя часть, в каком состоянии вы хотите оказаться? Это один файл (скажем, снова foo.c) с изменениями, внесенными в обе ветви, объединенными?
 pablo13 янв. 2011 г., 20:15
Хорошо, но то, что я ожидал сделать, было: быть в состоянии проверить, что переименования расходились, и затем быть в состоянии объединить их вместе под одним именем ...
 Cascabel13 янв. 2011 г., 18:57
Также, вероятно, полезно:git checkout [--ours|--theirs] <path>.
 pablo13 янв. 2011 г., 22:11
@Mark: нет, в конце я вижу: два файла, а не объединенные ... :( Спасибо.

Ваш ответ на вопрос