51–60 of 85 posts
Earlier quoted context omitted.
It's called GitLab. Not 100% uptime but better (and constantly improving)
It will take a long time before GitLab can even begin to regain my trust from their missing-backups outage. Problems are to be expected. But as great as it is that they had multiple levels of backup, none of them worked . They hadn't even been tested.
Earlier quoted context omitted.
It's called GitLab. Not 100% uptime but better (and constantly improving)
It will take a long time before GitLab can even begin to regain my trust from their missing-backups outage. Problems are to be expected. But as great as it is that they had multiple levels of backup, none of them worked . They hadn't even been tested.
Seeing an interesting thing where my github issue comments just posted are apparently posted a short time in the future. http://imgur.com/a/eQSc9 Doesn't seem to break anything, but it is a bit curious. May not be new though...I just happened to notice it today.
As others have said, Github's postmortems are always great. But frankly, I'd rather they have better uptime. Every couple months is too much. I pay them. My work pays them. If their CEO is serious about zero downtime, how about he offers his paying customers a credit for time they cannot access the service?
> I pay them. My work pays them. Hmm. You pay them to uphold a contract. What does that contract say about SLAs and availability? Probably the same as the TOS that I agreed to when paying and those specifically say: GitHub does not warrant that the Service will meet your requirements; that the Service will be uninterrupted, timely, secure, or error-free; that the information provided through the Service is accurate,…
An upgrade from Team to Business is "only" a 2.3x price bump per dev. I have no experience with this though, my team is still of the Team plan and thus suffered from the outage today.
As others have said, Github's postmortems are always great. But frankly, I'd rather they have better uptime. Every couple months is too much. I pay them. My work pays them. If their CEO is serious about zero downtime, how about he offers his paying customers a credit for time they cannot access the service?
My problem with a credit is that it never even comes close to what I'm losing in income. An ISP is an excellent example. I might get a $10 credit for 24 hours of downtime. I'm charging slightly more per hour than that... /s Maybe switch to bitbucket or other competition for a while?
Earlier quoted context omitted.
My problem with a credit is that it never even comes close to what I'm losing in income. An ISP is an excellent example. I might get a $10 credit for 24 hours of downtime. I'm charging slightly more per hour than that... /s Maybe switch to bitbucket or other competition for a while?
switched to gitlab a few weeks ago, didn't notice the outage until I saw this thread.
As others have said, Github's postmortems are always great. But frankly, I'd rather they have better uptime. Every couple months is too much. I pay them. My work pays them. If their CEO is serious about zero downtime, how about he offers his paying customers a credit for time they cannot access the service?
My problem with a credit is that it never even comes close to what I'm losing in income. An ISP is an excellent example. I might get a $10 credit for 24 hours of downtime. I'm charging slightly more per hour than that... /s Maybe switch to bitbucket or other competition for a while?
Earlier quoted context omitted.
Git timestamp can be set with different timezone so technically GitHub can analzye the timestamp (which they do) and compare with the actual clock of timezone. There's only a small problem though: the latency from the clock check server must be low otherwise we would be 1 second ahead by the time we get response and then another second or two after webpage render. So from a UX we should simply discount time drift +-5…
Wow, interesting. This info is definitely filed away, thanks. I don't quite remember but I think I might've been commenting on something on GitHub when I saw the time glitch. Initially for a moment I thought "why not just have OCD local NTP tracking?" but then I realized that time glitching around (even at the millisecond level) can be disastrous. One way to solve this is to obsess about keeping up to date with NTP,…
While parent object ids are provided on the command line, author and committer information is taken from the following environment variables, if set:
GIT_AUTHOR_NAME
GIT_AUTHOR_EMAIL
GIT_AUTHOR_DATE
GIT_COMMITTER_NAME
GIT_COMMITTER_EMAIL
GIT_COMMITTER_DATE
(nb "" and "\n"s are stripped)
In case (some of) these environment variables are not set, the information is taken from the configuration items user.name and user.email, or, if not present, the environment variable EMAIL, or, if that is
not set, system user name and the hostname used for outgoing mail (taken from /etc/mailname and falling back to the fully qualified hostname when that file does not exist).
A commit comment is read from stdin. If a changelog entry is not provided via " , where is the number of seconds since the UNIX epoch. is a positive or negative offset from UTC. For example CET (which is
2 hours ahead UTC) is +0200.
RFC 2822
The standard email format as described by RFC 2822, for example Thu, 07 Apr 2005 22:13:13 +0200.
ISO 8601
Time and date specified by the ISO 8601 standard, for example 2005-04-07T22:13:13. The parser accepts a space instead of the T character as well.
Note
In addition, the date part is accepted in the following formats: YYYY.MM.DD, MM/DD/YYYY and DD.MM.YYYY.
* https://github.com/yeukhon/demos/commits/master/git-date
* https://github.com/yeukhon/demos/blame/a9fc9dfe6d35c5ffe14af...
* https://github.com/yeukhon/demos/commits/a9fc9dfe6d35c5ffe14...
You see I got a 3 minute (using local time) and then 4 hours ago because I set the timestamp manually in the most recent commits. So yes you can set time in the future / past.
Seeing an interesting thing where my github issue comments just posted are apparently posted a short time in the future. http://imgur.com/a/eQSc9 Doesn't seem to break anything, but it is a bit curious. May not be new though...I just happened to notice it today.
I've seen that, but I've chalked it up to clock skew on the client. It only seems to happen on one of my machines, and only after a couple months of uptime.
Fairly compact implementation too: https://gist.github.com/anonymous/33710bd9c7175a645dd0d72d1a...