[coryrc]

Gerrit introduces the concept of Commit-Id; essentially a uuid ties to the first review which merged a proposed commit into the trunk.

Cherry picks preserve that Commit-Id. And so do rebases; because they're just text in a commit message.

So you can track history of patches that way, if you needed to. Which you won't.

(PS some team at google didn't understand git or their true requirements, so they wasted SWE-decades at that point on some rebasing bullshit; I was at least able to help them make it slightly less bad and prevent other teams from copying it)

[Snild]

But that Commit-Id footer has no functional effect. I don't see how it would help me if I have a clone of the repo, and my upstream (in this case, the debian maintainer) rebases.

> Which you won't.

Why not? Doesn't it make sense to be able to track the history of what patches have been applied for a debian package?

[coryrc]

You need additional tooling to make use of Commit-Id. With Gerrit, it does link them all together.

> Doesn't it make sense to be able to track the history of what patches have been applied for a debian package?

... no. Each patch has a purpose, which will be described in the commit message. Hopefully it does what it says it does, which you can compare with its current diff.

If it was upstreamed with minimal changes, then the diff is near-empty. Drop it.

If it was upstreamed with significant changes, then the diff will be highly redundant. Drop it.

If the diff appears to do what the commit message says it does, then it probably does what it says.

If the diff is empty, either it was upstreamed or you fucked up rebasing. Don't be negligent when rebasing.

[adastra22]

How is that not literally the git history?

[Snild]

It is, except after rebasing.