I'm wondering whether the intention with these sorts of blog posts (GitHub has done several of these in the past[1,2], where they provide a summary of the release notes) is to try to put in people's minds the link that "git" == "GitHub". To be fair, the author is actually the 2nd largest contributor (by commits) to the git project. Just thought it was a bit strange.
I don't know... While the title might give that impression, the opening paragraph seems pretty up-front about distinguishing "the open source Git project" from GitHub ("here's our look..."). They don't even mention their not-insignificant contributions to the project, nor do they say things like "we added [x]", even though they legitimately might be able to in some cases.
And, given their line of work, it would be kind of surprising if the GitHub blog didn't cover recent Git developments.
The point is, by publishing this kind of posts, Github is making you associate git with Github. Anecdote example: my university lecturer calls Github APIs "git APIs". While that might not be a bad thing, it blurs the boundary between an open source project and a company.
I can already imagine Github having influence on the direction of git project and becomes the de facto owner, and the impact on its competitors and the repository hosting industry. The equivalence would be Microsoft, instead of owning TypeScript, owns the ECMAScript specification.
>The point is, by publishing this kind of posts, Github is making you associate git with Github
Well, git IS associated with GitHub. It's the de facto #1 hosting service for Git repositories, eclipsing all others, and the #1 host of open source git repos. They're also major contributors to Git.
But regardless of all that, they host git repos. They literally work with people that use Git, day in, day out, and help them host their git managed code.
Of course they'll cover developments in Git. Who else would be more natural to cover them (aside something like "Git planet")? The GTK+ blog? The IEEE?
I think GitHub has done a great job being a good steward of the git project. They welcomed us (GitLab) to events like git merge. Because they made git popular people are sometimes confused about the difference between git and GitHub. But GitHub has done a great job on not muddling the water themselves.
I'm not saying that, just giving our point of view. BTW I still meet a lot of people that think GitHub is open source instead of them hosting open source.
I've had colleagues believe bitbucket is a replacement for git.
I had to explain there's a quite big difference between the two. I assume he had mixed up github with git and correctly deduced bitbucket is an alternative to github.
Also, I got way too excited over the git news to notice that it was github publishing ...
FWIW, I'd expect any git hosting provider -- including gitlab.com and bitbucket.com -- to be similarly eager to evangelize new git releases, since an improvement to git is an improvement to the usability of their offerings. At the very least, encouraging users to upgrade to easier-to-use git versions could reduce support costs and customer churn.
Open source developers have to eat too. I think it's a win-win. GitHub makes money by leveraging open source and they pay their employees to contribute to Git that benefits everyone.
Writing genuinely informative articles about your company's area of competence is a very widespread marketing approach. Just earlier today I've read a brief overview on moment theater written by some theater's marketing team. They didn't try to hide that it's a material designed to sell their tickets, but it didn't make it any less interesting.
Thanks for the feedback in this thread (I'm the author). The main goal _is_ to let people know about the new version, and about new features they can use (there are a ton of other new features and a lot of backend speedups and cleanups that I don't bother to highlight, because they're not really actionable by normal users).
I've tried to make the Git vs GitHub distinction clear in the first paragraph without belaboring it, but I agree with the sentiment here that the title muddies things. For future iterations I'll look into something more like "A look at the new features in v2.17".
I think the title you used is a lot less confusing than "A look at the new features in v2.17". A title like that doesn't mention Git would make me think that GitHub is releasing v2.17 if its own product. I don't think there's a way you can clear this up within the title.
I had raised this issue of demarcation a few days back [0].
As a newcomer to git a few years back I wasn't able to tell if github is a part of git or not OR can you work with git without a github account. It was confusing to me as github allows some of the exact functionalities offered by git.
The post itself is informative. But the title is deliberately confusing. This is not the release announcement. We should not let GitHub take over the Git brand like they try to do with blog posts like this one.
Most coders these days say they use git while in reality the have no clue how it works and how to use it. They just use the buttons of tools and services built on top of it and hope for the best. We would all win if we could collaborate via the nice functionality Git itself provides.
I would have an aneurysm if one of my coworkers or teammates didn’t know how to use git. The documentation is widely available, there are exactly zero excuses available.
Like a product manager? You think it's reasonable to understand all the nuances and capabilities of an obtuse CLI tool that manages concurrent history? What you probably mean is the simplified concepts of Git without the capabilities to alter the interaction effects. You come off as the typical condescending developer who secretly looks down on people with different interests and responsibilities because they don't understand YOUR JOB.
> We should not let GitHub take over the Git brand like they try to do with blog posts like this one.
Is there a similar blog post by the actual git team sharing this information? If so, let's link to that - but as I am not aware of one, I do appreciate github's git release announcements because they are typically a much easier way to learn about new git features than reading the entire release emails [0]
I was going to say that just from the title, they're not really representing themselves as being git, but then in the body of the post, they actually use "us" to refer to git
> Git v2.16 adds a new fsmonitor hook that relies on the operating system to tell us what has changed. Doing so allows us to avoid the repeated stat()
I just wanted to add as another Git developer (with patches in this release and others) and with no affiliation with GitHub, that this skepticism of their motives that's taking up 1/2 the comments here is entirely unwarranted.
I think it's also much better for a general audience like HN to link to these summary posts made by GitHub, Bitbucket and others than to the official release notes.
The official release notes are quite terse, and much too long for someone who just wants a quick summary without getting into all the obscure details. They're also mostly ordered in whatever order Junio happened to integrate the patches, not by some order of importance or user-visibility. They also never show practical examples of how the feature can be used.
Something I've seen in Github but not in Git is how in a red/green line, the individual changed characters are a brighter red/green than the rest. Is it possible to get that in CLUI git?
Here is a workflow I use often that I'm amazed isn't supported on Github: First I run `git log path/to/file` to see the commits for just that file. Then in a separate window I start copy/pasting SHAs to see the whole file at each commit: `git show abc123:path/to/file` ... `git show def456:path/tofile` ... etc. It's a little tedious, but it can really help to see what's going on.
It would be so much easier to do this in a browser with links and a back/forward button! In Github I can see the history of a single file, e.g. at https://github.com/pjungwir/topiary/commits/master/lib/topia... But from there I can't see that file at each commit. (Instead there are two links that both show me the commit's full diff, and another link back to the root of the repo.) I wish there were an easy way I could just browse forward and back, keeping the current file! Am I missing something?
49 comments
[ 2.8 ms ] story [ 87.9 ms ] thread[1]: https://blog.github.com/2016-11-29-git-2-11-has-been-release... [2]: https://blog.github.com/2017-05-10-git-2-13-has-been-release...
They are, after all, a major actor of the git ecosystem, with a great track record, using quality blog posts to inform your of their main tech.
I see zero problem with this.
They are all free, they all help users.
git and github has helped me, and ive never paid. I consider all of this fantastic.
And, given their line of work, it would be kind of surprising if the GitHub blog didn't cover recent Git developments.
- Git 2.17 is now available (gitlab.com)
- Git 2.17 is now available (bitbucket.com)
The point is, by publishing this kind of posts, Github is making you associate git with Github. Anecdote example: my university lecturer calls Github APIs "git APIs". While that might not be a bad thing, it blurs the boundary between an open source project and a company.
I can already imagine Github having influence on the direction of git project and becomes the de facto owner, and the impact on its competitors and the repository hosting industry. The equivalence would be Microsoft, instead of owning TypeScript, owns the ECMAScript specification.
No, not at all.
>The point is, by publishing this kind of posts, Github is making you associate git with Github
Well, git IS associated with GitHub. It's the de facto #1 hosting service for Git repositories, eclipsing all others, and the #1 host of open source git repos. They're also major contributors to Git.
But regardless of all that, they host git repos. They literally work with people that use Git, day in, day out, and help them host their git managed code.
Of course they'll cover developments in Git. Who else would be more natural to cover them (aside something like "Git planet")? The GTK+ blog? The IEEE?
I had to explain there's a quite big difference between the two. I assume he had mixed up github with git and correctly deduced bitbucket is an alternative to github.
Also, I got way too excited over the git news to notice that it was github publishing ...
I've tried to make the Git vs GitHub distinction clear in the first paragraph without belaboring it, but I agree with the sentiment here that the title muddies things. For future iterations I'll look into something more like "A look at the new features in v2.17".
I think that keeps it clear but without making it overtly look like a release announcement.
As a newcomer to git a few years back I wasn't able to tell if github is a part of git or not OR can you work with git without a github account. It was confusing to me as github allows some of the exact functionalities offered by git.
[0] https://news.ycombinator.com/item?id=16600666
https://issues.jenkins-ci.org/browse/JENKINS-50573
https://public-inbox.org/git/xmqq6059z9kz.fsf@gitster-ct.c.g...
Most coders these days say they use git while in reality the have no clue how it works and how to use it. They just use the buttons of tools and services built on top of it and hope for the best. We would all win if we could collaborate via the nice functionality Git itself provides.
Come on, seriously? Where do you work?
I did see many who use git via say sourcetree, they do just click button to push and pull .. and they dont know much more
I dont think this is bad though
I mean, that is true whether they're using GUIs on top of git or git's actual CLI.
Is there a similar blog post by the actual git team sharing this information? If so, let's link to that - but as I am not aware of one, I do appreciate github's git release announcements because they are typically a much easier way to learn about new git features than reading the entire release emails [0]
[0]: https://www.mail-archive.com/git@vger.kernel.org/msg145986.h...
Peff is a member of the Core Git team and is primarily working on open source git.
> Git v2.16 adds a new fsmonitor hook that relies on the operating system to tell us what has changed. Doing so allows us to avoid the repeated stat()
The `--color-moved` one for example can be toggled on with `git config --global diff.colorMoved default`.
I think it's also much better for a general audience like HN to link to these summary posts made by GitHub, Bitbucket and others than to the official release notes.
The official release notes are quite terse, and much too long for someone who just wants a quick summary without getting into all the obscure details. They're also mostly ordered in whatever order Junio happened to integrate the patches, not by some order of importance or user-visibility. They also never show practical examples of how the feature can be used.
Something I've seen in Github but not in Git is how in a red/green line, the individual changed characters are a brighter red/green than the rest. Is it possible to get that in CLUI git?
Here is a workflow I use often that I'm amazed isn't supported on Github: First I run `git log path/to/file` to see the commits for just that file. Then in a separate window I start copy/pasting SHAs to see the whole file at each commit: `git show abc123:path/to/file` ... `git show def456:path/tofile` ... etc. It's a little tedious, but it can really help to see what's going on.
It would be so much easier to do this in a browser with links and a back/forward button! In Github I can see the history of a single file, e.g. at https://github.com/pjungwir/topiary/commits/master/lib/topia... But from there I can't see that file at each commit. (Instead there are two links that both show me the commit's full diff, and another link back to the root of the repo.) I wish there were an easy way I could just browse forward and back, keeping the current file! Am I missing something?
https://github.com/git/git/tree/master/contrib/diff-highligh...