5 ms·

Maintaining separate upstream sources and downstream patches does provide value. Maybe not to you, but it does. For example, it's trivial from a web browser wi

by blucaz 9mo ago

Maintaining separate upstream sources and downstream patches does provide value. Maybe not to you, but it does. For example, it's trivial from a web browser with a couple of clicks to go and find out all the downstream changes to a package. For example to see how glibc is currently customized in debian testing/unstable you can just navigate this webpage: https://sources.debian.org/src/glibc/2.42-6/debian/patches https://sources.debian.org/src/glibc/2.42-6/debian/patches If everything gets merged in the same git tree it's way harder. Harder but doable with a rebase+force push workflow, which makes collaboration way harder. Just impossible with a merge workflow. As an upstream maintainer of several project, being able to tell at a glance and with a few clicks how one of my projects is patched in a distribution is immensely useful when bug reports are opened. In a past job it also literally saved a ton of money because we could show legal how various upstreams were customized by providing the content of a few .debian.tar.gz tarballs with a few small, detached patches that could be analyzed, instead of massive upstream trees that would take orders of magnitude more time to go through.

cryptonector 9mo ago
> For example, it's trivial from a web browser with a couple of clicks to go and find out all the downstream changes to a package. How is this not also true for Git? Just put all the Debian commits "on top" and use an appropriate naming convention for your branches and tags. > If everything gets merged in the same git tree it's way harder. Yes, so don't merge, just rebase. > Harder but doable with a rebase+force push workflow, which makes collaboration way harder. No force pushes, just use new branch/tag names for new releases. > Just impossible with a merge workflow. Not impossible but dumb. Don't use merge workflows! > As an upstream maintainer of several project, being able to tell at a glance and with a few clicks how one of my projects is patched in a distribution is immensely useful when bug reports are opened. Git with a suitable web front-end gives you exactly that. > In a past job it also literally saved a ton of money because we could show legal how various upstreams were customized by providing the content of a few .debian.tar.gz tarballs with a few small, detached patches that could be analyzed, instead of massive upstream trees that would take orders of magnitude more time to go through. `git format-patch` and related can do the moral equivalent.

by blucaz 9mo ago

cryptonector 9mo ago

> For example, it's trivial from a web browser with a couple of clicks to go and find out all the downstream changes to a package. How is this not also true for Git? Just put all the Debian commits "on top" and use an appropriate naming convention for your branches and tags. > If everything gets merged in the same git tree it's way harder. Yes, so don't merge, just rebase. > Harder but doable with a rebase+force push workflow, which makes collaboration way harder. No force pushes, just use new branch/tag names for new releases. > Just impossible with a merge workflow. Not impossible but dumb. Don't use merge workflows! > As an upstream maintainer of several project, being able to tell at a glance and with a few clicks how one of my projects is patched in a distribution is immensely useful when bug reports are opened. Git with a suitable web front-end gives you exactly that. > In a past job it also literally saved a ton of money because we could show legal how various upstreams were customized by providing the content of a few .debian.tar.gz tarballs with a few small, detached patches that could be analyzed, instead of massive upstream trees that would take orders of magnitude more time to go through. `git format-patch` and related can do the moral equivalent.