| ▲ | skydhash 4 days ago |
| Maybe I can't understand what TFA is describing, but from what I know a patch is usually tied to a specific commit, so a very specific point of time in the upstream lifetime. It does not make sense to have it lingering longer than that. Even in the case when you want to maintain a set of patches (package building,...) you usually revise it every new version of the software. In this case, the intent is much more important than the how (which quickly become history). |
|
| ▲ | lmm 4 days ago | parent | next [-] |
| The point is to maintain your set (perhaps stack) of patches as a set of patches on top of upstream for the long term. Yes, you will probably have to revise them as upstream changes, but this will let you maintain their identity as you do so. Is that something you will find useful? Maybe, maybe not. |
|
| ▲ | random3 4 days ago | parent | prev | next [-] |
| You’re thinking a patch is text, but should think of it as a logical change. Unless the logic becomes part of upstream the patch is not tied to a specific point in “time”. There’s a cost to it, as you have to constantly rebase. This is the case with any non-vanilla distribution (e.g. Linux), although it’s also at a package level so you do this both for each package as well across every package. For well written code there’s reasonably low coupling so it’s less work to maintain. |
|
| ▲ | doix 4 days ago | parent | prev | next [-] |
| Yes, I don't quite get it. When I need to maintain a fork, I just add an extra remote to git. Then I fetch upstream (what I call my remote) and rebase my changes against whatever branch I'm following. At any point in time I can generate a patch file that works for whatever version I have rebased against. Seems easy enough, I read the article multiple times and I don't get why what they are describing is needed. |
| |
| ▲ | Nullabillity 4 days ago | parent [-] | | (Author here.) The difference is that git rebasing is a destructive operation, you lose track of the old version when you do it. (Yes, there's technically the reflog.. but it's much less friendly to browse, and there's no way to share it across a team.) Maybe that's an okay tradeoff for something you use by yourself, but it gets completely untenable when you're multiple people maintaining it together, because constantly rebasing branches completely breaks Git's collaboration model. | | |
| ▲ | doix 4 days ago | parent | next [-] | | I worked at a place that was allergic to contributing patches upstream. We maintained a lot of internal forks for things and had no problem collaborating. You don't need to push the rebased branch to the same branch on your remote, if that's an issue (although I don't see how it is). Maybe this is a case of "Dropbox is just rsync", but I feel like just learning git and using it is easier than learning a new tool. | | |
| ▲ | NotPractical 3 days ago | parent | next [-] | | > I feel like just learning git and using it is easier than learning a new tool I would agree if this "new tool" we're talking about wasn't just a simple wrapper over existing git commands. You can learn it in its entirety, including how it works (not just how to use it), in a matter of a half hour or less. | |
| ▲ | nicoburns 4 days ago | parent | prev [-] | | We do this for some of the components that are shared between Servo and Firefox. Firefox is upstream, and on the Servo side we have automated and manual syncing. The automated syncing mirrors the upstream `main` branch to our `upstream` without changes daily. The manual syncing rebases our changes on top a new upstream version through a manual rebase process. This happens monthly and each sync is pushed to a new branch to maintain history. Between monthly syncs we push our own changes to our latest monthly branch (which also get manually sent upstream when we get a chance). |
| |
| ▲ | rlpb 2 days ago | parent | prev | next [-] | | > The difference is that git rebasing is a destructive operation, you lose track of the old version when you do it. (Yes, there's technically the reflog.. but it's much less friendly to browse, and there's no way to share it across a team.) Just tag v1, v2, etc. Then push tags as normal for collaboration. git range-diff is excellent to inspect the changes if you want to see how a patchset changed. | |
| ▲ | cobbzilla 4 days ago | parent | prev | next [-] | | I see — you’re doing more than “here’s a few patches to keep working across revisions”, you’re doing separate-path feature work on a different, actively-developed project. To me that sounds like not a great idea, but if you must do it, I could see some usefulness to this. | | |
| ▲ | Nullabillity 4 days ago | parent [-] | | Yeah. For reference, this is a typical patchset for the project that motivated it.[0] Some of the patches are "routine" dependency upgrades, some of them are bugfix backports, some of them are original work that we were planning to upstream but hadn't got around to yet. Some are worth keeping when upgrading to a new upstream version, some aren't. I agree that it's not ideal, but... there are always tradeoffs to manage. [0]: https://github.com/stackabletech/docker-images/tree/e30798ac... |
| |
| ▲ | account42 3 days ago | parent | prev [-] | | Just tag your old HEAD each time you rebase it (or before that)? | | |
|
|
|
| ▲ | shmerl 4 days ago | parent | prev | next [-] |
| For example wine-staging (ran by Wine developers themselves) hosts patches for Wine project and they revise / rebase them with each Wine version, which is often not a trivial task. I don't see how you can avoid that really. But Wine staging itself is a git repository that holds patches (and their history) if that helps, which indeed can stay there for years. Same happens with patches that Debian applies on top of fixed versions of packages. They are stored in Debian's Salsa git. |
|
| ▲ | cobbzilla 4 days ago | parent | prev | next [-] |
| Agreed. If you want your change and don’t want to bother the maintainers with a patch they are unlikely to accept, or can’t because it’s proprietary: fork the repo (at whatever tag makes sense), then periodically sync with the latest code for that version. The likelihood of conflicts is minimal, and often if you see conflicts it’s a good indication your issue may have been resolved. Or if not, you can see if it’s still needed, or how to adjust it. |
| |
| ▲ | Nullabillity 4 days ago | parent [-] | | (Author here.) > fork the repo (at whatever tag makes sense), then periodically sync with the latest code for that version. Yeah, this is the workflow that Lappverk is trying to enable. The problem is that neither of Git's collaboration models works well for this problem. Rebasing breaks collaboration (and history for the patchset itself), and merging quickly loses track of individual patches. Lappverk is an attempt to provide a safer way to collaborate over the rebase workflow. | | |
| ▲ | skydhash 4 days ago | parent [-] | | But you can always create a new branch before rebasing if you want to store the old revision metadata. or do a git format-patches if you don’t want a bunch of branches laying around. So what are the ways to be safer than this? |
|
|
|
| ▲ | what 4 days ago | parent | prev [-] |
| A patch just encapsulates what was added and removed in a particular change, it doesn’t care about any commits. |
