I usually rebase
when I pull in changes from my teammates, and often time I have conflicts:
...
CONFLICT (content): Merge conflict in app/views/sear
When this happened to me, I managed to solve it after realizing I had edited (and added to the index) during the rebase a file which does not have a conflict, I guessed this might be wrong.
So I used git checkout -- <filename-with-no-conflict>
, and then git rebase --continue
, and it worked.
So after opening each file with a conflict, fixing it then committing the fixed files...
The problem is that you aren't supposed to commit
the fixes. If a.txt
has a merge conflict, then your shell log should look like:
$ vim a.txt # fix conflict
$ git add a.txt
$ # no commit between add and rebase!
$ git rebase --continue
Calling git rebase --continue
will take care of the commit itself.
I'm not sure how to "get back" to before your commit, when you're in the middle of a rebase. git reset --hard HEAD
would probably do the trick, but personally I'd feel safer just going straight to git rebase --abort
and starting over without committing in the middle.
With Git 2.14 (Q3 2017), this kind of advice given in a rhetorical question that does not require an answer (like "did you forget to use 'git add'?
") will be no more.
See commit 6963893, commit 9932242, commit 6c48686 (11 May 2017) by Jean-Noel Avila (jnavila).
(Merged by Junio C Hamano -- gitster -- in commit e638108, 29 May 2017)
usability: don't ask questions if no reply is required
When the spelling of a command contains errors, the git program tries to help the user by providing candidates which are close to the unexisting command. E.g Git prints the following:
git: 'stahs' is not a git command. See 'git --help'.
Did you mean this?
stash
and then exits.
The problem with this hint is that it is not formally indicated as an hint and the user is in fact encouraged to reply to the question, whereas the Git command is already finished.
The user was unlucky enough that it was the command he was looking for, and replied "yes" on the command line, effectively launching the
yes
program.The initial error is that the Git programs, when launched in command-line mode (without interaction) must not ask questions, because these questions would normally require a user input as a reply that they won't handle indeed. That's a source of confusion on UX level.
To improve the general usability of the Git suite, the following rule was applied:
if the sentence
- appears in a non-interactive session
- is printed last before exit
- is a question addressing the user ("you")
the sentence is turned into affirmative and proposes the option.
In your case, "did you forget to use 'git add'?
" is now replaced with:
You should '
git add
' each file with resolved conflicts to mark them as such.
You might rungit rm
on a file to accept "deleted by them" for it.
Much clearer.
I agree with Mark Rushakoff that fixing commits should not include committing them.
There is at least one other way that git will continue to say that "You must edit all merge conflicts and then mark them as resolved using git add" even after you have done just this. This may occur if you remove files from git version control, but leave the unversioned file sitting in your working tree and then try to perform a rebase.
I was able to fix this problem as follows:
git rebase --abort
git status
tmp
directorygit svn rebase
Hope that helps.
I found myself in the same boat and git rebase --continue
didn't help. Running rm -fr .git/rebase-apply
fixed the issue though