

Git 1.8.0 - pyrotechnick
https://raw.github.com/git/git/master/Documentation/RelNotes/1.8.0.txt

======
aneth4
> "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
    

then it's:

    
    
      git branch foo --set-upstream-to origin/foo
    

and don't you dare do

    
    
      git branch --set-upstream-to origin/foo
    
    

Upstream and track are the same - why two different words?

And now we have --set-upstream-to and --set-upstream, which will be fun for
git newbies to distinguish.

~~~
makeramen
Wait, what exactly happens in that last one that I shouldn't dare do?

~~~
aneth4
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.

~~~
ibotty
which invalidates part of your point, because --set-upstream is now
_deprecated_.

~~~
aneth4
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?

~~~
cmn
\--set-upstream is deprecated in this release.

~~~
Johngibb
Deprecated, but not removed yet. It "may be removed in a relatively distant
future"

~~~
cmn
This is what deprecated means. You can't just remove an API that's existed for
years and scripts may depend on without giving them time to adapt. This shows
a warning when it's used so it's clear which scripts should be changed.

------
Zash

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

~~~
reitzensteinm
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.

~~~
rtomayko
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 <link rel=stylesheet>, <script>, and <img> 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.

~~~
Tobu
Browsers will ignore content-type in many cases (html5 embraced that quirk),
but they do have to sniff the bytes to confirm their hunch. You could use
`file` to detect images. Or use the content length, maybe by changing hit
quotas into bandwidth quotas.

[https://code.google.com/p/browsersec/wiki/Part2#Content_hand...](https://code.google.com/p/browsersec/wiki/Part2#Content_handling_mechanisms)
<http://mimesniff.spec.whatwg.org/>

------
dfc
[http://git.kernel.org/?p=git/git.git;a=blob_plain;f=Document...](http://git.kernel.org/?p=git/git.git;a=blob_plain;f=Documentation/RelNotes/1.8.0.txt;hb=8c7a786b6c8eae8eac91083cdc9a6e337bc133b0)

~~~
gulbrandr
Thank you.

------
solox3
That's a good change. I've never had the need to "git push" an entire repo,
and pushing the current branch is simply more natural to do.

------
alpb
That's great, guys using Homebrew can get this version by writing these:

    
    
        brew update
        brew upgrade git

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

~~~
CUViper
That's a _shallow_ clone: git clone --depth N ...

------
nodesocket
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

~~~
netshroud
X-RateLimit-Limit? Sounds redundant.

~~~
technoweenie
They're the same headers the Twitter API uses:
<https://dev.twitter.com/docs/rate-limiting/1.1>

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

~~~
peff
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.

------
manojlds
Does someone have more info on this:

A credential helper for Win32 to allow access to the keychain of the logged-in
user has been added.

~~~
mrnil
You can find it in contrib:
[https://github.com/gitster/git/tree/master/contrib/credentia...](https://github.com/gitster/git/tree/master/contrib/credential/wincred)

See man 7 gitcredentials on how to set it up.

------
hack_edu
> In the next major release (not _this_ one), we will change the behavior of
> the "git push" command.

So wait, is that in this release or not? Why put this at the very most top
part of the file without even mentioning what release it will actually be in?

~~~
josegonzalez
No, it is not in THIS release. it is in the NEXT major release. 1.8.0 is the
current major release. 1.9.0 (or 2.0.0, whatever) will have the change.

------
patrickod
Anyone have a mirror? GitHub has stopped serving this as it's over their rate
limit.

~~~
josegonzalez
[https://github.com/git/git/blob/master/Documentation/RelNote...](https://github.com/git/git/blob/master/Documentation/RelNotes/1.8.0.txt)

------
urza
Can git work with subtrees yet?

------
vinitool76
Is updating worth it?

------
messel
looking for saner nested submodule pulling , reading now

------
Brajeshwar
btw, what is Github's rate limit?

~~~
wahnfrieden
I don't know, but it's not meant for hosting pages or page resources unless
you use their "pages" feature, so they set it pretty low.

~~~
Daniel_Newby
Didn't Github suffer a DoS attack in the past few days?

~~~
wahnfrieden
Yea, these notices under light load are nothing new though.

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

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

