Junio Hamano, the maintainer of Git, writes about Git releases, security fixes, and behavior changes such as push defaults.
HN commenters recommend following it to track Git changes and cite its post on the 2014 release that fixed a security hole in HFS+ handling.
>Any reasons (beyond PR) that these highlights are posted on the blog of GitHub instead of on the main website of Git itself?
Probably the most obvious reason is that author Taylor Blau is employed by Github. If Github funds his work on Git, it doesn't seem strange at all that he posts on his employer's website.
Also, if you're referring to "git-scm.com" as the "main website of Git", there may be practical reasons such as TB not having any authoring privileges there to write a blog type of post. I notice that Git contributor Junio C Hamano who wrote the Git release notes doesn't post blog articles there either. JCH's blog-style posts seem to be at a different url: https://git-blame.blogspot.com/
You didn't ask but a related question people wonder about is why HN users (such as ossusermivami in this thread's case) submit Github links more often than the Git mailing list release notes: https://news.ycombinator.com/item?id=28207811
Concerning "SHA-1 attack" and "Random GIT modifications"
http://osdir.com/ml/version-control.git/2005-06/msg00583.html
But seriously, if anything had been done thousands of people would have known by now.
"just append some commits to any repository"
People will notice that immediately.
The simple fact of the matter is that due to a combination of both Git's technical attributes and the Linux kernel development organization/practices, we are quite safe. This was addressed last time this topic came up, I feel you should probably read some of the responses you got that time.
If you still want to be concerned, I advise addressing this: http://git-blame.blogspot.com/2011/08/how-to-inject-malicious-commit-to-git.html
A topic branch workflow is tremendously useful even without separate people in the "developer" and "integrator" roles. For example, we have about 20 people regularly developing code and about five of us "integrate", first to 'next', then to 'master' when a feature has stabilized. We don't explicitly pass an integrator token so there is a possible race to the integration branch, but since we only merge there, it's actually pretty rare in practice. If you lose the race, the polite thing to do is discard your old merge, fast-forward, and repeat the merge. This preserves first-parent.
http://git-blame.blogspot.com/2012/03/fun-with-first-parent.html
> ...this is solved by the named branches in Mercurial...
I'm not super-familiar with Mercurial (and only somewhat-familiar with git), but couldn't you get the same effect as named branches by just not deleting fully merged branches in git?
> ... how can you tell which one of the parents is the previous commit in the master ...
You can use --first-parent [1] to disambiguate that. In a nutshell, the master branch in your example would be the first parent, letting you disambiguate (and there's support for this in a lot of other git tools!)
[1]: https://git-blame.blogspot.ca/2012/03/fun-with-first-parent.html
"Otherwise, an unsuspecting user can run git pull from an innocuous-looking-but-malicious repository and have the meta-information in her repository overwritten, or executable hooks installed by the owner of that repository she pulled from (i.e. an attacker)." [1]
You could pull down git hooks that root your box, pretty intense hack, update now!
1. http://git-blame.blogspot.com.es/2014/12/git-1856-195-205-214-and-221-and.html
Most pull requests are the url of a repo and the name of a branch. Without a sha1, those aren't tamper-proof.
Another option is to make pull requests for signed tags, which build on GPG trust; or to GPG-sign a pull request email containing a sha1.
- https://lwn.net/Articles/473220/
- http://git-blame.blogspot.com/2012/01/using-signed-tag-in-pull-requests.html