Git Notes: Git's coolest, most unloved feature (2022) • Hacker News Board

Re: Git Notes: Git's coolest, most unloved feature (2022)

#141

Post by ozim » Mon, Jun 23, 2025, 9:13 PM UTC

chrishill89 wrote: post #134

ozim wrote: post #102

It is not coolest most unloved feature. It is a gimmick feature that could have been cool in some really specific cases like team of only developers running the whole company. Whatever is needed goes into commit message and referencing tickets in separate system is a feature not a bug - because JIRA or any other system is used to communicate with non developers. Like business analysts don't get access to code or repo…

There’s plenty of data which is extra-commit (doesn’t belong in the commit messages but is relevant). Like if the tests passed[1], manual testing notes, iteration on code review, notes for code spelunking when you find a problematic 6+ month old commit. [^1] https://news.ycombinator.com/item?id=44348438

Yeah but GIT notes are not the best tool for that unless you are single dev working on your project or you have team of only devs.

If you have manual testers they have their own set of tools and most of them don’t use or have working knowledge of GIT.

For code reviews everyone is using PRs and it is not because they don’t know about GIT notes but because no one is doing reviews per commit and there is no support for discussion and other tools that are baked in forges PR flows.

You can always use git notes for yourself but it is as I called it gimmick feature. I can make a bet you will use it for a week maybe couple weeks and then just stop because in description it sounds good but in practice - no one is using it.

Re: Git Notes: Git's coolest, most unloved feature (2022)

#142

Post by steve_adams_86 » Mon, Jun 23, 2025, 10:06 PM UTC

raju wrote: post #94

steve_adams_86 wrote: post #72

Earlier quoted context omitted.

Ha, I expected to know the features you were going to list, but got surprise attacked by pickaxe. What the hell? I guess I shouldn’t be so confident

pickaxe isn't a Git command, rather, it's a set of flags that `git log` offers (specifically `-S` and `-G`). Shameless plug: I recently did a webinar on how the pickaxe options are better than `git-blame`) that you can find here: https://nofluffjuststuff.com/webinar/142/level_up_your_git_g... (Note: It requires you to provide an email address).

Yes, this makes more sense now. Unfortunately I was already a heavy user of log, so then only new part is the term used for the flags. Somehow I've never seen it before

Re: Git Notes: Git's coolest, most unloved feature (2022)

#143

Post by cma » Tue, Jun 24, 2025, 12:07 AM UTC

Zambyte wrote: post #107

hinkley wrote: post #73

Earlier quoted context omitted.

You’re treating a commit as an atom, which is not true in patch based git situations like Linux. Most of the rest of us do not work this way, but they still do. The rest of us also only have to deal with three way merges most of the time, instead of octopus merges. Though I jokingly call, “fixing an incorrect three way merge” a “five way merge” because you end up doing a star shaped pattern of diffs to re-resolve the…

I'm not really sure what you mean by this. Git treats commits as atomic (unchangeable), and thus they are atoms (indivisible). This is not really related to patches, unless you're referring to partially applying patch series. Can you elaborate on what you mean?

Does the commit message itself affect the hash or is it separate and outside of the main system, like tags?

Re: Git Notes: Git's coolest, most unloved feature (2022)

#144

Post by chrishill89 » Tue, Jun 24, 2025, 7:17 AM UTC

ozim wrote: post #141

chrishill89 wrote: post #134

Earlier quoted context omitted.

There’s plenty of data which is extra-commit (doesn’t belong in the commit messages but is relevant). Like if the tests passed[1], manual testing notes, iteration on code review, notes for code spelunking when you find a problematic 6+ month old commit. [^1] https://news.ycombinator.com/item?id=44348438

Yeah but GIT notes are not the best tool for that unless you are single dev working on your project or you have team of only devs. If you have manual testers they have their own set of tools and most of them don’t use or have working knowledge of GIT. For code reviews everyone is using PRs and it is not because they don’t know about GIT notes but because no one is doing reviews per commit and there is no support for…

> You can always use git notes for yourself but it is as I called it gimmick feature. I can make a bet you will use it for a week maybe couple weeks and then just stop because in description it sounds good but in practice - no one is using it.

I'll take that bet.

Re: Git Notes: Git's coolest, most unloved feature (2022)

#145

Post by Zambyte » Tue, Jun 24, 2025, 12:12 PM UTC

cma wrote: post #143

Zambyte wrote: post #107

Earlier quoted context omitted.

I'm not really sure what you mean by this. Git treats commits as atomic (unchangeable), and thus they are atoms (indivisible). This is not really related to patches, unless you're referring to partially applying patch series. Can you elaborate on what you mean?

Does the commit message itself affect the hash or is it separate and outside of the main system, like tags?

The commit message affects the hash.

Re: Git Notes: Git's coolest, most unloved feature (2022)

#146

Post by fnl » Wed, Jun 25, 2025, 8:30 PM UTC

chrishill89 wrote: post #132

rlpb wrote: post #90

Earlier quoted context omitted.

> Are git rebase etc smart enough to also copy over the notes to the new commit... This is configurable. By default, amend and rebase operations will copy them forward. See git-config(1) under `notes.rewrite`.

By default no copying will be done. While `notes.rewrite.amend` and `notes.rewrite.rebase` are true you also need `notes.rewriteRef` which tells it what notes refs should be rewritten. And it has no value by default. (you can set it to a glob copy over all notes refs)

Thanks for the warning! From the git docs:

> Set it to refs/notes/commits to enable rewriting for the default commit notes.

Why wouldn’t that at least be the default? Why is rewriting off by default in the first place?

Re: Git Notes: Git's coolest, most unloved feature (2022)

#147

Post by stopthe » Fri, Jun 27, 2025, 3:00 PM UTC

ozim wrote: post #140

stopthe wrote: post #103

Earlier quoted context omitted.

> business analysts don't get access to code or repositories at all for example or support people don't get access to the repositories and code. Yes, but isn't it insane? What is the benefit from treating your own product as a black box? Yet that's mainstream. Sometimes I have the analyst (not on my team, but from a team we share a monorepo with) asking me questions that can be answered literally with a line of code.…

I think you underestimate inefficiency of requiring all business analysts and employees to learn GIT. If not all employees than more employees. I can pick put up job ad for BA saying knows JIRA and I have dozens of applicants. We had a technical guy once where I worked that wanted to force sales guys to use LaTex to write documentation and requirements in and store it in GIT. I feel bad for the guy as he was laughed…

OTH the inefficiency of an analyst who cannot answer even basic questions about the current state of the product without developers' help. Distracting them, or even worse - blocking until a dev is available.

I think it boils down to the power of balance in the org. Likewise I've met developers who cannot book a meeting. Some people have privilege to choose what to learn and what to laugh at. Actually, I'm surprised your sales guys wrote any documentation at all:)