Recently I have started to see some weird things when I want to commit using TortoiseGit. The following screenshot is taken from the commit UI of TortoiseGit:
In this image, you can see the files finishing by ~HEAD
or ~CommitNumber + description of the commit.
What does it mean?
Do I need to be worried?
What should I do, or what have I done wrong?
I don't know if it's relevant but those files are supposed to be deleted.
Related
Anyone see this behavior? For example here is my code in an activity....#{concat(
substring(activity('GetMaxDate').output.firstRow.MAX_DATE,0,4)
This IS saved. Multiple times. But when I run in debug this is what is run...
#{concat(\n substring(activity('GetMaxDate').output.firstRow.MAX_DATE,1,4)\n ,'
It's running the prior version (0,4) instead of the new version (1,4). I first noticed this because I changed the name of the activity and debug still ran the old name. This seems like new problem I've not had before. If I publish and run it as trigger it picks up the change. It's just debug that's not picking it up. This seems an inexcusable bug. This is 101 functionality folks.
Any suggestions? Should this be logged with Microsoft as bug?
Additinal option to Gary's comment:
C) Rename your pipeline, save, run debug. Rename back after.
This worked for me.
Seen this cache behavior in the past. Preview query shows cached data from source table even though the source table data was completely changed.
Deleting the pipeline,dataset.. and creating new pipeline solved the issue for me.
Seems this happenens when the debug is being used too many times. Recommend to log this behavior as a bug.
I was having issues with submitting a document into Solr on Google Cloud and read somewhere that the issue should be resolved by committing.
I couldn't figure out how to commit on Solr(noob) and pressed a button called reload. The error went away, but I'm afraid I messed something else up. Can anyone explain what reload does compared to commit, or confirm if reload was fine?
No, reload isn't fine if you want a commit.
The reload command tells solr to update some core based on a new configuration (solrconfig, schema and another config files). Even if it work in your case, it's not meant for the purpose of commit.
The commit command tells solr that the data sent to it should be searchable ASAP. I guess it's what you're looking for.
For this you can configure automatic commits and/or soft commits in solrconfig.xml. There's also a URL you can call to achieve this, which is something like this: http://localhost:8983/solr/mycollection/update?commit=true
I recommend you to read this docs:
Commit
Reload
Technology used:
Microsoft Visual Studio Community 2015
VB.NET
GitHub
When i was altering skin in my form to design it, i was having trouble undoing my design to return back to its normal design. And as i go to my Form in Solution Explorer and clicked Undo everything had vanished including my code. I'm having trouble on how to retrieve my code ? Is there a way to retrieve my codes and my design or a garbage collector where i can easily retrieve it?
I would be so happy for your suggestions.I really need your Help.
The only way that you will be able to retrieve your old code at this point is if you did a
git push origin master
(or other branch) to github before you made these changes.
If you haven't use Git Extensions - I would suggest downloading and linking it to your github repo for this project. Git Extensions will give you a nice quick view of all your branches and what is sitting in your local repo.
Provided that you did a
git commit
You will still have your changes saved locally and this can be easily identified using Git Extensions.
If you have made the changes after you did a commit, you will see the old code in Git Extensions. From here you will be able to revert selected lines or all of the files. This is provided, that you had at least one major commit in git before this happened.
Update 1:
Based on your comment on your OP you should still have the original files in git. You should then be able to find your code easily via Git Extensions. You should see a list of changed files and from here you can revert them easily.
Update 2: Based on your comments, it appears that you have completely lost your changes. Git is a change tracker - and based on what you have said you did an Undo Changes on git. This means, that git had reset all the changes that it was tracking and went back to the last commit that you made. There is no way to get your changes back unless you had the files stored on DropBox or something similar where files are tracked on each save of the file. With git, changes made are only stored once committed. If you do an undo changes on the git repo before committing what it actually does is a
git reset
This removes all the changes and reverts it to the last commit.
I've checked and found this. I expect this should deal with your problem. Afterall, as long as you didn't intentionally delete anything, they are still in your target folder where you saved it.
If you checked in your code BEFORE the error on GitHub you can try this:(although I am not certain of community edition as I know it works on Pro and Enterprise).
Go to class in question
Right Click to get context menu
Select Source Control>History
Select a prior version
Right Click Reset>Reset and Delete Changes
This will basically say: "I don't care what happened just take me back to my safe place at this point in time with all affected files!". When performing code I cannot stress the importance to having source control and committing often.
I have shelved my 26 java files changes via Intellij Idea 2016.2.1 and I checkout to different branch.
When I came to old branch to check my shelved changes.
I gone a mad now, I lost all the files. I was worked nearly two months
Can somebody help to get it back?
You can restore the state of those files if they were edited in IntelliJ. Use local history to see all the changes made in IntelliJ (VCS -> Local History -> Show History).
Even there isn't Shelf tab in IDE you can find shelved changes as patch files at {ProjectName}/.idea/.idea.{ProjectName}/shelf/.idea/shelf.
Then your can apply any selected patch.
I was able to view lost changes and revert back to them by:
right click on project directory, select Local History > Show History
Find the entry in the history menu that you want to restore. You can examine the files by double clicking on the entry and the files to examine differences.
Right click on the entry you want to restore, and select Revert
Note in my case Git>VCS Operations>Show History showed nothing. Only through the Project Files menu.
Andrei's answer was helpful for my situation where I renamed my project and my previously shelved changes were no longer found under the shelf, but I did run into an issue when applying the patch file because I was prompted to "Select missing base" for various files in the patch. Similar to what is seen in the screenshot below:
https://youtrack.jetbrains.com/issue/IDEA-183910
I was able to avoid having to "Select missing base" for various files by first changing the default shelf location and then applying the patch.
https://www.jetbrains.com/help/idea/shelving-and-unshelving-changes.html#change-shelve-location
Also, I found my patch in this location:
{ProjectName}/.idea/shelf
instead of the aforementioned location:
{ProjectName}/.idea/.idea.{ProjectName}/shelf/.idea/shelf
Maybe this will help someone:
I lost part of my shelved changes in combination with an update of IntelliJ. I'm not sure if the update was the reason but eventually most of my most recent (and important) changes were gone.
I couldn't restore them from local history as this does not "survive" an update of IDEA. But in the files I saw that there still is some data:
C:\Users\myUser\AppData\Local\JetBrains\IntelliJIdea2021.2\LocalHistory had a changes.storageData with ~50MB.
Copying the files to the folder of the new version didn't help as the files got overwritten again.
Solution:
I was able to get the old version of IntelliJ (2021.2) here and installed it. This can be done in parallel, without removing the newer version.
Here I was able to retrieve my changes from the Local History and shelve or apply them again.
Hint: Backup the "Local History" folder (or the whole IntelliJIdea20xx.x folder) before you start. I don't remember if I had to copy it in there again or if it worked out of the box. (Just to be sure the local history doesn't get lost).
I've also experienced this bug repeatedly and hence no longer use shelved changes, but rather the Git CLI directly. As of 2022 Jetbrains IDE's still cannot be trusted with their "Smart Checkout" feature, which has a small probability of the total loss of your files (experienced personally in both IntelliJ & Rider).
Unlike another comment here regarding using the Local History, this did not work for me as the history showed nothing. I've also lost many hours of work due to this bug which remains unfixed.
The solution is to use "git stash -u" on the command line, then checkout the desired commit. Once youre done, type "git stash apply" to restore your files. Trusting the "smart checkout" feature is like playing Russian roullette. It's IDE magic that may just fail and you lose everything.
I've got a graph that isn't behaving as it should in CloudConnect.
I'm running it locally, and it's completing, but not doing its work.
In an effort to figure out why this is, I've added printLog calls in many places, like the following
printLog(warn, 'transfrom from file ' + $in.0.fileName);
printLog(debug, 'joining etc');
The Phase consists of a FileList into a SimpleCopy, into a LookupJoin, a Reformat (produce SQL) and a DBInsert.
However, while I see logs for phases above, I'm not seeing anything produced in the log for any part of my phase. All parts of the phase do report running successfully in log. I've also done Enable Debugging on all connections in this phase.
Am I missing something to enable logging? Is there a better way to debug processing in CloudConnect?
Discovered the problem - the FileList will succeed if the source file cannot be found, but none of the subsequent steps will then fire. It's somewhat unintuitive, since the log files says 'succeeded'.
For debugging, after run you can access the data by right clicking on the connection, and selecting "View Data"
Sorry for the elementary question, but documentation didn't seem to cover this clearly, at least for a GoodData noob. I'll leave it up for anyone with the same problem!