I normally create new branches from master for different JIRA tasks and them merge them back into master with pull requests when the task is completed.
However, I'm using Rstudio and always have a local script open which acts a a rolling cookbook of tricks and tips to look back on. Basically its a library of my R knowledge.
Unfortunately I believe I've lost a couple of weeks work on this file as I think dropped any changes from the master branch, then created a new branch, created/edited a different file and merged back into master for a separate task.
I'm on Windows 10 and restore previous version doesn't seem to be available. The last restore point is a day after the last pull request I had merged. Im trying to find a way to find any other version of this file either in Git or older versions on my machine.
Whats the best way or tools to do this. I've lost some changes to an algorithm I'd been working on which successfully turned a 6 hour job into a 10 min job and I don't want to try and remember how I did it. I'm using visual studio for Git and I've got Git tortoise. According to tortoise There was a merge on 19/04 and nothing before 09/02 so I don't think Git ever staged or committed the changes I've lost that were all written between the 16/04 and 20/04.
EDIT
I think I've found it. Although its not in my Rstudio history in the UI (or the history file opened in notepad), when I use the search function in Rstudio's history it finds it?! Rstudio apparently has everything I've ever written and its timestamped too.
Still keeping this question open for future issues (although I've made this file local now to avoid this in the future). If anyone knows where the 'master' history file for Rstudio too thats of interest.
As mentioned in How to access the script/source history in RStudio?
RStudio's source panel is essentially a view to an Ace Editor
You have found the "searching history" which allows you to find back all past files/commands.
Related
I have a problem with Gitlens extension. Firstly, Gitlens or Git History extension is working fine on any other project except the this Laravel project. My problem is, can`t see the file history or line history in this project.
On the other hand, there is no problem in the git log (Git History Extension) as seen in screenshot;
But I can't compare any files with their any version (every commit seems like in the ss). I have no idea what the problem is about.
Lastly, I don't think the problem is about extension settings because other projects do not have this problem. Is there a any chance to fix this issue without resetting git history?
I am answering after 3 months, maybe it works for someone. As I mentioned in the title, surely there is no problem about extension settings for this specific project. The problem is just about git files. Maybe, I damaged some git files while moving the project on my desktop :)
So, there is no chance to fix this issue without resetting git history or starting fresh with git, if you`re having the same problem.
Do not play with git files, it`s no joke!
I've got a similar issue. My problem is in using symbolic links for folders.
I have this folder symlink for my repos.
C:\>dir
Directory of C:\
27.09.2018 21:07 <JUNCTION> repos [C:\Users\Qwerty\repos]
(GitLens v11)
The top editor is opened via C:\repos
The bottom editor via C:\Users\Qwerty\repos
You can see that some git features still work (yellow), but others don't.
However, this is very strange, because in my other repos, I have never observed such issues.
Also notice below that it is still possible to invoke the same action via a git lens popup and then it is possible to use the Prev Next Revision buttons.
Anyway, after more testing, I actually observe the same thing in my other repos. I assume that something must have changed between versions as I only observe these issues for last maybe 2-3 months. I even submitted a ticket that GitLens stopped working in v12.0.0 and later versions https://github.com/gitkraken/vscode-gitlens/issues/1979
The buttons completely disappeared and even the commit information
v11
v12
And Now actually, after having reopened my repo via original path and after updating GitLens back to v12.0.6 I see that it is working properly!
Bottom editor is opened via C:\repos symlink.
I pressed Alt-E which I mistakenly thought was Merge Changes In Merge Tool, however, that was actually Keep Local Version. Is there a way to go back? Is there a way to find out what was merged, as in what file? Ugh! :(
I have completely stopped working in case I erase something of importance.
I'm using MSVS 2013 Professional.
Here's another possible approach.
If you know what version of the code you started with before you started making your current batch of changes, you can grab a copy of your local workspace files. Then Undo all your Pending Changes. Then delete all the files in your local workspace (in Windows explorer). Then do a Get Specific Version to get back the old version of the files from where you started, then copy-paste in your updated files from your backup copy. Then do a Get Latest. This should retrigger the Merge process.
I don't know a great answer to this problem, but I do know one thing you can do (I hope you don't have a massive amount of pending changes, or this will get tedious).
The problem is that TFS thinks you have now merged the server changes (other devs changes) into your workspace, even though you told it to basically toss them. If you try to check-in now it will blow away other developers changes in TFS.
What you can do is go through each file in your pending changes window, and do a Compare With Latest Version. This will show you the differences between your local file, and the file in TFS. You will notice two types of differences:
the changes you made which you can just skip past.
Changes that other devs made and are on the server, these differences will show up as though you have deleted/undone that code locally
For the changes that other devs made, you will have to manually reapply them in your local workspace before you check-in.
Actually I have faced this issue many time during working with SVN. Most of the time I am working with VSS for source control but since last couple of months working with SVN.
We are using tortoise and AnkhSVN with VS 2010.
In our team there are 5-6 people and some of them are working on same file at a time. Now when somebody commit , we have seen that some other developer changes get vanished and Sometime we get some line with version number. This thing get consume lots of time and we have to resolve conflict and all.
Please provide information so we can avoid such issues.
If two developers are working on the same file and make changes to the same are of code, then you have to manually resolve this conflict. There is no way to avoid it, no matter which version control you use.
The version control cannot know what the correct code is, so it requires a human intervention.
There is no way around this, other than preventing the users from working on the same code. this is done in svn by locking the file.
Each developer must svn update before svn commit. Between the update and commit, the developer must do a full, clean build and run all tests to make sure their code still works after merging in all other developer's changes into their copy.
You can set svn:needs-lock on files or folders that need to be locked before making changes, they'll be forced to check for locks. When you will try to edit a file, you will be required to lock it first. And when it is already locked by someone else, they you get an error message, preventing you from making any changes. This can be done in Tortoise SVN in Properties -> Advanced
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Git GUI.. stage everything
My employer is finally looking into setting up some source control after much pleading by all of the developers. Unfortunately, none of our developers, inclusive of myself, have ever done much with source control. I've looked into SVN and thought that would be fine but another of the developers didn't like it. I've moved on to looking at GIT as an option. I've downloaded the GIT GUI from http://git-scm.com and started tinkering with it which brings me to my question/problem.
The web application we're trying to add to source control (GIT) is 7,386 files and 712 folders. When doing the initial commit, from what I understand, I've got to click on each file I want to commit to move it from the Unstaged Changes to Staged Changes pane. Well obviously I am hesitant to sit and click 7,386 times (once for each file to commit). Is there another faster way to do this?
I'm currently using this page as my reference to learn to use the GIT GUI http://nathanj.github.com/gitguide/tour.html. If anyone has a better tutorial/reference for using the GIT GUI I'd much appreciate linking me to it.
Thanks
To add every file (that is not ignored), use
cd /path/to/workspaceRoot
git add .
I don't use any gui, but I think this should be possible by adding a directory (the root directory in this case).
Remember to create a appropriate .gitignore file before, so no unwanted files get added. You can check, what is (un)staged with
git status
Also, there should be a context option (or something like that) in your gui, that provides status.
Extra: Additional git resource (quite good imo) http://progit.org/
From Git-GUI select all files in the "Unstaged changes" list and select "Commit->Stage to commit" in the menu.
If you're not afraid of the command line, try this tutorial instead. It's a detailed walkthrough of beginning git in 10 parts and ends with a Git reference card to help you go further. The free Pro Git book is also much applauded.
Like many programmers, I'm prone to periodic fits of "inspiration" wherein I will suddenly See The Light and perform major surgery on my code. Typically, this works out well, but there are times when I discover later that — due to lack of sleep/caffeine or simply an imperfect understanding of the problem — I've done something very foolish.
When this happens, the next step is do reverse the damage. Most easily, this means the undo stack in my editor… unless I closed the file at some point. Version control is next, but if I made changes between my most recent commit (I habitually don't commit code which breaks the build) and the moment of inspiration, they are lost. It wasn't in the repository, so the code never existed.
I'd like set up my work environment in such a way that I needn't worry about this, but I've never come up with a completely satisfactory solution. Ideally:
A new, recoverable version would be created every time I save a file.
Those "auto-saved" versions won't clutter the main repository. (The vast majority of them would be completely useless; I hit Ctrl-S several times a minute.)
The "auto-saved" versions must reside locally so that I can browse through them very quickly. A repository with a 3-second turnaround simply won't do when trying to scan quickly through hundreds of revisions.
Options I've considered:
Just commit to the main repository before making a big change, even if the code may be broken. Cons: when "inspired", I generally don't have the presence of mind for this; breaks the build.
A locally-hosted Subversion repository with auto-versioning enabled, mounted as a "Web Folder". Cons: doesn't play well with working copies of other repositories; mounting proper WebDAV folders in Windows is painful at best.
As with the previous method, but using a branch in the main repository instead and merging to trunk whenever I would normally manually commit. Cons: not all hosted repositories can have auto-versioning enabled; doesn't meet points 2 and 3 above; can't safely reverse-merge from trunk to branch.
Switch to a DVCS and "combine" all my little commits when pushing. Cons: I don't know the first thing about DVCSes; sometimes Subversion is the only tool available; I don't know how to meet point 1 above.
Store working copy on a versioned file system. Cons: do these exist for Windows? If so, Google has failed to show me the way.
Does anyone know of a tool or combination of tools that will let me get what I want? Or have I set myself up with contradictory requirements? (Which I rather strongly suspect.)
Update: After more closely examining the tools I already use (sigh), it turns out that my text editor has a very nice multi-backup feature which meets my needs almost perfectly. It not only has an option for storing all backups in a "hidden" folder (which can then be added to global ignores for VCSes), but allows browsing and even diffing against backups right in the editor.
Problem solved. Thanks for the advice, folks!
Distributed Version Control. (mercurial, git, etc...)
The gist of the story is that there are no checkouts, only clones of a repository.
Your commits are visible only to you until you push it back into the main branch.
Want to do radical experimental change? Clone the repository, do tons of commits on your computer. If it works out, push it back; if not, then just rollback or trash the repo.
Most editors store the last version of your file before the save to a backup file. You could customize that process to append a revision number instead of the normal tilde. You'd then have a copy of the file every time you saved. If that would eat up too much disk space, you could opt for creating diffs for each change and customizing your editor to sequentially apply patches until you get to the revision you want.
if you use Windows Vista, 7 or Windows Server 2003 or newer you could use Shadow Copy. Basically the properties window for your files will have a new tab 'previous version' that keeps track of the previous version of the file.
the service should automatically generate the snapshot, but just to be safe you can run the following command right after your moment of "inspiration"
'vssadmin create shadow /for=c:\My Project\'
it has defiantly saved my ass quite a few times.
Shadow Copy
I think it is time to switch editors. Emacs has a variable version-control, which determines whether Emacs will automatically create multiple backups for a file when saving it, naming them foo.~1~, foo.~2~ etc. Additional variables determine how many backup copies to keep.