How to cleanly clipboard copy code from a GitHub.com diff? - github

Consider the following split view code diff from a browser on GitHub.com:
While looking at this diff, I want to clipboard copy the code from the right-hand side (e.g. in order to paste that snippet into a different project in another window).
However, if I try to use the mouse to select the code on the right-hand side in the usual fashion, the code from both sides ends up selected:
And if I hit Ctrl+C / Cmd+C, I end up with kind of a mess on my clipboard which includes copies of the code from both sides, and all of the + and - indicators, which leaves me with a lot of error-prone manual cleanup to do after I paste. (Particularly when copying from a diff that's more long and complex then the simple one I picked out for illustration purposes in this question!)
My question: How can I cleanly and easily copy code from one side of a split view diff in a web browser on GitHub.com to my clipboard?

Update March 2021: this should be, this time, supported:
Copy one side of split diff
When comparing changes to a file using the split view, you can now select and copy just one side of the diff.
Previously both sides were copied. Selecting over a comment will still copy the comment's contents.
May 2018:
As mentioned by Hugo Giraudel in his tweet in late April 2018, a bit too quickly:
GitHub finally moved the + and - symbols from diffs to CSS pseudo-elements, making it possible to copy code directly from a diff without having to clean it up.
That is long overdue and fantastic. ✨
Actually... this is only true with the help of third-party extension!
Like sindresorhus/refined-github.
Without, you would still copy the '+' and '-'.
GitLab has that feature though.
This is still pending for BitBucket (issue 16204)
timotheecour reports in the comments that it does not help with side-by-side diffs:
the code from both sides ends up selected
This is in the context of using refined-github, a Browser extension that simplifies the GitHub interface: issue 2765.
Update Nov. 2020: that issue just got resolved with PR 3698

Related

VS Code multi-line select past ends of lines

I've been transitioning to using VS Code for my python projects after previously working with the full Visual Studio, and some of the key bindings/features I'm used to in Visual Studio I can't find the equivalent for in VS Code. I'm not sure if the bindings are different or if the feature doesn't exist.
One feature in particular that I can't figure out is if it is possible to do multi-line select past line endings. In Visual Studio, using Alt + Click + Drag, lets you create a multi-line cursor or box selection, that can extend past line ends, implicitly adding spaces as needed so that the right-most side of the box stays uniform. In VS Code, if you drag the selection past the end of a line, the selection box won't go past the end of the line, even if other lines in the selection extend past it. In Visual Studio, this feature even goes further, as you could Alt + Click + Drag even in areas with no characters as all, creating a multiline cursor or box selection to the right of all existing line ends.
This isn't an essential feature, but it's very handy in making code easy to read. For example, when assigning several dictionary entries all at once, with varying key lengths. Is it possible to do something like this in VS Code?
Edit: The feature I'm looking for is virtual spaces (thank you Mark for providing the feature name), which seems to be an outstanding feature request in VS Code.
The short answer is no, vscode does not have a box select, past line ends, built-in. VS Code does not have the concept of virtual spaces which would be necessary to make this work yet.
Below is the issue, lots of comments, not that many upvotes. Upvote it.
https://github.com/microsoft/vscode/issues/5402

Handling [re]moved lines with Meld visual diff and merge tool

I have a question about the Meld visual diff and merge tool, which is probably a simple misunderstanding.
But how do I adopt lines that were removed in the $REMOTE?
Please see the screenshot below for an example. I have changed the order of the imports and created a merge conflict, so now I want to pull the first change from the right, but then also the second change that would remove those lines that now already exist at top of the imports. I could remove them manually of course, but surely there is an easier way?
Or am I wrong with my assumption, that the middle pane is the result that gets written to $MERGED?
Edit: In this contrived example, I actually have a Delete action that I can use to remove those lines. But in a real-world merge I'm trying to do with meld the Delete action is greyed out, as is the Pull from Right action.
Any idea why Meld wouldn't allow me to Delete those lines that will be made obsolete by a Pull from Right above them?
I found out that holding the Shift key allows me to remove individual changes.

How to undo / redo selective parts of code?

I am using Eclipse.
It happens a lot when we develop code like this (assume it is developed sequentially, from top to bottom):
Part 1 (*)
Part 2
Part 3
Part 4 (*)
Part 5
But we just figured out that parts 1 and 4 (marked with (*)) are wrong and the others are just fine. The question is that how we can undo just those two parts (1 and 4) without undoing the rest?
If we could undo selectively, it was great. Note that simply reverting the code to the version 1 loses parts 2, 3 and 5 which are correct parts and should remain in the code. Also note that usually these parts are mixed in one or two code blocks (not in separate blocks).
Example:
Part 1: Add method f1(x, y) and move some code from main() to f1() --> incorrect (should be reverted)
Part 2: Add method f2(a, b, c, d) --> correct (should remain)
Part 3: Change another part of main() implementation --> correct (should remain)
Part 4: Change f2 signature to f2(s, n) --> incorrect (should be reverted)
Part 5: Change body of f2 --> correct (should remain)
The current approach I use is:
Keeping a copy of the latest version somewhere (e.g., in a temporary
text file), then undo to before part 1, and add those correct parts
from the temporary text file to the source code.
Manual comparison of different versions, and resolving conflicts.
Does anybody think of easier, yet more automatic way of selecting which change to undo and which one to keep?
Eclipse keeps a history of your changes for a few days (configured in the Preferences in 'General > Workspace > Local History'). You can right click on a file and select 'Compare With > Local History' to see the differences between two version of your file. You can copy changes from the old version to the current version.
For the longer term you should use a version control system such as SVN or GIT. There are Eclipse plugins for these which let you do similar 'Compare With' operations - but covering the entire history of the file (provided you commit your changes regularily).
I just found this paper:
Supporting Selective Undo in a Code Editor which will be presented in ICSE 2015 conference.
The authors show the history of changes graphically, so you can choose which changes to undo (and which one to keep).
Azurite (can be download and installed from here) is the name of their implemented Eclipse plugin that supports selective undo and lots of other simple features that are useful for developers.

How to see(mark) lines, that are changed comparing to the project repo, in emacs?

Is there any way to current working copy modifications in-place by marking somehow all modified lines. For example NetBeans has the following feature:
In MSVC also, smth like this (not for VCS, but it looks alike):
Green Bars in Visual Studio 2010
I use vc-mode in Emacs to work with my versioned project. It can compute the full diff ( vc-diff) but it is inconvinient: to browse the diff separately. I want, to know all changed lines, during file-editing sesstion. Is it implemented in some version-control plugin?
The diff-hl extension does this in a VCS-agnostic way. There also exist other tools like git-gutter which are more focused on a specific VCS.

Beyond Compare 3 editing disabled

With BC2, when i click the Show differences... option in SourceGear Vault. It allow me to copy from the repository to the working version and save but I can't do this with BC3. It doesn't allow copying to the otherside (right) and have the editing disabled showing at the bottom of the BC3. It is even the same with DiffMerge. What am I not understanding here?
Can someone explain to me why the changes in BC3 and is there a workaround?
Beyond Compare will disable editing of a file for any of the following reasons:
It's one of the input files in a 3-way merge
The comparison was cancelled
The comparison encountered an error (corrupt file, invalid character encoding, out of memory, gamma rays, etc)
The file format's conversion settings don't support converting back to the original format (MS Word, PDF)
The file is on a read-only "filesystem" (7zip/RAR/CHM archives, CD/DVD-ROMs)
A file or parent folder had editing explicitly disabled by the user in the session settings or using the /ro command line switches
The viewer itself doesn't support editing (eg, Hex Compare prior to v4)
Also, the Full Edit (F2) toggle in the Text Compare View menu switches between inline editing and line-based mode. If it's disabled you can copy/delete whole lines and type in the line details edits at the bottom of the window, but the main windows won't have a cursor, typing is disabled, and it will always select whole lines. Unlike the above items, this doesn't show "Editing Disabled" in the status bar.
there must be a flag on the command line to call BC such as /ro# or /#ro or /(side)readonly (where side is left or right), it prevents editing.
these flags are there because differs are often called with temporary files to diff, in particular from SCC. and Vault probably has a single "external diff" command, thus you have to choose whether the flags are always there, it protects you from unexpectly editing a temporary file and loose this work when closing the diff tool, or not.
The few reasons I have found are:
If the encoding of the file is different than the default. In this case change the encoding to the expected one. (Japanese-ShiftJIS in my case)
If a refresh of files is in progress.