Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Git 1.8.0

raw.github.com

Post reply on HN
Print view View original

21–30 of 54 posts

Re: Git 1.8.0

#23

Post by Osiris »

Why in the Release Notes do they use the verb "learned" to describe adding a command line option to a feature?

  "git cherry-pick" learned the "--allow-empty-message" option
It's not like Git has obtained sentience and has started to teach itself new tricks, though that would be an interesting development.

I understand what they are trying to say I just thought the choice of verb and subject was odd, leaving out the developers as those acting on the code.

Re: Git 1.8.0

#25

Post by chaitanyav »

Zash wrote: post #3

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."

Re: Git 1.8.0

#26

Post by _ikke_ »

isarat wrote: post #22

I really wish a day when I am able to download the code with minimal footprint. (few previous versions).

git archive allows you to download only a specific version (though, it doesn't work for github because they haven't enabled it)

Re: Git 1.8.0

#27

Post by rtomayko »

reitzensteinm wrote: post #18
Zash wrote: post #3

You're over the rate limit. Serve this file from your own servers. Contact support@github.com if you have questions.

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. They'll happily use whatever's at the other end of a URL for , , and tags.

As for whitelisting, it's a path we just don't want to go down for raw requests. We do a lot of that for the API and it isn't cheap to maintain.

Re: Git 1.8.0

#28

Post by derleth »

Osiris wrote: post #23

Why in the Release Notes do they use the verb "learned" to describe adding a command line option to a feature? "git cherry-pick" learned the "--allow-empty-message" option It's not like Git has obtained sentience and has started to teach itself new tricks, though that would be an interesting development. I understand what they are trying to say I just thought the choice of verb and subject was odd, leaving out the de…

Developers often anthropomorphize things to gloss over irrelevant details. The focus is on what, not how, and anthropomorphizing is the quickest route to get that across.

Re: Git 1.8.0

#29

Post by makeramen »

aneth4 wrote: post #13

> "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?

Re: Git 1.8.0

#30

Post by peff »

Osiris wrote: post #23

Why in the Release Notes do they use the verb "learned" to describe adding a command line option to a feature? "git cherry-pick" learned the "--allow-empty-message" option It's not like Git has obtained sentience and has started to teach itself new tricks, though that would be an interesting development. I understand what they are trying to say I just thought the choice of verb and subject was odd, leaving out the de…

Writing it in the passive voice is slightly more awkward. E.g., "git cherry-pick" was enhanced with an "--allow-empty-message option".

Similarly, writing it in the active voice but attributing the verb properly ends up with meaningless words: "Developers taught cherry-pick to..." or "We taught cherry-pick to...". Every entry would begin that way; having the first words be the relevant subsection of git makes it easier to skim through the release notes.

Post reply on HN