[Nullabillity]

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

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]

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

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

[cobbzilla]

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]

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

[rlpb]

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

[account42]

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

[Nullabillity]

v4_updated_updated_proper_real.doc

[account42]

More like vUPSTREAMVERSION-YOURVERSION.

Not that hard to keep it organized.