> Let me ask a different question: What is wrong with cherry-picking
> downstream changes to your upstream branch? Without rebasing it to
> downstream.
Naah, dont rebase the upstream ontop of downstream - this doenst make
any sense (yeah, my devs sometimes doing exatly this wong ;-o).
Instead, as you just said, cherry-pick the good commits into your
upstream branch and rebase your downstreams ontop of that. (doesnt
make any difference if this is done by different people or in different
administrative domains).
> That might mean there is a rather useless merge downstream later on,
> but that's the price you pay for not doing the change in a development
> branch.
That's one of the things rebase is for: not having your history filled
up with merges at all, but always have your local cutomizations added
ontop of the current upstream.
By the way: I'm also using this hierachy for package maintenance to
different target distros:
upstream branch
|
|----> upstream release tag X.Y.Z
|
\ /
bugfix branch (maint-X-Y-Z) => general (eg. distro-agnostig) fixes go here
|
|-----> maintenance release tag X.Y.Z.A
|
\ /
dist branch (mydist-X-Y-Z) => distro-specific customizations (eg.
| packaging control files, etc) go here
|------> dist package release tags X.Y.Z.A-B
Usually I do quick hotfixes in the dist branch (and assigning new dist version number),
then copy the dist branch into some topic-branch, rebase into latest bugfix branch,
cherry-pick the interesting commit(s) into the bugfix branch. When I do a new bugfix
release (from by bugfix branch), I rebase the dist branch ontop the latest bugfix
release tag, fix dist-package version numbers and run the dist-specific build and
testing pipeline.
Here's some example for it: https://github.com/vnc-biz/redmine-core
cu
--
Mit freundlichen Grüßen / Kind regards
Enrico Weigelt
VNC - Virtual Network Consult GmbH
Head Of Development
Pariser Platz 4a, D-10117 Berlin
Tel.: +49 (30) 3464615-20
Fax: +49 (30) 3464615-59
enrico.weigelt@xxxxxxx; www.vnc.de
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html