Seems easy enough, I read the article multiple times and I don't get why what they are describing is needed.
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.
To me that sounds like not a great idea, but if you must do it, I could see some usefulness to this.
I agree that it's not ideal, but... there are always tradeoffs to manage.
[0]: https://github.com/stackabletech/docker-images/tree/e30798ac...
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.
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.
> 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.
Same happens with patches that Debian applies on top of fixed versions of packages. They are stored in Debian's Salsa git.
cyberax•3h ago
I'm going to try to make a frontend UI for it.