Junio Hamano
git-blame.blogspot.com · Personal blog · on HN since 2011
Junio Hamano, the maintainer of Git, writes about Git releases, security fixes, and behavior changes such as push defaults.
What HN saysHN commenters recommend following it to track Git changes and cite its post on the 2014 release that fixed a security hole in HFS+ handling.
24HN people shared it
10linked it in comments
15stories submitted
60story points
5 years agolast shared
2011people per year2026
Most-shared posts
- 1How to inject a malicious commit to a Git repository (or not)2 people · 4 points · first shared 2011 · discussion on HN
- 2Using signed tags in git pull requests2 people · 2 points · first shared 2012 · discussion on HN
- 3Fun with Git's --first-parent2 people · 2 points · first shared 2012 · discussion on HN
- 4CVE-2014-9390 (2014)2 people · 1 points · first shared 2015 · discussion on HN
- 5Homepage2 people · first shared 2013
- 6Git 1856 195 205 214 and 221 and2 people · first shared 2014
- 7Git 1.8.0 released1 people · 22 points · first shared 2012 · 1 comments on HN
- 8Git to change default push behavior.1 people · 8 points · first shared 2012 · discussion on HN
- 9Git to mandate users explain their merges explicitly in 1.7.101 people · 7 points · first shared 2012 · 2 comments on HN
- 10Git 1.8.0 released1 people · 3 points · first shared 2012 · discussion on HN
- 11Fun with first parent history1 people · 2 points · first shared 2013 · discussion on HN
- 12Where do evil merges come from?1 people · 2 points · first shared 2013 · discussion on HN
- 13Git 1.8.0 released1 people · 2 points · first shared 2012 · discussion on HN
- 14Git 2.51 people · 2 points · first shared 2015 · 2 comments on HN
- 15Measuring Project Activities (1) - Git Blame1 people · 1 points · first shared 2013 · discussion on HN
What HN people wrote when they linked it
saidajigumi · 2013-11-02
It's worth following Junio Hamano's Git Blame blog[1] to keep up with changes in git of this ilk. This particular item is old news in that regard, and a very welcome change at that.
[1] http://git-blame.blogspot.com/
jasode · 2022-01-25
>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
turaw · 2016-05-26
> ...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
tshtf · 2016-05-20
Ignorable (invisible) unicode characters have caused security vulnerabilities in the past, especially on HFS+ filesystems running on OS X (due to normalization):
* https://git-blame.blogspot.com.es/2014/12/git-1856-195-205-214-and-221…
* https://www.cvedetails.com/cve/CVE-2013-0966/
thomasfromcdnjs · 2014-12-18
"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-…
jedbrown · 2013-04-30
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
wfarr · 2012-08-12
It's a fairly recent addition to git (January 2012). You need at least version 1.7.9 to use credential caching. [1]
[1]: http://git-blame.blogspot.com/2012/01/git-179.html
Tobu · 2012-03-16
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-request…
davvid · 2011-09-25
Junio (git's maintainer) was using a hook to pre-generate html documentation and manpages. These would get committed to "html" and "man" branches so that others could check them out without needing to have the asciidoc tools installed.
http://git-blame.blogspot.com/2011/09/return-of-htmlman-branches.html
burgerbrain · 2011-09-03
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-t…