3 ms·

Ha yes that does sound mad. If only there was a version control system specifically designed to track changes to code...

by IshKebab 11mo ago

blibble 11mo ago
it's quite difficult to maintain a quilt like workflow with plain git I've tried it
- cryptonector 11mo ago
  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 11mo 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 11mo ago
      I think that's right, sadly.
  - mxey 11mo ago
    How do you track changes to the patches themselves?
    - IshKebab 11mo ago
      You can keep the old branches around if you want. Or merge instead of rebasing.
    - cryptonector 11mo 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 11mo 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 11mo 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 11mo 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.
db48x 11mo ago
Quilt predates Git. Back then source was distributed as a tarball, and Debian simply maintained a directory full of patches to apply to the tarball.
- IshKebab 11mo ago
  Sure but Git has been available (and super popular) for almost 20 years now.
  - tremon 11mo ago
    So has git-buildpackage; the debian historical archives don't go further back than v0.4, but the oldest bug report referencing gbp is from december 2006: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=403987 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=403987
  - db48x 11mo ago
    Yea, so? Debian goes back 32 or more years, and quilt dates to approximately the same time. It’s probably just a year or two younger than Debian. At Mozilla some developers used quilt for local development back when the Mozilla Suite source code was kept in a CVS repository. CVS had terrible support for branches. Creating a branch required writing to each individual ,v file on the server (and there was one for every file that had existed in the repository, plus more for the ones that had been deleted). It was so slow that it basically prevented anyone from committing anything for hours while it happened (because otherwise the branch wouldn’t necessarily get a consistent set of versions across the commit), so feature branches were effectively impossible. Instead, some developers used quilt to make stacks of patches that they shared amongst their group when they were working on larger features. Personally I didn’t really see the benefit back then. I was only just starting my career, fresh out of university, and hadn’t actually worked on any features large enough to require months of work, multiple rounds of review, or even multiple smaller commits that you would rebase and apply fixups to. All I could see back then were the hoops that those guys were jumping through. The hoops were real, but so were the benefits.
    - 11mo ago

Ha yes that does sound mad. If only there was a version control system specifically designed to track changes to code...

blibble 11mo ago

it's quite difficult to maintain a quilt like workflow with plain git I've tried it

cryptonector 11mo ago
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 11mo 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 11mo ago
    I think that's right, sadly.
- mxey 11mo ago
  How do you track changes to the patches themselves?
  - IshKebab 11mo ago
    You can keep the old branches around if you want. Or merge instead of rebasing.
  - cryptonector 11mo 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 11mo 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 11mo 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 11mo 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.

db48x 11mo ago

Quilt predates Git. Back then source was distributed as a tarball, and Debian simply maintained a directory full of patches to apply to the tarball.

IshKebab 11mo ago
Sure but Git has been available (and super popular) for almost 20 years now.
- tremon 11mo ago
  So has git-buildpackage; the debian historical archives don't go further back than v0.4, but the oldest bug report referencing gbp is from december 2006: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=403987 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=403987
- db48x 11mo ago
  Yea, so? Debian goes back 32 or more years, and quilt dates to approximately the same time. It’s probably just a year or two younger than Debian. At Mozilla some developers used quilt for local development back when the Mozilla Suite source code was kept in a CVS repository. CVS had terrible support for branches. Creating a branch required writing to each individual ,v file on the server (and there was one for every file that had existed in the repository, plus more for the ones that had been deleted). It was so slow that it basically prevented anyone from committing anything for hours while it happened (because otherwise the branch wouldn’t necessarily get a consistent set of versions across the commit), so feature branches were effectively impossible. Instead, some developers used quilt to make stacks of patches that they shared amongst their group when they were working on larger features. Personally I didn’t really see the benefit back then. I was only just starting my career, fresh out of university, and hadn’t actually worked on any features large enough to require months of work, multiple rounds of review, or even multiple smaller commits that you would rebase and apply fixups to. All I could see back then were the hoops that those guys were jumping through. The hoops were real, but so were the benefits.
  - 11mo ago