Search Results

Search found 11 results on 1 pages for 'mergetool'.

Page 1/1 | 1 

• Can I rename LOCAL, REMOTE and BASE as used in git mergetool?

  - by carleeto

  Lets say I'm doing a rebase B of a branch onto master and there's a conflict. git opens up the default merge tool with 3 files as input : file.LOCAL, file.BASE, file.REMOTE (they're named a little differently, but LOCAL, BASE and REMOTE are in the file names and is how they are distinguished). Now, according to the mergetool man page: $LOCAL is set to the name of a temporary file containing the contents of the file on the current branch; $REMOTE set to the name of a temporary file containing the contents of the file to be merged, and $BASE set to the name of a temporary file containing the common base for the merge. That really does not make sense to me. LOCAL is the current state of the branch. Where I get lost is BASE and REMOTE. So my question is : Is it possible to make git use the branch name instead of LOCAL and similarly more meaningful names other than BASE and REMOTE? For example, if the branch name is FeatureX and the BASE = the file as it exists in master, is there a way to get git to substitute FeatureX for LOCAL and master for BASE, so that it is more apparent where the source is coming from? This is especially a problem when doing a rebase.

  Read the article

• Vimdiff with git mergetool error: "More than two buffers in diff mode"

  - by Elizabeth Buckwalter

  I've read Vimdiff and Viewing differences with Vimdiff plus doing various google searches using things like "vimdiff multiple", "vimdiff git", "vimdiff commands" etc. When using do or diffg I get the error "More than two buffers in diff mode, don't know which one to use". When using diffg v:fname_in I get "No matching buffer for v:fname_in". From the vimdiff documentation: :[range]diffg[et] [bufspec] Modify the current buffer to undo difference with another buffer. If [bufspec] is given, that buffer is used. If [bufspec] refers to the current buffer then nothing happens. Otherwise this only works if there is one other buffer in diff mode. and more: When 'diffexpr' is not empty, Vim evaluates to obtain a diff file in the format mentioned. These variables are set to the file names used: v:fname_in original file v:fname_new new version of the same file v:fname_out resulting diff file So, I need to get the name of bufspec, but the default variables (fname_in, fname_new, and fname_out) aren't set. I ran the command git mergetool on a linux box through a terminal.

  Read the article

• Merge changes when a file on a branch has split into two files on the master

  - by carleeto

  This is basically the result of a massive class C on the master having been refactored down the line into two smaller classes, C1 and C2. C was then made a subclass of C2 and cut down to a skeletal version for backward compatibility. So from that point on, master contained C, C1 and C2. On that master commit git said C was renamed to C1. The branch was last updated before this happened. (All C++ code, if it helps to visualize the files involved) Obviously, when I tried a rebase of the branch onto master, there were conflicts that needed to be resolved. As usual, I used mergetool. So now the mergetool comes up with the following: On Local, I have the skeletal version of C. Base and Remote have a bunch of changes to C. Because the skeletal version of C exists on Local, I conclude that the changes from Base and Remote should actually go into C1, leaving C alone. My question is, how do I do this?

  Read the article

• Is there a way to make Git mark a file as conflicted?

  - by Christian Jonassen

  It's possible to commit files that contains conflict data. Is there a way to mark these files as conflicted again, so that running git mergetool will generate the necessary files and run the merge tool?

  Read the article

• Git on Windows: How do you set up a mergetool?

  - by Jake

  I've tried msysGit and Git on Cygwin. Both work just fine in and of themselves and both run gitk and git-gui perfectly. Now how the heck do I configure a mergetool? (Vimdiff works on Cygwin, but preferrably I would like something a little more user-friendly for some of our more... Windows-loving coworkers.) Thanks!

  Read the article

• Wise settings for Git

  - by Marko Apfel

  These settings reflecting my Git-environment. It a result of reading and trying several ideas of input from others. Must-Haves Aliases [alias] ci = commit st = status co = checkout oneline = log --pretty=oneline br = branch la = log --pretty=\"format:%ad %h (%an): %s\" --date=short df = diff dc = diff --cached lg = log -p lol = log --graph --decorate --pretty=oneline --abbrev-commit lola = log --graph --decorate --pretty=oneline --abbrev-commit --all ls = ls-files ign = ls-files -o -i --exclude-standard Colors [color] ui = auto [color "branch"] current = yellow reverse local = yellow remote = green [color "diff"] meta = yellow bold frag = magenta bold old = red bold new = green bold whitespace = red reverse [color "status"] added = green changed = red untracked = cyan Core [core] autocrlf = true excludesfile = c:/Users/<user>/.gitignore editor = 'C:/Program Files (x86)/Notepad++/notepad++.exe' -multiInst -notabbar -nosession –noPlugin Nice to have Merge and Diff [merge] tool = kdiff3 [mergetool "kdiff3"] path = c:/Program Files (x86)/KDiff3/kdiff3.exe [mergetool "p4merge"] path = c:/Program Files (x86)/Perforce Merge/p4merge.exe cmd = p4merge \"$BASE\" \"$LOCAL\" \"$REMOTE\" \"$MERGED\" keepTemporaries = false trustExitCode = false keepBackup = false [diff] guitool = kdiff3 [difftool "kdiff3"] path = c:/Program Files (x86)/KDiff3/kdiff3.exe [difftool "p4merge"] path = C:/Users/<user>/My Applications/Perforce Merge/p4merge.exe cmd = \"p4merge.exe $LOCAL $REMOTE\" .

  Read the article

• Recovering 'old commits' from multiple git rebases

  - by Benjol

  I am aware of this question, but not to sure how to map it to my current situation. (Rebase is scary, undoing rebase is double scary!) I started out with several different feature branches of my master: master x-x-x-x-x-x-x-x-x-x \ \ \ FeatureA 1-2-3 \ \ FeatureB A-B \ FeatureC X-Y-Z I wanted to merge them all together and check they worked before merging back onto the top of master, so I did a: git checkout FeatureB git rebase FeatureA git mergetool //etc git rebase --continue Then git checkout FeatureC git rebase FeatureB git mergetool //hack hack git rebase --continue Which leaves me with master x-x-x-x-x-x-x-x-x-x \ FeatureA 1-2-3 \ FeatureB A'-B' \ FeatureC X'-Y'-Z' Then I corrected some bits that didn't compile properly, and got the whole feature set to an acceptable state: master x-x-x-x-x-x-x-x-x-x \ FeatureA 1-2-3 \ FeatureB A'-B' \ FeatureC X'-Y'-Z'-W My problem is that my colleagues tell me that we're not ready for FeatureA. Is there any way for me to keep all my work, but also revert to a situation where I can just rebase FeatureC on to Feature B?

  Read the article

• How to prevent an automerge using git?

  - by marckassay

  I am trying to merge a local branch into the master branch without having Git to do an automerge. I would like to “hand pick” what I would like to be merged into master. When I use Git’s difftool command, I am able to diff and select what I want to be added into the master branch. But then when I do a merge, I will lose what I selected prior because Git will do an automerge. I can commit the changes into master prior to the merge, but doing so seems unnatural. And Git’s mergetool is only available when there are conflicts from a merge. But if Git does an automerge then usually there aren’t conflicts, so I am unable to run the mergetool command.

  Read the article

• How Do You Get the bufspec While Using Vimdiff Through Git

  - by Elizabeth Buckwalter

  I've read Vimdiff and Viewing differences with Vimdiff plus doing various google searches using things like "vimdiff multiple", "vimdiff git", "vimdiff commands" etc. When using do or diffg I get the error "More than two buffers in diff mode, don't know which one to use". When using diffg v:fname_in I get "No matching buffer for v:fname_in". From the vimdiff documentation: :[range]diffg[et] [bufspec] Modify the current buffer to undo difference with another buffer. If [bufspec] is given, that buffer is used. If [bufspec] refers to the current buffer then nothing happens. Otherwise this only works if there is one other buffer in diff mode. and more: When 'diffexpr' is not empty, Vim evaluates to obtain a diff file in the format mentioned. These variables are set to the file names used: v:fname_in original file v:fname_new new version of the same file v:fname_out resulting diff file So, I need to get the name of bufspec, but the default variables (fname_in, fname_new, and fname_out) aren't set. I ran the command git mergetool on a linux box through a terminal. [Edit] A partial solution that bred more questions. I used the "filename" at the bottom of the buffer. It's only a half answer, because occasionally I get a file does not exist error. I believe it's consistently the remote version of the file that "does not exist". I suspect this has something to do with git and indexing. How do you get the bufspec value consistently while using vimdiff through git-mergetool?

  Read the article

• How do I accept all changes from a remote?

  - by e-satis

  I'm doing a pull origin some_branch and can see there are a lot of changes. Eventually I don't mind if their erase all mine. How can I accept them all instead or using mergetool and merge files one by one?

  Read the article

• How to use Winmerge with Git Extensions?

  - by sebastiaan

  I'm using Git Extensions and it pre-installs and sets up KDiff as the diff tool to solve merge conflicts. I'm very fond of Winmerge though and would like to replace KDiff with Winmerge. In the Git Extensions settings, there are settings to change the Mergetool, but I can't seem to figure out what syntax I should use and why. There seem to be 4 variables: $BASE, $LOCAL, $REMOTE, $MERGED. It seems that I should pass these to WinMergeU.exe, but with which command line parameters? I've tried to search for this a few times, but there is no answer that actually seems to work.

  Read the article

1