On Oct 7, 2014 5:25 AM, "William Slacum" <wilhelm.von.cl...@accumulo.net> wrote: > > #1 would be nice. I would discourage the cherry-pick-back-from-master model > because it completely disregards git's history model and makes auditing > changes nearly impossible because for N patches, the same change exists N > times under different IDs. If we wanted that, we'd be back to subversion > without mergeinfo. >
That only happens for patches that apply to all branches, which hopefully soon means just bug fixes. We already effectively have patch-per-branch because our main dev lines have substantial differences. As it is now, those differences end up in merge commits where they're harder to deal with. > #2 and #3 is possible now with our branching strategy. Is there some > deficiency you notice with it? > The main issue with #2 is the one Christopher brought up. Since we have to merge through each major version to get to master, there's no expectation that a release manager for e.g. 1.7 could opt out. For #3, I have to look at the results of a merge commit to know if the issue in an earlier release was also applicable to the newer branch or not. > While we're a big project, I think we might be able to benefit from a > review-then-commit process. It could allow us to review any patch to > master, and if we determine it is relevant in historical branches, we > commit it to the historical branch and then merge forward before publishing > to our public history. > > It's no secret that I would be thrilled if we switched to RtC. How would we deal with fixes that are substantively different on older branches?
