I've been using VSCodeVim for a few weeks now and it's pretty great but I find that there are a few actions that I cannot perform without using the mouse. One of them is using the source control tab on the sidebar to stage/discard changes and commit.
I am able to use j and k to move up and down, h and l to collapse/expand as well as view the working tree/diff view for the selected file, but I haven't found how I can stage or discard the selected file.
Are there ways that I could remap keys to perform these actions? Ideally I would also be able to commit, unstage files, stage all, unstage all, etc. I found these actions as git.{action} in the key bindings, but this doesn't seem to work.
Related
I use VS CODE for version control (using git).
Every time I had a conflict, VS CODE showed me with a layout where I could see all the changes in one window:
However, with no advice, it change to a weird 3 windowed design where I can't understand anything.
Does someone know how can I go back to the first design?
Go to VS Code settings
Untick the Git: Merge Editor setting
Now you should be able to see the previous merge layout.
This feature (3 way merge editor) can be enabled by setting git.mergeEditor to true and will be enabled by default in future releases.
You can set it back to false to go back to the previous design as you want.
This new 3-way merge editor seems to have a terrible UX issue. For me simply switching to merge editor to 'false' doesn't work as below:
git.mergeEditor = false
After this editor completely stopped showing me any merge conflict line.
I have to finally do like this to revert back to original merge conflict view.
"diffEditor.codeLens": true,
"git.mergeEditor": false
Hit ctrl+shift+p to open command pallet and open the settings json by typing Preferences: Open User Settings (JSON) (or start typing 'settings' and this will come up)
In the main JSON object add "git.mergeEditor": false (insert comma beforehand if needed)
Hit ctrl+shift+p and type Developer: Reload Window to reload the windo.
The old type of merge editor should be back.. but you may need to wait a minute to get the full UI back (on my machine, the accept incoming buttons etc. didn't come back for a little).
Update 2023 in case the conflict UI has crashed/not displayed
When you rebase a file with embedded conflicts within conflicts VScode's in- file-conflict-display(blue/green UI) might glitch due to too-many git markers present, rendering merge impossible without CLI.
Apply workaround by enabling and switching to 3 way conflicts window.
enable merge editor (by searching the settings or modifying vscode config file locally)
use vscode's merge display by going to Source Control tab then clic the file with ! exclamation mark before the name of the file
solve the maximum number of conflict using the new 3 windows conflict UI (remember current and incoming are inverted in case of rebasing)
go back to normal file UI and the classic in-file-conflict-UI (green/blue) should be back online
finally git add . && git rebase --continue && :wq (vim) in case of rebase to pass to the next commit to handle.
Rule of Thumb: Remember to always create a temporary local branch of your feature before merging/rebasing your feature branch before PR. This will be used as backup to keep the design intent in mind. Then always run code(and lint) to check for obvious typos/merge artifacts (ie these git flags or unclosed loops/functions).
Update 1.31 added keyboard navigation to tree widgets, where it will now filter items in the file explorer tree based on a search result.
Previously, when the file explorer was focused, I was able to use A or shift+A to create a new file or folder in my current directory. I am now unable to do this, as any keystrokes enter a filtering mode in the tree, rather than performing the keyboard shortcut.
The developers have added a setting to control this: workbench.list.keyboardNavigation, however none of the options appear to revert it to the old behaviour.
Changing this option simple, rather than the new default highlight, allows the keyboard shortcuts to work as they did previously, however the new file/folder I create are now created in what feels like an arbitrary location in the file tree, rather than the current directory which was the previous behaviour.
If anyone could shed some light on how to revert back to the previous functionality, or if I am misunderstanding how the simple behaviour works, that would be great.
For anyone stumbling across this question, this has been solved as of the 1.32 update. With the tree focused, press / to toggle between filtering mode and operation mode.
I have one folder that contains multiple sub folders, and each of them is one git repository. Sometimes I can see this SOURCE CONTROL PROVIDERS view showing up and it's super helpful, but sometimes it doesn't show up. I would like to know if there is a switch on the vscode UI to turn on or off this view. (Maybe it's a plug in that I accidentally installed?)
Thank you!
Version 1.31.1 has a config parameter to always show the source control providers:
Type Ctrl+, to access settings
Search for SCM
Check the "Scm: Always Show Providers" option
You are using 1.17 released today (at least for me). For info about that panel see source control providers. I don't see a toggle for that panel - I assume you always get it if you have multiple SC Providers and open up the source control icon CTRL-Shift-G.
but sometimes it doesn't show up
Starting with 1.47 (June 2020), it does not show up at all, as it used to.
There is a new "single-unified view":
(the old view might come back in 1.49, Sept. 2020, see at the end)
The Source Control view has been consolidated into a single view:
All repositories are rendered in a single view, so you can get a better overview of the entire workspace status.
Additionally, the Source Control view can now be moved to the panel and other views can be moved to the Source Control view container
This... has not been appreciated. See issue 102118:
In the old system, if I had 4-5 repos showing, the one or two with active changes would show up clearly at the bottom.
Now it's very muddled, and sort by status simply puts the repos with changes at the top.
Here is the old view. List of changed files only show up when a repo is clicked. They are clear and distinct, separated from all the list of repos and everything else at the bottom.
The new single source view. One has to hunt for the changes amidst a list of other repos. It is cluttered, hard to parse, and requires hunting to find what you want. The old view was much easier to follow and use.
issue 104151 proposes to bring back the old view
Example:
The Source Control Repositories view is now back.
(It used to be called Source Control Providers).
It lets you control visibility of multiple repos in the Source Control view.
The setting scm.repositories.visible is now back
(It used to be called scm.providers.visible).
I've sprinkled visibility actions both in the context menu of the Source Control view as well as the ... menu, to make it easier to control the visibility without using the Source Control Repositories view.
I'm now in a process of transition from Netbeans to Eclipse (Indigo).
Ctr+Q seems to have the same function - going back to the last edit location. But in Netbeans I was able to press Ctr+Q repeatedly and go further back without the need of altering the file content (undo and redo hack).
Is there such functionality in Eclipse?
Some info:
I'm using the JavaScript Development Toolkit, PDT, and YAML editor.
It seems that Back action (Alt+Left) is more or less the same. The difference is that it tracks any action, not only edits. Actions as "Go to declarations" are also included in the history of Alt+Left.
I think, in a way, it's more useful because I track back my real actions as in "real browsing" the code. Though I will switch the keyboard shortcuts for Last Edit and Previous Action so that I keep the Ctr+Q habit.
It is currently not possible in Eclipse. There is an old feature request for this functionality with Bugzilla id 72773 (https://bugs.eclipse.org/bugs/show_bug.cgi?id=72773).
9 years later, check out Eclipse 4.17 (2020_09)
Multiple Last Edit Locations
Previous Edit Location navigation (formerly named Last Edit Location) is now expanded to remember multiple edit locations.
The last 15 edit locations are now remembered.
For convenience, similar edit locations in close proximity to each other are also merged so that each of the 15 remembered locations remains distinct.
How to use
Two new keyboard shortcuts are introduced:
Ctrl+Alt+LEFT_ARROW (or on Mac Ctrl+Opt+LEFT_ARROW) navigates to the most recent edit location, just as Ctrl+Q always has in prior releases.
However, now continuing to hold Ctrl+Alt and then pressing LEFT_ARROW again begins a traversal through the history of prior edit locations, with each additional press of LEFT_ARROW moving a step further back in history.
Once traversal stops, future Ctrl+Alt+LEFT_ARROW actions are now temporarily anchored to this older historical location for easy exploration of that code region.
The classic Ctrl+Q mapping has been likewise enhanced with this new functionality, so that Ctrl+Q and Ctrl+Alt+LEFT_ARROW are synonymous.
Ctrl+Alt+RIGHT_ARROW (or on Mac Ctrl+Opt+RIGHT_ARROW) conversely moves the anchor forward through edit history, so after traversing backward with Ctrl+Alt+LEFT_ARROW, you can go forward again by holding Ctrl+Alt and repeatedly pressing RIGHT_ARROW.
A new menu item has likewise been added for this forward navigation as well.
New edit locations are always inserted at the end, so original historical ordering is always maintained.
New edits also reset the last location "anchor" back to the most recent edit, so that pressing Ctrl+Alt+LEFT_ARROW once again brings you to the most recent edit rather than a historical one.
You can use the local history if you lost your undo redo functions.
to do that: 1/ right click anywhere on your code, 2/ Team, 3/ Show Local History, then choose the version you want according to edit time.
Okay, I have another newbie question. I'm starting to work with a remote code repository, remotehosting.com, and have been given a username, password, and URL. I've been able to successfully associate my project with a remote source code repository, have checked out/pulled down the source files, and have now made a small change to a single file. Here's where my questions start.
1) I can't see anywhere in my GUI where Xcode realizes that I have made a change to a file
2) How do I check my files back in?
I gotta be missing something. The docs I've been reading point to more menu items that I currently see under my SCM menu item. Anybody have any ideas? Thanks in advance for your assistance!!!
File -> Source Control -> Commit, Select the files that you want to commit, add a comment and hit commit button.
This is the flow for xcode 4
In Xcode 3...
The Project window should have a column which displays the SCM status for your files. This can appear both in the "Groups & Files" outline view in the left pane and the file list in the right pane. The icon for the column is a little cylinder shape, a black-and-white version of the yellow cylinder that's shown when you manage repositories. If this column is not displayed, you can right-click on the header of either of those panes to bring up a menu with a list of columns. Select "SCM" from that. The status will display as the same one-letter codes that SVN uses on the command line.
In order to commit files, you can either a) select the particular files, or group you want to commit and use the menu command SCM>Commit Changes..., or b) Select SCM>Commit Entire Project... (which I personally have bound to ⌥-⌘-C in the Xcode key bindings preferences).
Either of these will display a sheet in which you can enter your commit message; the text field in this is very handy in that it accepts the Return key as a newline, rather than passing it to the "Commit" button, but could be confusing the first few times. Press ⌘-Return to activate the button and perform the commit.