> "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.
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.
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.
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?
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.
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.
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.
Also note, it is quite easy to transform github urls back and forth.
For all text files, there is a `blob` portion that comes after the repository name and before the branch. You can change that to `blame`, `commits`, `edit`, or `raw`. When changing it to `raw`, the user is redirected to the `raw.github.com` subdomain. `blob` is the normal view, and `commits` is a history of the file.
Note that using the `edit` version will instantly create a fork in your account for that repo. Resulting in notifications for it, regardless of whether you actually edit it. I guess it's eager forking so that the user doesn't notice this in the foreground. Blech.
You can also change the branch name - it is master in this case - to whatever branch you want. Or commit-sha. Or tag. Almost anything tree-ish will work with Github's UI.
The cool thing about this is that it also pretty much works for the gist service they provide, which allows you to do stuff like:
- create javascript-based inline diffs
- show changes across multiple forks of a gist
- consolidate commits for a file
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.
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.
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.
> 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?
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.
But if you forgot --track: then it's: and don't you dare do 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.