[haiku-commits] AW: Re: haiku: hrev49807 - in src: servers/app servers/app/drawing/Painter servers/app/drawing/Painter/bitmap_painter servers/app/drawing tests/servers/app/unit_tests
- From: "Harnath, Julian Axel" <Julian.Harnath@xxxxxxxxxxxxxx>
- To: "haiku-commits@xxxxxxxxxxxxx" <haiku-commits@xxxxxxxxxxxxx>
- Date: Wed, 11 Nov 2015 10:44:43 +0000
Hey Axel,
app_server: PictureBoundingBoxPlayer fixups
* TODO: squash commit before merge into master
Looks like you forgot something here.
Yup... those were made some time ago and I didn't remember they were in there.
Merge branch 'app_server'
We prefer rebasing instead of merging for a cleaner history.
Even for long-living feature branches?
The problem is, when the (github-)branch lives long enough, you have to merg
haiku master into it every now and then so you won't get too many conflicts all
at once when finished (or maybe the branch work wants to use a feature that was
added in master in the meantime). Of course one could also rebase the branch
onto haiku master, but that'd require a forced push. If there's only one person
working on the branch, that's somewhat ok, but if there is ever more than one
developer working on it, that gets nasty. So rebasing the feature branch during
its development does not seem to be a good policy.
Now another option (the one you mean I think) would be to rebase the feature
branch once at the end, when it's finished and not used anymore. But then,
during rebase, all the conflicts reemerge which were already solved during the
incremental merges of master into the feature branch, during development.
To prevent having to deal with possible old conflicts, merging seemed to be the
best choice to me.... any ideas?
Best regards,
Julian
Other related posts:
