Current update schedule is too frequent to me. The editor pops out update reminder every 3-4 days.
I don't need so frequent update reminder. It's annoying to me. I am only interested in major release.
So how to get less update notification? (Every month or quarter would be preferred).
(Because of the annoyance, currently, I just ignore all update notifications. I understand it could be risky and it's not a good practice)
Current version number looks like: XX.YY.ZZ. How to only subscribe XX.YY update (ignore ZZ update)? Thanks
Thanks
You can switch to manual updates in the settings (Ctrl + ,).
This will disable the notification, and checking for updates manually will only be 2 clicks away:
Related
I have lots of old and useless notifications when I mark them done they go to "done" section (obviously) but I couldn't find a way to remove them completely. How can I remove these old notifications from my life?
There does not seem a way to manually clear out the Done section.
The documentation simply mentions:
Notifications marked as Done are saved for 5 months.
So they are cleared out eventually, but not immediately.
I using GitKraken as Git client. Here I see that, in file history it shows 1 hour ago, yesterday, 4 days ago,etc. Is there a way that I can see date time instead? I can see that in sourceTree.
GitKraken:
SourceTree:
Is there a way that I can see date time instead?
tl;dr: No, since it does not fit GitKrakens slim visual approach.
There is no feature to switch to absolute times, as far as I know. And it wouldn't really meet the purpose here: in SourceTree, you have a list (more like a table) of commits, each with id, author, message and time stamp shown.
GitKraken, following a more visual approach, focuses on the graph and the commit messages, but groups the commits in the graph by time period. There would be no point in showing a concrete date, since it would only show the date for a single commit, but not group commits by time periods. It would have to be shown for every commit separately, leading to a more table-like view, as it is in SourceTree.
In your example, You would have four timestamps cluttering your graphical repository view instead of a single 3 hours ago, roughly pinning down when the four commits where created.
You can, of course, click a commit in the graph to view its details in the top right, also showing author and commit date times.
I have pushed two changes to AOSP, same topic and they have been sitting with "Needs Code-Review Label" for 3 days now (weekend included).
I know I can assign reviewers manually, but I wouldn't know who to add. I've read around on how to submit a patch but have not found if reviewers are automatically notified and the change will be processed whenever it should or if there is something else on my side I have to do.
You just need to wait or you could, if was the case, add specific reviewers for your change. It's seens that 3 days (weekend included) aren't time enought for the review.
I'm using github for students to submit a programming assignment. And I have a strict deadline for submission and I would like to be able to check the time that their release was submitted.
Unfortunately, github only reports how many days ago a release or commit was made. Is there any (quick) way to get the exact time?
If you move your mouse over the xx minutes|hours\... ago label, a tooltip will be displayed showing the UTC time the commit was created at.
Keep in mind that Git history can be rewritten (see git commit --amend or git filter-branch commands for instance) and that this displayed time shouldn't be considered as solid proof.
Well I'm jumping into this WAAAYY late, but I wanted to add a note about this particular use case.
nulltoken is absolutely right about the possibility of the times being modified. To circumvent this, I would make use of tags. Slap together a simple script that would pull the branch at the cutoff point, tag it (using an annotated tag), and then push the tag up to github. This gives you a snapshot of the branch at that particular time, stamped the time that the tag was cut AND the name of the tagger. That last part is particularly useful for students who think they are crafty.
https://git-scm.com/book/en/v2/Git-Basics-Tagging
Cheers!
After you start tracking the source of a bunch of open source software, how do you keep your code in sync? Run svn update every time you want to look at or play with the code?
It strikes me that it would be better to essentially start mirroring the code with (say) a cron job every night. Have people set up workflows to do this sort of thing? (With alerts when/if any changes you make to the code end up conflicting with the latest update?)
Or am I on my own? (I'm running Mac OS X but interested in general as well as specific solutions.)
The general workflow recommended by the Subversion book is to update your working copy often; at the start of every work-day is a good time. But you don't have to. Just update whenever you feel like seeing the latest changes.
I have a number of open source repositories checked out under a src/ directory. Every couple of days, I remember to run 'svn up *' from that directory, and it updates all the working copies contained there.
If your repository sends you an email every time someone checks in, why not have a program that checks for those emails and then updates the working copy at that time? This way you're always up to date. Caveats include needlessly burning bandwidth and the possibility of getting odd conflicts when a file you're working on gets updated.
Just updating once a day, or once every few days, is only useful when there are a limited number of people working on a project, all in disparate areas of it. When you've got more than five people, and the possibility that they are working in similar parts of the code, updating once an hour, or more frequently, is much better.
I will update often really only when I use an open source library in my own application, the external repository will actually be part of my project tree, when I update my project it also updates the external repository. I think when you only look at code for research it will only make sense if you want to look at a new feature they released and then update.
You might want to look into using svn:externals: http://svnbook.red-bean.com/en/1.0/ch07s03.html