31–40 of 54 posts
Seems to be back up. I assume they waived the rate limit. curl --head https://raw.github.com/git/git/master/Documentation/RelNotes/1.8.0.txt HTTP/1.1 200 OK Server: nginx Date: Mon, 22 Oct 2012 05:32:02 GMT Content-Type: text/plain; charset=utf-8 Connection: keep-alive Status: 200 OK X-Runtime: 14 X-RateLimit-Limit: 100 Content-Length: 1 X-Frame-Options: deny Cache-Control: no-cache X-RateLimit-Remaining: 100
http://git.kernel.org/?p=git/git.git;a=blob_plain;f=Document...
> "git branch --set-upstream" is deprecated and may be removed in a relatively distant future. "git branch [-u|--set-upstream-to]" has been introduced with a saner order of arguments. It would be great if changes to the git CLI were thoroughly thought through instead of one-off fixes like this. This is the reason the interface is such a mess. git branch foo --track origin/foo But if you forgot --track: git branch foo…
Wait, what exactly happens in that last one that I shouldn't dare do?
git branch --set-upstream origin/foo
A credential helper for Win32 to allow access to the keychain of the logged-in user has been added.
> "git branch --set-upstream" is deprecated and may be removed in a relatively distant future. "git branch [-u|--set-upstream-to]" has been introduced with a saner order of arguments. It would be great if changes to the git CLI were thoroughly thought through instead of one-off fixes like this. This is the reason the interface is such a mess. git branch foo --track origin/foo But if you forgot --track: git branch foo…
The usual pattern of a copy command:
copy source destination
The pattern of git push command
push destination source:destination
http://perlalchemy.blogspot.com/2011/04/git-push-and-other-c...
You're over the rate limit. Serve this file from your own servers. Contact support@github.com if you have questions.
got the same "You're over the rate limit. Serve this file from your own servers. Contact support@github.com if you have questions."
Earlier quoted context omitted.
Wait, what exactly happens in that last one that I shouldn't dare do?
I should have written: git branch --set-upstream origin/foo This counter-intuitively creates a LOCAL (!) branch named origin/foo which tracks the current branch. I would expect this to set the upstream of the current branch, given that most commands operate on the current branch unless otherwise specified. Instead it does something completely unexpected and useless.
Earlier quoted context omitted.
I should have written: git branch --set-upstream origin/foo This counter-intuitively creates a LOCAL (!) branch named origin/foo which tracks the current branch. I would expect this to set the upstream of the current branch, given that most commands operate on the current branch unless otherwise specified. Instead it does something completely unexpected and useless.
which invalidates part of your point, because --set-upstream is now _deprecated_.
Regardless, my point is the interface is horrible and this is just adding to the patchwork. Why not add --track semantics or unify these flags?
Earlier quoted context omitted.
I'm surprised they don't exempt high profile public projects from limits like that. Git being hosted on Github is hugely beneficial to their image. Any roadblocks should be eliminated for VIPs, especially if the consequence is just a few bucks more in bandwidth bills.
We actually don't care about rate limits with this type of raw request. The limits are in place because people (usually porn sites) hot link js/css/image assets which can lead quickly to an insane number of requests. If file extensions could be used to determine whether a resource could be used like this, we'd only apply the rate limits to those. Browsers don't care about extensions or event content types though. The…
https://code.google.com/p/browsersec/wiki/Part2#Content_hand... http://mimesniff.spec.whatwg.org/
Earlier quoted context omitted.
which invalidates part of your point, because --set-upstream is now _deprecated_.
It's deprecated in the next release not this one, and it will be around for years to come. People will google and find the old way documented and have to read up on the difference, adding to the cognitivie baggage of git. Regardless, my point is the interface is horrible and this is just adding to the patchwork. Why not add --track semantics or unify these flags?