CODEWITHSUNDEEP
git
Jamie Marshall
Jamie Marshall

Reputation: 2304

remove git head from files <<<<<<head

I have a bit of unique situation. A folder containing a large library has been committed into our repo with get headers still in it (ex: <<<<<<<Head). However these are not recognized by git, nor are they listed as conflicts. As far as git is concerned all is well. However, the presence of these headers makes the library impossible to run. I know everyone's first impulse is to say, "this can't happen, that's the whole point of git." Well it has happened, and it seems like I need to manually clear these headers out of this library.

Here is git status after git reset --hard and git commit

On branch master
Your branch is ahead of 'origin/master' by 2 commits.
  (use "git push" to publish your local commits)

nothing to commit, working tree clean

here's trying to run a file in the library:

pip freeze
Traceback (most recent call last):
  File "C:\Users\jmarshall\AppData\Local\Programs\Python\Python37\lib\runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "C:\Users\jmarshall\AppData\Local\Programs\Python\Python37\lib\runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "C:\Users\jmarshall\source\repos\MediaDesignGroup\ETLApp_Dev\ETLApp\ETLAppEnv_3_7\Scripts\pip.exe\__main__.py", line 5, in <module>   
  File "c:\users\jmarshall\source\repos\mediadesigngroup\etlapp_dev\etlapp\etlappenv_3_7\lib\site-packages\pip\_internal\cli\main.py", line 60
    <<<<<<< HEAD
    ^
IndentationError: expected an indented block

Upvotes: 1

Views: 1821

Answers (2)

Lukas
Lukas

Reputation: 1

I once faced the same problem, and it seems that git does recognize it as a problem. But here there is a simple solution.

  • first copy all data in the file excluding the line causing conflict
  • Then try deleting the file that has the issue and recreates the file again

$ git rm file_with_issues

Upvotes: 0

matt
matt

Reputation: 535305

I have a bit of unique situation

It’s not particularly unique actually.

I know everyone's first impulse is to say, "this can't happen, that's the whole point of git."

No, it's very easy to make this happen. I'll demonstrate!

I'll start a repo:

$ echo a > a.txt
$ git add .
$ git commit -ma
$ git branch b
$ echo c > a.txt
$ git add .
$ git commit -mc

Now I'll create a conflict and merge it:

$ git switch b
$ echo b > a.txt
$ git add .
$ git commit -mb
$ git switch master
$ git merge b

Now Git reports the conflict:

Auto-merging a.txt
CONFLICT (content): Merge conflict in a.txt
Automatic merge failed; fix conflicts and then commit the result.

Okay, ready? I'll make the problem happen. Here we go:

$ git add a.txt
$ git commit -moops

That's all it takes! Do you see what I did? I didn't fix the conflict markup in a.txt, but I told Git that I had fixed it, and I committed. Now this version of a.txt has been commited!

<<<<<<< HEAD
c
=======
b
>>>>>>> b

So you see it's actually quite trivial to make this mistake. Git has no idea what's in the merge conflict file; fixing it and saying so, honestly, is the responsibility of humans.

Now, in the simple example I just gave, fixing the issue at this point is easy; the file still has the original merge conflict markers, so do what you should have done before: edit the file to fix the conflict (pick c or b, or whatever), removing the markers, and add, and commit!

But whether the OP's situation will admit of such a simple solution is doubtful at this point.

Upvotes: 3

Related Questions