Given the following test-setup: git init resolving-rename-conflicts cd resolving-rename-conflicts echo “this file we will rename” > will-be-renamed.txt git add -A git commit -m “initial commit” git checkout -b branch1 git rename will-be-renamed.txt new-name-1.txt git commit -a -m “renamed a file on branch1” git checkout -b branch2 master git rename will-be-renamed.txt new-name-2.txt git commit -a -m … Read more
Per the docs, I just tried this simple command and it worked for me: git commit –no-edit Afterward, run git log to confirm that the default message has been used.
You might be best off looking for a description of a 3-way merge algorithm. A high-level description would go something like this: Find a suitable merge base B – a version of the file that is an ancestor of both of the new versions (X and Y), and usually the most recent such base (although … Read more
Try git mergetool.
You can use :lopen to open window containing error/warning lines. After that, navigate to each of them. The actual answer is that you can use :lnext to jump to the next error, or :lprev, or ]l and [l (those are lowercase Ls) if you have vim-unimpaired, which you do, because you shouldn’t use Vim without … Read more
This happened to me and git reset –hard HEAD from the accepted answer didn’t help. However, running spring stop did the trick. I suspect spring is rewriting the file whenever it is modified to ensure that it is in sync with the code running via spring.
You mean conflict markers such as <<<<<<<, =======, and >>>>>>> on merges to indicate that the automatic resolution failed?! You can use my ConflictMotions plugin for that; it provides ]x and [x mappings, ]= for navigation within a conflict, and even corresponding text objects ax and a=.
A stash is a commit (or really, two or even sometimes three commits) and you cannot change a commit. The literal answer to your question, then, is “you can’t”. Fortunately, you don’t need to. You say you can’t apply your stash because of a conflicting file. But you can apply it, you just get a … Read more
Before you dig deep into your workflow, before you spend a moment of time or a dollar of money rebuilding your communication processes, ask your team three questions: Do we enforce whitespace conventions? If we use IDEs, do they all use the same formatting and keyword settings? For example, Eclipse can automatically finalize parameters. Do … Read more
Everything between <<<<<< and ====== comes from the HEAD revision, which is the committed state before starting the merge operation (git merge will complain if the tree is dirty, so it should be equivalent to your working directory). The parts between ====== and >>>>>> come from the version being merged. The text after the >>>>>> … Read more