(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.

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.

> 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.

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.

Just tag your old HEAD each time you rebase it (or before that)?