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.
Related
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.
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
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.
When comparing two files, for example during a commit, Eclipse shows the original version on the right and modified on the left:
However, I would prefer to see the original version on the left and modified on the right. Is it possible?
Eclipse Neon.2 (4.6.2) has a button to swap the views:
You can either swap the views for every compare, as one answer suggests:
Or you can make the swapped order be the default for all compares:
Windows --> Preferences --> General --> Compare/Patch
Select the Text Compare tab, and mark the check-box of Swap left and right
I think it's just depending of which file you're selecting first. I mean, choose a file, and select compare to .. and choose another one. Next choose the second one and compare to the first one, they'll swap in your window :)
This behaviour is influenced by what exactly is compared. When comparing two local files the view is influenced by the first & second selection. If using e.g. GIT the left hand side will always be what is present locally, the currently checked-out branch or local changes - so changing the branch will influence the view. When using SVN it is mostly the same, so left hand locally, right hand remotly.
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.