![]() What isn't clear to me is if this is even an issue with BC itself, or if it's a Windows 10 issue, or possibly an issue in Git for Windows itself. I think modern versions of Git will work just fine the way I have it. I used to use those settings and I still observed this behavior. You guys should seriously consider updating it. Regarding your recommended setup, it is quite old and hasn't been updated for many years. I'm sorry that I don't have anything else to help get you to reproduce this. I suspected deletions were causing it, but I actually see it happen regardless of that at times. In my case, the issue doesn't happen 100% of the time. Make sure you're testing during a rebase, and ensure that rebase contains 10+ conflicts. OS is Windows 10 圆4 (latest updates as of today) ![]() Git for Windows version is: 2.37.0.windows.1 You can ignore the `merge.supressDest` option, I accidentally provided more information than was relevant to my question.īeyond compare version is: 4.4.2 (build 26348) I took a screenshot of Process Explorer showing that `bcomp` is indeed used: Git does seem to be updating and while it has added 'bc4' as a keyword it recognizes to auto-handle a lot of the configuration, I didn't know it also detected our default install path. It's not part of our recommended setup, which also includes the path to the install (which is missing from here). I'm also not sure what suppressDest = true would do. Also, I should probably mention I'm testing on Windows 11, which might impact things, but I'd expect similar behavior on Win10. Are you using the latest Git for Windows from and BC4.4.2? I've seen a wide variety of behavior depending on the version and flavor of Git. Which version of Git are you using, and are you launching from Git for Windows' Git Bash? I've set up a similar merge scenario which alternates between prompting for the mergetool and for the bash's internal prompt of '(m)odified or (d)eleted file, or (a)bort?', which passed focus correctly between windows on my test system. Is there anything I can do to prevent the BC4 window from being sent to the background when it is launched during `git mergetool`? I was looking for a "Always On Top" option for BC4 but I am not seeing it. After resolving this, all diff-based conflicts (which result in BC4 being launched) now cause the window to appear in the background with a blinking button in the windows task bar. I modify a file on my branch that is deleted on `master`), I am prompted to keep the modified file or remove the deleted file. However, if my rebase involves resolving a deleted file conflict (e.g. So I never have to put my hand on my mouse to resolve multiple conflicts in turn. In a scenario where the *only* conflicts are differences (not one file deleted or added), BC4 appears in the foreground and immediately has keyboard input. Path = C:\\Program Files (x86)\\Beyond Compare 4\\BComp.exeĪlso tried changing the exe to BCompare.exe instead of BComp.exe but that didn't work either.Trustexitcode = trueWhen I do a `git rebase` to update a topic branch I'm working on and there are conflicts, I run `git mergetool` to interactively visit each conflict, which pops open BC4 4-way compare to resolve the conflicts. =C:\Program Files (x86)\Beyond Compare 4\BComp.exeĬore.editor="C:/Program Files (x86)/GitExtensions/GitExtensions.exe" fileeditorĬredential.helper=!\"C:/Program Files gitcoinfig in GIT install / etc directory All rights reserved.ĭ=C:\Program Files (x86)\Beyond Compare 4\BComp.exe NO matter how I seem to configure this it wants to use the VS2013 internal diff/merge tools.īeyond Compare Install Directory C:\Program Files (x86)\Beyond Compare 4įrom git bash window Microsoft Windows Ĭopyright (c) 2009 Microsoft Corporation. I'm trying to figure out how to configure BEYOND COMPARE 4 to use with Visual Studio 2013 with GIT.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |