It’s fairly fast-forward and intuitive, helps alot when there’s loads of small conflicts.It is almost 2 months, i was facing this error, with my Linux box. Next time, try using a tool for resolving the conflicts, for example git mergetool -t kdiff3. git is pretty solid and should never destroy data (unless you inadvertently ask it to, of course). If the stuff between the conflict markers was truly garbage, it’s possible your IDE screwed up and corrupted the files.
E138 CAN T WRITE VIMINFO FILE HOW TO
(git will tell you how to finish the merge when it tells you there’s a conflict.) When this happens, git has almost certainly injected conflict markers into those files, and you need to resolve the problem and finish the merge. Git will tell you if there are conflicts after a merge, and git status (which you should run religiously) will always show conflicting files in scary red. Git log -graph -oneline -decorate is a pretty useful view that should (Plus, you’d have no way of resolving conflicts.) You can’t do this work on the remote because it involves changing your files to create merged versions, and the remote machine doesn’t actually have physical copies of your files. You can’t push like this, because your local branch doesn’t know anything about D and E or how they relate to history you only have A-B-C-F-G.īut if you merge first to create H, you now have a branch with all the commits from both you and github on it, and github can be updated merely by “moving” its arrow upwards.
This is what commit history might look like if you did work up to C, then someone else (or you on another computer) added D and E and pushed them, and then you started working from C again and did F and G. So, here is a crash course with one of those commit graph diagrams you will learn to hate: H G E <- github But if you’ve been pulling shenanigans like rebase or force-pushing without understanding what you’re doing, you might have created the delightfully absurd situation of merging a branch into itself. It’s only you, so the remote shouldn’t have different commits. You can only push if it would result in only adding new commits on top of what the remote already has. You always have to merge (or do something) if you’ve made some commits and the remote has different commits. Perhaps that is related as well? Like I said, the problem seems to be behind me for now, just wondering what went wrong and how to avoid it in the future. So I kept having to abort that command, then go in and manually delete the index.lock file, as well as a COMMIT_EDITMSG.swp file.Īlso, this last time (when the nonsense was inserted), I got an error message that said E138: can't write viminfo file u:_viminfo!
E138 CAN T WRITE VIMINFO FILE WINDOWS
How can I avoid this happening in the future? I was using the git bash console on Windows XP.Īlso – since this might be related – when I tried committing files earlier via my PHPStorm CLI interface, I would hit “commit” and the commit would never complete. Fortunately, there weren’t too many new files and I was able to go through, clean them out fairly easily, then re- add / commit / push, and now I believe the problem is behind me.īut what was going on? I’m still pretty new to git and github. Those sorts of lines were inserted sort of randomly but perhaps not entirely randomly throughout the newly added files. For some reason, after merging, pulling and pushing my changes to github, I noticed that all the new files had text inserted into them like this: > I added some new files to a git repository that I hadn’t touched in a couple months.
0 kommentar(er)
