Git 2.10 has been released | Hacker News Reader

Git 2.10 has been released

github.com

205 pointsdwaxe36 comments

Meta: Beautifully written release summary, including hyperlinks and animated gif "demos".

Inspirational for our own releases :-)

Nice formatting aside, I am slightly concerned that GitHub "releasing a release note" for Git would further blur the distinction between the two for new programmers.

If I were new to Git and GitHub, I would have thought that Git is a product of the company GitHub.

Edit: After searching through git repo and official site, I could not find any nicely "rendered" release note beyond the official release note in raw markdown here: https://raw.githubusercontent.com/git/git/master/Documentati... , so I think GitHub is doing us a good thing here by giving a high level summary and actually rendering the markdown properly.

Oh geez, you're giving me flashbacks to trying to introduce Github to non-technical students. I basically just don't even try to explain the difference, because I have them use a minimal set of git's functionality, that is, the subcommands add, commit, and push...and of course, clone and init at the beginning of the quarter.

And I teach them virtually nothing about Github other than that it's a website that you interface with git. For me, Github is a great place to get students to push their assignments and papers because I can easily comment on them...once in awhile I'll do a force push to fix something. We never do anything with forking, and I strongly discourage them from using the Github web interface to edit documents, as that is the most frequent cause of merge conflicts.

If they follow what I say, git and Github are just glorified document-uploading systems. I've almost never had a student fuck up in a way that we had to rollback something, because for the most part, people who don't use version control as their job don't need it. Version control is only particularly relevant when working in a team, doing iterative work, or deploying to multiple environments. These are things that students do not need to worry about.

And actually, even the comsci students don't really need to worry about it.

If I do attempt to explain the difference between git and Github, I usually use the analogy of git is to Github as your cameraphone is to Instagram.

I do corporate trainings on git. Many prospective clients or vendors call me asking for "g.i.t. hub" trainings. Thankfully though, most of these are just the misinformed marketing teams. The engineering people usually grasp the difference easily when I finally reach the parts about collaboration.

I like the cameraphone/instagram analogy. Thanks! I usually do all the pushes/pulls etc. using a file:// remote so that people can see what happens and then just tell them that github is what happens with you move the remote to the cloud and give it a nice UI.

Interesting. Do you get a lot of work training people in git?

It's reduced a little in the past few months. I've increased my rates a little so that I can focus only on direct clients rather than training vendors who need the prices to be low so that they can take a cut.

Also, I think cheaper git trainers have shown up on the market and many people are already familiar with it both of which have reduced the number of requests I get.

If you ever run into this need again, I'd recommend this book: https://launchschool.com/books/git

Thanks. I often have troubles explaining to others the difference between Git and GitHub, and I think the camera phone and Instagram is a nice analogy.

i assume that's at least partly intentional from the github point of view

I recently participated in a focus group which was discussing git, github, and other git-ish things. To my eyes, it seemed like most of the other participants were unclear on what the difference between git and github actually was as answers about the two were often interchanged.

In a more perfect world I would have wanted to see GitHub be stopped at the time of release due to trademark concerns, as they clearly did this knowing it would creat this kind of confusion; it devalues git itself and their business model relies on that.

That's quite an extraordinary claim. Do you have any actual evidence to support it?

To support which claim? That they knew naming their product "GitHub" would lead to this kind of confusion? The opposite of that is the extraordinary claim: it is painfully obvious that if you take someone else's product and name yours "ThatProductHub" you will cause semantic confusion over whether your product is directly affiliated with the other product. I am not even sure what evidence could be provided to refute that claim other than a record of extremely low IQ scores :(. People do this because they want to ride on the coat tails of the other brand, whether they want to admit it or not.

To be fair, I'll point out that you are giving no consideration to the fact that git's popularity is due in part to GitHub's massive success and that the relationship is clearly mutually beneficial.

I find the gifs make the text around them far harder to focus on. I'd much prefer they only played on click or hover.

I'm actually surprised that the browsers don't have gif playback controls by now.

Until relatively recently. You could stop gif animations on a page in firefox. They removed the functionality, citing bloat, and suggested someone write an extension.

Shortly after, they integrated Pocket and Hello and broke the extension apis that would have made a gif control extension easy.

In a desktop: right-click, "show controls". Should work in FF / Chrome.

Showing controls is only possible on <video> tags. This won't work on gifs.

and with humour: > Git's internal date-formatting code can now correctly show dates past the year 2100. Phew, fixed with only 84 years to spare.

Do you know what they might have used to make the gifs?

I use this on OS X and it works great:

https://github.com/vvo/gifify

I tried a lot other services to convert quicktime recording to gif but all of them have color encoding issues.

This works well: https://gist.github.com/dergachev/4627207

it doesn't make a gif but I think it's really nifty to get a similar (better?) effect: https://asciinema.org/

https://github.com/paulguy/asciirec is very nice, and could be helpful but doesn't do gifs directly.

Original announcement with hipster mode off. ;) http://marc.info/?l=git&m=147286906121492&w=2

I just get

  no such message

on that page

https://git-scm.com/docs/git-config has the complete color documentation (find for "magenta" to jump to it).

Here's the release announcement from the people who actually bring you git: https://raw.githubusercontent.com/git/git/master/Documentati...

Interestingly, git-scm.com is still serving Git 2.9.3 right now.

This is great and all, but do status bars and terminal colorings really warrant this kind of fanfare? I love git and I'm very happy that they are constantly releasing new stuff, but I think we should draw a line somewhere on what really matters and what doesn't as far as news coverage.

The news is on github, it specialises in everything git and on the git subject they can choose to shine the light wherever and it will not be out-of-place.

Maybe you could limit the criticism to the fact that it has been submitted to HN and voted onto the front page, which would be a criticism of distribution medium and of the medium consuming masses.

It seems so easy to include a command line option to specify which PEM file to use but git just won't do it.

Yes I know there are ways around it and config files you can set up, but heck, it's just a command line "use this PEM file". It's not hard.

Does anybody really care about the progress meters? Those useless numbers! You can try to tell me you are not stuck every half second or so, but I don't want to see all the noise. I'd rather it not print out anything by default unless I ask for it or it fails.

Why do git developers concern about the colored output? It's completely unrelated to SCM at all. I love the functionality. But it shouldn't be only for git. Can we have a separate utility that reads a diff and gloriously print out the contents, all by itself, and only that?

I really don't want to see git becomes another bloatware.

Use the --quiet flag to turn off most output and don't bother defining any colors if you don't like them. Now git is how you like it. For diffs, try git difftool.

1) The progress meters is important. The scenarios in which this progress meter would matter, would lead to users thinking something strange went wrong and their push did not succeed because of the lack of the progress meters. Besides that, it's a UI manifestation of a bug that would have led to pushes in certain scenarios not working.

2) As long as GIT diff exists, making it more usable should certainly be a core part of changes to GIT diff. There are many utilities you can use for GIT diffs easily enough instead of the base diff. But I like the fact that if I'm at a machine where my preferred utilities are not setup, I still have a very usable diff built into GIT.

Reply on news.ycombinator.com