This is so strange, for some reason I thought rebase preserved them. `git replay` does, which is probably why GitHub works, so it can do these in memory. I believe libgit2 does as well, so maybe they're still using that. @gitlab.com and @gitea.com don't, so they're prob shelling out to `git rebase`

He’s right, your rebase also strips extra headers. Do you know where the whitelist of headers is hard coded?

We actually have a third structure, which is virtual branches - you can work on multiple branches (or stacks of branches) at the same time in one working directory. In case multiple stacks or branches have no interdependencies.

I like the two levels.

Per-commit review within a branch means they are all merged together. Stacking branches means the bottom should be merged first, but stacks above it depend on those but don’t need to be merged at the same time.

Its a useful mental difference when working on them.

Really? That seems like an unlikely reason. The signature just verifies the commit data minus the signature, it shouldn't matter what is in there for a verification. Can you point me at a use case?

In fact, if this were true, Gitea would break with any new future official git headers.

Merci

Currently no, but it's on our short list.

Not the entire history, just the commits you are trying to review.

my god, the russian bear octocat. probably my favorite one.

I think they come up a few days later or something.

Dont worry, my next post is about bundle-uri, which I think is more Derrick.

In fact, I thought I _just_ saw in the GerritForge summit video that branch based review was _maybe_ on the horizon

I’m curious. You say “series” but my last run in with Gerrit was that it was very single commit based. Even looking at the docs now, it still appears single patch based. Can you do a series of commits as a change basis now?

This is how shit gets done.