[Snild]

Rebasing would mean there's no continuous versioning of the "patches on top", which might be undesirable. Also, the history rewriting might make cooperation difficult.

Merges would avoid those problems, but are harder to do if there are lots of conflicts, as you can't fix conflicts patch by patch.

Perhaps a workflow based on merges-of-rebases or rebase-and-overwrite-merge would work, but I don't think it's fair to say "oh just rebase".

[cryptonector]

> Rebasing would mean there's no continuous versioning of the "patches on top", which might be undesirable. Also, the history rewriting might make cooperation difficult.

Let's say you have these version tags upstream: foo-1.0.1, foo-1.1.0, foo-1.3.0, and corresponding Debian releases 1.0.1-0, 1.1.0-0, 1.1.0-1, 1.3.0-0, 1.3.0-1, and 1.3.0-2, and the same 3 patches in all cases, except slightly different in each case. Then to see the several different versions of these patches you'd just `git log --oneline foo-${version}..debian-${version}-${deb_version}`.

[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?