4 ms·

Quilt is difficult to maintain, but a quilt-like workflow? Easy: it's just a branch with all patches as commits. You can re-apply those to new releases of the

Quilt is difficult to maintain, but a quilt-like workflow? Easy: it's just a branch with all patches as commits. You can re-apply those to new releases of the upstream by using `git rebase --onto $new_upstream_commit_tag_or_branch`.

coryrc 10mo ago
Those who don't understand git are doomed to reimplement half of it poorly? (I know that's not quite the Greenspun quote)
- cryptonector 10mo ago
  I think that's right, sadly.
mxey 10mo ago
How do you track changes to the patches themselves?
- IshKebab 10mo ago
  You can keep the old branches around if you want. Or merge instead of rebasing.
- cryptonector 10mo ago
  By having a naming convention for your tags and branches, then you can always identify the upstream "base" upon which the Debian "patches" are based, and then you can trivially use `git log` to list them. Really, Git has a solution to this. If you insist that it doesn't without looking, you'll just keep re-inventing the wheel badly.
  - blibble 10mo ago
    but then if I want to see the history for a specific patch, or bisect them? mercurial has a patch queue extension that married it and quilt, which was very easy to use
    - cryptonector 10mo ago
      Do you ever really want this? I don't recall wanting this. But you can still get this: just list the ${base_ref}..${deb_ref} commit ranges, select the commit you want, and diff the `git show` of the selected commits. It helps here to keep the commit synopsis the same. E.g., c0=$(git log --oneline ${base_ref0}..${deb_ref0} | grep "^[^ ] The subject in question" | cut -d' ' -f1) c1=$(git log --oneline ${base_ref1}..${deb_ref1} | grep "^[^ ] The subject in question" | cut -d' ' -f1) if [[ -z $c0 || -z $c1 ]]; then echo "Error: commits not found" else diff -ubw <(git show $c0) <(git show c1) fi See also the above commentary about Gerrit and commit IDs. (Honestly I don't need commit IDs. What happens if I eventually split a commit in a patch series into two? Which one, if either, gets the old commit ID? So I just don't bother.)
      - mxey 10mo ago
        So there’s no way to have commit messages on changes to patches? There’s also https://dep-team.pages.debian.net/deps/dep3/ https://dep-team.pages.debian.net/deps/dep3/ People keep saying “just use Git commits” without understanding the advantages of the Quilt approach. There are tools to keep patches as Git commits that solve this, but “just Git commits” do not.
        cryptonector 10mo ago
        Having maintained private versions of Debian packages, I have zero need for "commit messages on changes to patches". I can diff them as needed as I showed, but I rarely ever need to -- I mostly only rebase onto new upstreams. Seeing differences in patches isn't helpful because there is not enough context there as to what changed in the upstreams. I rather suspect that "commit messages on changes to patches" is what Debian ended up with and back-justifies it. Of course, I am not a Debian maintainer, so it's entirely possible I'm just missing the experience of it that would make me want "commit messages on changes to patches".
        mxey 10mo ago

coryrc 10mo ago

Those who don't understand git are doomed to reimplement half of it poorly? (I know that's not quite the Greenspun quote)

cryptonector 10mo ago
I think that's right, sadly.

mxey 10mo ago

How do you track changes to the patches themselves?

IshKebab 10mo ago
You can keep the old branches around if you want. Or merge instead of rebasing.
cryptonector 10mo ago
By having a naming convention for your tags and branches, then you can always identify the upstream "base" upon which the Debian "patches" are based, and then you can trivially use `git log` to list them. Really, Git has a solution to this. If you insist that it doesn't without looking, you'll just keep re-inventing the wheel badly.
- blibble 10mo ago
  but then if I want to see the history for a specific patch, or bisect them? mercurial has a patch queue extension that married it and quilt, which was very easy to use
  - cryptonector 10mo ago
    Do you ever really want this? I don't recall wanting this. But you can still get this: just list the ${base_ref}..${deb_ref} commit ranges, select the commit you want, and diff the `git show` of the selected commits. It helps here to keep the commit synopsis the same. E.g., c0=$(git log --oneline ${base_ref0}..${deb_ref0} | grep "^[^ ] The subject in question" | cut -d' ' -f1) c1=$(git log --oneline ${base_ref1}..${deb_ref1} | grep "^[^ ] The subject in question" | cut -d' ' -f1) if [[ -z $c0 || -z $c1 ]]; then echo "Error: commits not found" else diff -ubw <(git show $c0) <(git show c1) fi See also the above commentary about Gerrit and commit IDs. (Honestly I don't need commit IDs. What happens if I eventually split a commit in a patch series into two? Which one, if either, gets the old commit ID? So I just don't bother.)
    - mxey 10mo ago
      So there’s no way to have commit messages on changes to patches? There’s also https://dep-team.pages.debian.net/deps/dep3/ https://dep-team.pages.debian.net/deps/dep3/ People keep saying “just use Git commits” without understanding the advantages of the Quilt approach. There are tools to keep patches as Git commits that solve this, but “just Git commits” do not.
      - cryptonector 10mo ago
        Having maintained private versions of Debian packages, I have zero need for "commit messages on changes to patches". I can diff them as needed as I showed, but I rarely ever need to -- I mostly only rebase onto new upstreams. Seeing differences in patches isn't helpful because there is not enough context there as to what changed in the upstreams. I rather suspect that "commit messages on changes to patches" is what Debian ended up with and back-justifies it. Of course, I am not a Debian maintainer, so it's entirely possible I'm just missing the experience of it that would make me want "commit messages on changes to patches".
        mxey 10mo ago