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.

> 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.

There are many uses for Git notes even though you might use a project management tool. Particularly all those things which are relevant for developers only, or that the developers can use as the data source for "higher-level" goals.

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?

"Pickaxe" most often means those options. But it's also a (apparently legacy) command alias for git-blame.

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 <insert research notes> 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)

I use this to note potential issues in my copy of the Git project. For outright bugs though I report them to the project.

awesome to see a user in the wild! if you weren't aware, you can publish your git-bug issues to the project's issue tracker, assuming that it's on one of the supported bridges today (github, gitlab, jira).

the bridges exist within git-bug to support adoption of the tool and interop with existing platforms.

`git bug bridge pull` and `git bug bridge push` use the bridge's API, and don't attempt to pull from or push to the git remote.

Thanks. I can’t push it to the issue tracker since they don’t have one. Bug reports go to the mailing list.

hrm... what's your current workflow like? if there's anything you think git-bug could be doing to make that workflow easier, would you mind hopping in our matrix channel [1], or opening an issue [2]?

[1]: https://matrix.to/#/#git-bug:matrix.org

[2]: https://github.com/git-bug/git-bug/issues

I create issues for myself. I sometimes create branches with informal issue keys like `<three letters>-<incrementing number>`. I use `git bug webui` to type edit issues. That’s it.

All I would like as a nice-to-have is support for making those issue keys that I use automatic. For me it’s all local to me so it doesn’t need to be globally unique. But those N-letter prefix does make collision less likely on a single project. I’ve mentioned it here: https://github.com/git-bug/git-bug/issues/75#issuecomment-19...

I’ve just used it two times in the last few months. One was to track down a commit which triggered a bug I found in Git. I wouldn’t be able to troubleshoot it myself. And I couldn’t send the whole repository because it’s not OSS. But with a script to reproduce the bug and half an hour I was able to find the problematic change.

I also tried to make a minimal reproduction but wasn’t able to.

Here’s the most relevant (to me) difference:

- The real unit of change lives in Git

- The real unit of change lives on some forge

I want it to live in Git.

They are the same if you use squash merge.

modulo the commit message, which github apparently takes a lot of effort to not surface when needed; the most egregious example is that it's a complete afterthought to fill out right before the 'squash and merge' button becomes green.

You can make the PR description the commit message through configuration.

This is an active fork: https://github.com/dathere/qsv

Never realized it was a fork. qsv is great. I parsed lots of 4Gb files with it and was really happy.

There's also DSQ which uses SQL instead of its own language. https://github.com/multiprocessio/dsq

The Git project has a script for that: https://github.com/git/git/blob/master/contrib/contacts/git-...