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

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

#121

Post by fudged71 » Mon, Jun 23, 2025, 6:15 AM UTC

rpicard wrote: post #116

This would be a cool place for LLMs to store a summary of the prompts used to generate the code in order to make it easier for other LLMs and humans to pick up where they left off.

I've been thinking about this exact same problem. It would be great to store a log of how much time/tokens were spent reasoning, what was the reasoning path, why were certain decisions made, etc.

I don't know if rationale is something better suited for the git commit log, or tagged by code function to an external "rationale" system of record.

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

#122

Post by lrvick » Mon, Jun 23, 2025, 6:46 AM UTC

A few years ago I wrote a simple git "extension" that allows you to attach signatures to existing git commits, and allow for verification that a minimum number of signatures from relevant teams exist. This is possible because Git Notes allow you to attach and distribute arbitrary metadata with any commit ref.

https://git.distrust.co/public/git-sig

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

#123

Post by phatskat » Mon, Jun 23, 2025, 6:48 AM UTC

hxtk wrote: post #114

naiquevin wrote: post #112

Earlier quoted context omitted.

Gerrit uses a “Change-Id” trailer with a unique value. When you “fix up” a commit, the commit SHA changes but the change id remains the same. That’s how it can identify different commits with the same change id as patchsets of the same change. This is based on what I remember (haven’t used gerrit in a while), so it may not be accurate. I used gerrit in my previous job and miss using it. Would definitely prefer it ove…

Your understanding of the Change-Id footer sounds like it matches mine. I’d note that it works that way presently, but the teams behind git, gerrit, jj-vcs, and a couple of other relevant stakeholders have an email thread going in which, from what I understand, they discuss standardizing on the approach taken by jj-vcs: https://lore.kernel.org/git/CAESOdVAspxUJKGAA58i0tvks4ZOfoGf...

I’ve really enjoyed jj and im happy to see the community working together on these kinds of things.

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

#124

Post by chrishill89 » Mon, Jun 23, 2025, 7:39 AM UTC

I use Git Notes all the time. It doesn’t look like the article mentions that you can attach the notes to emails you send out with git-format-patch(1) and git-send-email(1). I use them for emails to attach comments on patches that shouldn’t go into the commit message:

    I did  and found no other places in the code base where this needs to be fixed.

And as the cover letter for a single patch (if needed/not cowered by the commit message).

And also like a commit message on the iterations on the patches. So for a patch series that go over three versions the note may say what updates where done in versions 2 and 3.

And other than that I use notes for:

- Private notes on how I’ve manually tested the commit

- Link to CI

- A localized changelog for customers (who are not technical)

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

#125

Post by imiric » Mon, Jun 23, 2025, 8:18 AM UTC

chuckadams wrote: post #104

imiric wrote: post #50

Earlier quoted context omitted.

Interesting, I wasn't familiar with this feature. I'm a big fan of conventional commits, and trailers seem like a better way of adding such metadata. Is adding them manually to the commit message functionally equivalent to using the `--trailer` flag?

I like the idea of conventional commits, but the lack of many useful categories is a real `chore:` to where I end up making my own, which tooling of course doesn’t recognize. The codification of something called conventional commits strikes me as kind of counterintuitive anyway.

Well, they're just commonly used commit types. I don't follow the "spec" strictly and have my own conventions as well. I don't use any tooling that reads them, and I'd probably write my own if needed.

I mainly find them helpful for sticking to atomic commits. If a change doesn't align with the commit type, or it touches too many parts of the codebase, that means it should be in a separate commit.

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

#126

Post by Pxtl » Mon, Jun 23, 2025, 12:43 PM UTC

hinkley wrote: post #74

Pxtl wrote: post #36

Earlier quoted context omitted.

The history-destroying problems of rebasing are a rant on their own.

Can you say more? I use rebase to avoid history destruction/obscuration. Do you mean squash? If so then I agree.

Basically, the fact that any kind of tweaking to the history in terms of comments or grouping together related commits into a single commit changes the hashes. This means that git's normally useful ability to check "hey is commit X in the history of both branches A and B" is broken.

That's a huge usability problem with git. Even as simple as a "rebase on merge" or "squash on merge" automation makes it impractical to push your topic-branch and keep working locally on that same branch while your topic-branch is being reviewed and tested, because git doesn't retain any concept of the fact that "this block of commits has been transformed into that block of commits and so you can consider them one-and-the-same".

I'm the git sme at my office and I deeply resent the amount of time I have to spent training juniors and students around git's jagged edges.

