Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

tylercipriani.com

Post reply on HN
Print view View original

111–120 of 147 posts

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

#111

Post by angus-g »

cmrdporcupine wrote: post #99
hxtk wrote: post #95

Earlier quoted context omitted.

GitLab is actively developing native support for stacked diff workflows. CLI support for creating stacks landed in GitLab 17, and now they’re working on the code review workflow for it. To be honest, though, I find it easiest to create several branches with Jujutsu and then manually chain the MRs. That’s what glab does under the hood with glab stack commands. Looking forward to the code review tools in a future versi…

Putting stacked diffs aside, I'd frankly just be happy with the ability to track comments across different commit hashes. This is something neither GitLab or GitHub can do: 1. "Please change this" 2. 3. Comment keeps association with the original line and/or its new replacement. Gerrit has no problem w/ this flow. GH and GL both can't do it. GH wants to force you to put a pile of "fix" commits in and then either do a…

How does Gerrit manage this? Are the comments associated with the source content, instead of commits?

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

#112

Post by naiquevin »

angus-g wrote: post #111
cmrdporcupine wrote: post #99

Earlier quoted context omitted.

Putting stacked diffs aside, I'd frankly just be happy with the ability to track comments across different commit hashes. This is something neither GitLab or GitHub can do: 1. "Please change this" 2. 3. Comment keeps association with the original line and/or its new replacement. Gerrit has no problem w/ this flow. GH and GL both can't do it. GH wants to force you to put a pile of "fix" commits in and then either do a…

How does Gerrit manage this? Are the comments associated with the source content, instead of commits?

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 over GitHub which is more popular (and convenient of course, can’t deny that).

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

#113

Post by GuB-42 »

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…

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 but without the consensus mechanism, and just like transactions are final on the Bitcoin network, pushed commits are final in git. You can agree to use one branch over another, but if you are using git as designed (i.e. as a decentralized system), it can be confusing. Merge commits are how you can resolve that confusion.

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

#114

Post by hxtk »

naiquevin wrote: post #112
angus-g wrote: post #111

Earlier quoted context omitted.

How does Gerrit manage this? Are the comments associated with the source content, instead of commits?

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

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

#115

Post by GuB-42 »

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.

Rebase creates an entire new branch and drops the previous one, it is a form of history destruction.

Commits are actually snapshots of the entire repository, not just diffs, so even if the diff is the same, if the base is different, it is not the same commit. And when you rebase, all the old commits will stay there until you run the garbage collector, and only if they don't have a head.

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

#117

Post by 57473m3n7Fur7h3 »

jacques_chester wrote: post #75
oftenwrong wrote: post #12

Earlier quoted context omitted.

One more similar feature from a different system: PostgreSQL COMMENT https://www.postgresql.org/docs/17/sql-comment.html This allows you to attach text to various database objects in PostgreSQL. I wish PostgreSQL had a feature that was more like structured key-value database object metadata that could be edited.

It's a great feature, but GitHub's parser chokes on it. Compare: https://github.com/jchester/spc-kit/blob/eb2de71d815b0057e20... To: https://github.com/jchester/spc-kit/blob/main/sql/02-spc-int... Basically the original rendering makes me look incompetent to a casual skimmer. Plus tools like JetBrains IDEs can suss out what comments belong to what DDL anyway.

Since the project consists of multiple SQL files already, a workaround might be to split out all the “comment on” statements from each file into new files following them.

So in file 02-… you have your “create schema”, “create view” and so on. And then in file 03-… you have only the “comment on” statements that go with the things from file 02. And then file 04-… contains “create schema” and “create view” and so on, and file 05-… has the “comment on” statements for file 04-….

And in addition you could then add dash dash comments in 02 and 04 referring to files 03 and 05. And in file 03 and 05 at the top mention that these are valid SQL for PostgreSQL and that GitHub has trouble rendering them properly.

It’s a bit messy of course, but that’s why I say it’s a possible workaround rather than a great solution. Could be worth considering and trying, anyway.

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

#118

Post by Ayesh »

oftenwrong wrote: post #11

Another little-known feature is git trailers: https://alchemists.io/articles/git_trailers These are key-value structures data that can be included on a commit when it is created. These are used by some systems for attaching metadata. For example, Gerrit uses this for attaching its Change-Id.

TIL the `--trailer` CLI option. I used to edit the commit message in a text editor and manually add the trailers (which works for GitHub `Co-Authored-By`).

being able to use them with `git log` format is pretty cool.

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

#119

Post by pyuser583 »

Ayesh wrote: post #118
oftenwrong wrote: post #11

Another little-known feature is git trailers: https://alchemists.io/articles/git_trailers These are key-value structures data that can be included on a commit when it is created. These are used by some systems for attaching metadata. For example, Gerrit uses this for attaching its Change-Id.

TIL the `--trailer` CLI option. I used to edit the commit message in a text editor and manually add the trailers (which works for GitHub `Co-Authored-By`). being able to use them with `git log` format is pretty cool.

I’ve wanted to use them to keep track of whether a change was done by AI.

Lack of support was a big problem.

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

#120

Post by Ayesh »

smallpipe wrote: post #56
b0a04gl wrote: post #48

Earlier quoted context omitted.

haha wait do you actually read long commit messages( more than a line) all the way through? like line-by-line, imo commit msg = tweet, git note = blog post.

In my line of work a bug could cost multiple millions. I do read them. I write long ones. I would love if my colleagues started writing longer ones too.

Me too.

Most of the times, the commit message is 10+ lines while the change itself is -1/+1.

We use GitHub for repo hosting and a separate issue tracker to coordinate changes. It bothers me a lot that GitHub UI doesn't render markdown for commit messages. We all write really detailed and nicely formatted commit messages, and had to work out a commit message sync so the issue tracker can display related commit messages in full Markdown glory.

Post reply on HN