[_flux]

I used git notes for marking which of my commits in my branch I had run the unit tests for (and thus my script would skip those). This was useful when working with open source upstream where you want the massage the branch to perfection with git rebase -i.

It seems git trailers would now be the better place to put that information.

Regarding change ids: I wish git itself had those, as then also the tooling would understand them. Identifying commits by their commit messages is fragile, in particular when you may update those for an MR. While commit id truly identifies the commit in a unique way, it is not a useful identifier when the same changes could be moved on top of some other commit.

edit: Oh it looks like they are actually part of the commit, whereas notes aren't, so it wouldn't be a good replacement for my use.

[masklinn]

> Regarding change ids: I wish git itself had those, as then also the tooling would understand them. Identifying commits by their commit messages is fragile, in particular when you may update those for an MR. While commit id truly identifies the commit in a unique way, it is not a useful identifier when the same changes could be moved on top of some other commit.

Projects for which mutable changes are a unit of work are working on standardising that: https://lore.kernel.org/git/CAESOdVAspxUJKGAA58i0tvks4ZOfoGf...

They don't need git support, but it might eventually become first-class.

[arxanas]

One trick for running tests in rebase-heavy workflows is to use the tree hash of the commit as the cache key, rather than attach metadata the commit itself.

- That way, tests will be skipped when the contents of the commit are the same, while remaining insensitive to things like changes to the commit message or squashes.

- But they'll re-run in situations like reordering commits (for just the reordered range, and then the cache will work again for any unchanged commits after that). I think that's important because notes will follow the commits around as they're rewritten, even if the logical contents are now different due to reordering? Amending a commit or squashing two non-adjacent commits may also have unexpected behavior if it merges the notes from both sides and fails to invalidate the cache?

- This is how my `git test` command works https://github.com/arxanas/git-branchless/wiki/Command:-git-...

---

I've also seen use-cases might prefer to use/add other things to the cache key:

- The commit message: my most recent workflow involves embedding certain test commands in the message, so I actually do want to re-run the tests when the test commands change.

- The patch ID: if you specifically don't want to re-run tests when you rebase/merge with the main branch, or otherwise reorder commits.

Unfortunately, I don't have a good solution for those at present.

[_flux]

In my case I wanted to invalidate the notes when rearranging commits, because changing order could introduce bugs, but also have a single command that ensures that all my commits are tested before sending pull request. I think maybe it used to work that way (remove notes upon rebasing) out of the box that time, but if not, then I suspect I simply added the git commit id to the note, which can be effectively used for validity checking.

Of course, if the notes mechanism didn't exist, then I could have just used a local file.. But it's nice to see the messages in the git log.

But yeah, both kinds of keys would be useful for this purpose, depending on the exact needs.