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

41–50 of 54 posts

Re: Git 1.8.0

#41

Post by cmn »

aneth4 wrote: post #33
makeramen wrote: post #29

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.

So why are you unhappy about this option being deprecated? Have you tried it in this release? It tells you it's deprecated and which options exist. If you do what you show in this command, it tells you how to undo it with the new more sensible option.

Re: Git 1.8.0

#42

Post by malkarouri »

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…

I would have gone for

"git cherry-pick" acquired the "--allow-empty-message" option

or

"git cherry-pick" now has the "--allow-empty-message" option

myself. I think the subject is fine with the emphasis where it belongs. The verb is weird, though.

Re: Git 1.8.0

#46

Post by xyz-x »

Awesome, now when and where do I download it for Windows??? "Please checkout the source and build it yourself" - wtf.

Re: Git 1.8.0

#47

Post by riffraff »

netshroud wrote: post #31
nodesocket wrote: post #20

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

X-RateLimit-Limit? Sounds redundant.

maybe they meant to have

   X-RateLimit-reset-at
   X-RateLimit-remaining
etc, so X-RateLimit- works as a sort of namespace.

Re: Git 1.8.0

#48

Post by e40 »

xyz-x wrote: post #46

Awesome, now when and where do I download it for Windows??? "Please checkout the source and build it yourself" - wtf.

Or wait for it to appear in the Cygwin release cycle. Or, msysgit. I think you're being overly dramatic.

Re: Git 1.8.0

#49

Post by nicholassmith »

rtomayko wrote: post #27
reitzensteinm wrote: post #18

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…

"The limits are in place because people (usually porn sites) hot link js/css/image assets"

I'd like to be surprised by that but I'm not.

Re: Git 1.8.0

#50

Post by nicholassmith »

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…

It does occasionally feel like the CLI development happens with a very short time scale imagined rather than planning it out, which is slightly odd given Linus' involvement.
Post reply on HN