New features from the last few versions of Git | Hacker News Reader

New features from the last few versions of Git

blog.github.com

107 pointsfanf248 comments

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.

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

[0]: https://www.mail-archive.com/git@vger.kernel.org/msg145986.h...

> Is there a similar blog post by the actual git team sharing this information?

Peff is a member of the Core Git team and is primarily working on open source git.

OK, we've changed the title to a representative phrase from the first paragraph.

> Most coders these days say they use git while in reality the have no clue how it works and how to use it.

I mean, that is true whether they're using GUIs on top of git or git's actual CLI.

> Most coders these days say they use git while in reality the have no clue how it works and how to use it

Come on, seriously? Where do you work?

I know right?! What kind of response is that?

I cant tell if this serious or sarcastic

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

The original comment was referring to coders. It's not a lot to ask people who are working on code to know how to use basic git commands.

Dude that’s a total overreaction. I was referring to software engineers. Why would a product manager need to know how to use rebase or bisect?

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()

arent't they using "us" to refer to "us, the programmer using git" as in "...to tell us, the user of git, what has changed"?

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.

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

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.

Out of curiosity, would you be surprised by:

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

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.

Okay. I guess if you say so then I was just being paranoid and overreacting.

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.

Which was one of the top 3 reasons I chose to host my projects on GitLab instead of GitHub. Thank you for supporting OSS by being OSS yourself!

You're welcome. Thanks for using GitLab. BTW We refer to ourselves as an open core company since we also sell proprietary features.

>Out of curiosity, would you be surprised by

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?

Try "Git 2.9 is out!": https://blog.bitbucket.org/2016/06/13/git-2-9/

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.

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

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.

Er, sorry, I meant to say "...the new features in Git v2.17".

I think that keeps it clear but without making it overtly look like a release announcement.

Ok, I think that does actually make things a bit more clear. Thanks for writing these up, by the way!

It's a sane marketing strategy, let's not blame them for this.

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.

I run a few websites, and you bet that each of them will give shutouts to each other.

They are all free, they all help users.

git and github has helped me, and ive never paid. I consider all of this fantastic.

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.

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.

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.

[0] https://news.ycombinator.com/item?id=16600666

It does happen. When we were hiring a couple years back, some candidates seemed to be confusing the two or thought that git was a product of GitHub.

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.

The --color-moved feature sounds really nice!

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?

Try the diff-highlight script which can be found at:

https://github.com/git/git/tree/master/contrib/diff-highligh...

Please use the original announcement https://marc.info/?l=git&m=152270220826214&w=2 (or change the title to something else such as "Some interesting new features of git 2.17")

To be fair, the original announcement you linked is unreadable.

Slightly more readable copy (from the official archive):

https://public-inbox.org/git/xmqq6059z9kz.fsf@gitster-ct.c.g...

Please use the original title.

I see it's been updated. Thanks!

Warning for anyone using Git 2.17 on Windows with Jenkins

https://issues.jenkins-ci.org/browse/JENKINS-50573

I'll never be able to remember all of these new flags they add in. Too bad all these nifty features are all "opt-in".

With git it's usually possible to set your config file to enable a given feature by default, unless you override it with a flag.

The `--color-moved` one for example can be toggled on with `git config --global diff.colorMoved default`.

Thanks for the article, I've just learned many options I didn't know !

Reply on news.ycombinator.com