3

I did a git pull this afternoon. The merge failed with a thousand files conflicting. I couldn't find a command that worked after the merge conflicted to chose "theirs" strategy on all files and I didn't want to resolve each so I tried aborting the merge. git reset --merge, git merge --abort, and git checkout master didn't work. There was no merge head and the other failed. I tried git reset --hard HEAD and 8 hours later it's only at 50%. Why did this happen and how can I avoid this in the future? I have a RAID SSD and I could just clone the repo again in maybe 15 minutes. Possible solutions if anyone knows one of these:

  1. A command that resets fast.
  2. A command after a merge fails that choses "theirs" for all files like git checkout --theirs . (this command didn't work)

I was fairly thorough and didn't see the solution to a large merge conflict in any of the popular git questions.

Here are the errors: 

C:\Users\sticker592\source\repos\netDocs\docs-1>git reset --merge
error: Untracked working tree file '.gitattributes' would be overwritten by merge.
fatal: Could not reset index file to revision 'HEAD'.

C:\Users\sticker592\source\repos\netDocs\docs-1>git merge --abort
fatal: There is no merge to abort (MERGE_HEAD missing).
C:\Users\sticker592\source\repos\netDocs\docs-1>git merge --strategy-option theirs
Already up-to-date.

C:\Users\sticker592\source\repos\netDocs\docs-1>git merge master --strategy-option theirs
Already up-to-date.

C:\Users\sticker592\source\repos\netDocs\docs-1>git checkout --theirs
fatal: '--ours/--theirs' cannot be used with switching branches

C:\Users\sticker592\source\repos\netDocs\docs-1>git merge -X theirs master
Already up-to-date.
C:\Users\sticker592\source\repos\netDocs\docs-1>git status
On branch master
Your branch is up-to-date with 'origin/master'.

The merge was still in conflict according to VS team explorer and it required before I push or commit for me to resolve the conflicts.

user5389726598465
  • 1,418
  • 2
  • 14
  • 25
  • My first question is what on earth is in your Git repo that it takes this long? It can't be the network, because a hard reset happens locally. Do your other basic Git commands also take a really long time? – Tim Biegeleisen Apr 06 '18 at 04:06
  • @TimBiegeleisen The size is 500MB and there are 107903 files. Is that why or would the clone have to take this long if the number of files was cumbersome? – user5389726598465 Apr 06 '18 at 04:08
  • Well cloning 500MB will take however long it takes for this much data to go across your network. – Tim Biegeleisen Apr 06 '18 at 04:09
  • @TimBiegeleisen They are slow but not a work day slow, like 10 minutes slow. – user5389726598465 Apr 06 '18 at 04:15
  • Well a commit which affects a few files only and takes 10 minutes, I can see that scaling to hours for the entire repo. Maybe try to pare down the size of your Git repo. Do you have a lot of large binary files in there? – Tim Biegeleisen Apr 06 '18 at 04:16
  • @TimBiegeleisen No, just lots of files. I don't see why cloning would be faster. I don't understand why the merge failed in the first place. It should have just been a fast forward. – user5389726598465 Apr 06 '18 at 04:19
  • 1
    I gave you an upvote. Hopefully a Git expert will see this and be helpful than I have been. – Tim Biegeleisen Apr 06 '18 at 04:23
  • Yeah, something is very wrong with your system or your repo if that takes hours. Should be well under a second. – hobbs Apr 06 '18 at 04:34
  • @hobbs. Ok, I canceled and tried checkout -f and the same thing. I'm just starting over with a new clone I guess. Sure wish one of the popular git posts had a chose theirs strategy command for after a conflict without canceling and restarting the merge though. – user5389726598465 Apr 06 '18 at 04:35
  • Possible duplicate of [Abort a Git Merge](https://stackoverflow.com/questions/44048982/abort-a-git-merge) – Timothy Truckle Apr 06 '18 at 07:52

1 Answers1

1

The first test is to do a git clone in another folder, to get a fresh copy and check if that operation takes hours.

You can then integrate your changes from your current working tree into the new one.

But if the issue persists (and is not limited to you), then you would need to install GVFS (Git Virtual File System) in order to guarantee fast response time to any Git operation when dealing with large repos.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250