Ideally git should have a proper in-repo objects that reify a relationship between rebased/squashed/amended/etc commits and their predecessors and exposes that when you ask things like "hey is commit X in ref Y?" it could say "no, but there is a modified version of that commit".

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

#127

Post by Pxtl » Mon, Jun 23, 2025, 12:55 PM UTC

saghm wrote: post #110

Pxtl wrote: post #36

Earlier quoted context omitted.

The history-destroying problems of rebasing are a rant on their own.

I don't think I agree with this take, at least not completely. I tend to commit quite frequently when working on a feature branch in ways that wouldn't be desirable to include in the history of the main development branch, and I take advantage of the fact that rebase lets me clean everything up beforehand into whatever commits I actually want afterwards (which I usually do two separate times, once before opening a re…

My problem is that so many of git's features feel like they just aren't designed to accommodate history rewriting.

Like if I have branch X and branch Y, and X is 1 commit ahead of Y, but I alter the comment of a commit in Y, now X is one or more commits behind Y and will not recognize identical code-changes as identical.

It gets worse if you squash a commit, where you start getting conflicts during merges and rebases even though the code-changes are the same.

I understand why these problems happen, and the ways to prevent it (don't rebase anything pushed), but it still underscores the fact that git doesn't properly accommodate its own love of rewriting history.

If git had a proper synced graph of history-rewriting actions (commit A was rewritten into commit B) then it would be able to provide better responses when doing a merge or reflist across rewritten branches.

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

#128

Post by Pxtl » Mon, Jun 23, 2025, 12:59 PM UTC

Zambyte wrote: post #51

Pxtl wrote: post #36

Earlier quoted context omitted.

The history-destroying problems of rebasing are a rant on their own.

That's a UI problem with git making it hard to find hidden commits (pre-rebase). The commits aren't destroyed, they are hidden. The Jujutsu CLI is nice because it fixes this UI problem.

Not only that. Git doesn't appear to have any internal link between the hidden pre-rebase commits and the post-rebase commits, which hurts its ability to copy later commits across that rebase.

Yes, you're supposed to avoid moving later commits across a rebase... but the reason you're supposed to avoid that is because git is so bad at it.

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

#129

Post by saghm » Mon, Jun 23, 2025, 3:05 PM UTC

GuB-42 wrote: post #113

saghm wrote: post #110

Earlier quoted context omitted.

I don't think I agree with this take, at least not completely. I tend to commit quite frequently when working on a feature branch in ways that wouldn't be desirable to include in the history of the main development branch, and I take advantage of the fact that rebase lets me clean everything up beforehand into whatever commits I actually want afterwards (which I usually do two separate times, once before opening a re…

You do whatever you want on your own repository, but as soon as you make anything public, for me, it is here to stay, I consider every push to be pulled by someone else, and if you rebase or do anything to change your history, you have just created a new branch, even if you pretend it doesn't exist anymore using a push --force. Git is a decentralized version control system. It is effectively a blockchain like Bitcoin…

I guess we just fundamentally disagree with how using git should work. I don't agree at all that using git for a public repo somehow implies that you're committing to preserving every single branch in perpetuity just because the tool can support it. If it's confusing, I'd argue it's from mistakenly inferring that others are conveying intent by publishing public feature branches.

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

#130

Post by saghm » Mon, Jun 23, 2025, 3:13 PM UTC

Pxtl wrote: post #127

saghm wrote: post #110

Earlier quoted context omitted.

I don't think I agree with this take, at least not completely. I tend to commit quite frequently when working on a feature branch in ways that wouldn't be desirable to include in the history of the main development branch, and I take advantage of the fact that rebase lets me clean everything up beforehand into whatever commits I actually want afterwards (which I usually do two separate times, once before opening a re…

My problem is that so many of git's features feel like they just aren't designed to accommodate history rewriting. Like if I have branch X and branch Y, and X is 1 commit ahead of Y, but I alter the comment of a commit in Y, now X is one or more commits behind Y and will not recognize identical code-changes as identical. It gets worse if you squash a commit, where you start getting conflicts during merges and rebases…

Yep, I don't disagree with you about that. To me, the cost of having to stick with a workflow that prevents it (which you describe) is still worth it to have a clean history without merge commits, but I totally understand that this is a matter of personal preference, and having a consistent workflow for everyone working on a project together matters more. Right now, I'm working on a team that uses merge commits for the first time in a while, and it's definitely taking a bit of time to get used to again, but I'm still committing to it (pun intended!)