4

I had a highly problematic git merging and my repo has now a little bit of trouble.

Actually, I have a lot of files seeming so:

<<<<<<< HEAD
...version1...
=======
...version2...
>>>>>>> <long hexa code>

As we know, this is the normal behaviour in the case of merge conflicts. But I don't have the other file versions, only these.

How could I merge this interactively? What I would need, is to see "version1" and "version2" next to each other and be able to merge them interactively.

Of course, these file format means a syntax error with every software.

git merge and all of the merge tools are saying, that there is no merge conflict. But, there is.

What should I do?

Extension #1: I split the files with a little bit of shellscripting, with the command

for i in $(cat ../conflicts); do csplit $i '/=======/' -f $i. -n 1;done

Now I have the parts of these files in path.0 and in path.1. Now I would need an interactive solution to merge them.

pho
  • 41
  • 3
  • I'm curious how you got into that state. It seems like perhaps someone committed unresolved conflicts. You should hunt them down :-). Or, find the commit committed the conflicts unresolved, and revert it, and re-merge. – Daniel Jul 06 '15 at 16:32
  • Somebody started a merge while my changes in my working copy weren't committed. :-( – pho Jul 06 '15 at 16:34
  • The only person who should be able to do that is you. `git pull` or `git merge` should only be run if your working copy is clean. – Daniel Jul 06 '15 at 16:40
  • @Daniel Sometimes there are good-standing collegues thinking I can't do my job and want to help. And sometimes this leads to data loss. Now I need my hardcore shellscripting and gitting skills to fix their help. – pho Jul 06 '15 at 16:54

2 Answers2

1

If git is saying that there's no merge conflict, then either these files have been added as is or they've been committed.

If they've been added as is, then you should run git reset HEAD which will reset the state of the index. You should then see all of the files that you have committed as being new again, in which case you can address them individually.

If they've actually been committed, then you'll need to undo the merge node and then do the merge node again. You can use git reset --hard HEAD^ to reset to the last known point (and throw the commit away) and re-doing the merge again. Note that this option will lose your data; you're effectively re-doing the merge again.

AlBlue
  • 23,254
  • 14
  • 71
  • 91
  • Then I will lose the changes which were only in my working copy. – pho Jul 06 '15 at 16:35
  • Note that `git reset HEAD` doesn't lose changes. But if you've already committed the merge commit with the code, you have to fix/amend it anyway. – AlBlue Jul 06 '15 at 16:37
  • After the problem were clear to me, I made a `git add .; git commit` on the spot. So, I now have an old, error-free version of my files, and a new, in the state which I described in my question. – pho Jul 06 '15 at 16:40
  • So by doing the git commit you told Git there wasn't any errors and to ignore the fact there were conflicts. You'll need to re-do the merge again as I've suggested if you want to resolve them automatically, or you'll need to manually fix each of the conflicted files. – AlBlue Jul 06 '15 at 16:45
  • Exactly this manual fix is for what I am looking for an automatized or interactive solution. – pho Jul 06 '15 at 17:02
1

You can try the git mergetool command, if you want to resolve conflicts in a graphic environment. Of course, you will need to have one of the valid tools installed. Here's an excerpt of the doc; note the valid values listed:

git mergetool [--tool=<tool>] [-y | --[no-]prompt] [<file>...]

   -t <tool>, --tool=<tool>
       Use the merge resolution program specified by <tool>. Valid values include emerge, gvimdiff,
       kdiff3, meld, vimdiff, and tortoisemerge. Run git mergetool --tool-help for the list of
       valid <tool> settings.
logc
  • 3,813
  • 1
  • 18
  • 29
  • 1
    The problem is there isn't a merge any more - the files have been committed, so Git doesn't think there's any further work to be done. – AlBlue Jul 06 '15 at 16:45
  • All of the tools say that there is no merge conflict. – pho Jul 06 '15 at 16:51