Am Fri, 04 Jan 2013 00:40:03 +0100 schrieb "foobar" <f...@bar.com>: > > Let's clarify a bunch of things here: > 1. There is no overhead with maintaining many feature brunches. I didn't mean the overhead of the branches itself. I meant the overhead of merging those first into master. Then later determining if master is stable (how?) and then merging into staging. The wiki says this is useful to allow fixing integration bugs. I think with mostly bugfixes there won't be many integration bugs. And merging into staging always requires someone to do it, which is imho overhead (regarding "human resources", not technical).
> 2. Feature branches can be safely removed after their contents > have been merged. This is useful for avoiding clutter. sure > 3. There is no need to re-review the _same_ code on each branch > it is merged to. That's just plain stupid. Well, the wiki says things are merged into staging if they are considered sufficiently stable. Who determines what is stable and how? > 4. Chery picking is a HORRIBLE idea for managing releases and > should only be used on development. Chery-picking COPIES commits > and thus loses the connections in the history graph. Sure, this is why I said mixing cherry picking and merging is not a good idea. As long as you only cherry pick into a branch and never merge into that branch or merge it back there is no issue. I missed the detail that you suppose basing bugfix branches on the oldest applicable release branch. That should be made very clear in the wiki. I just think that this process is counter-productive for dmd as most changes are bugfixes and regressions are caused by bug fixes as well. Applying _every_ bugfix in older releases has a high risk of reintroducing regressions (and / or breaking user code. If the compiler didn't enforce const in some situations, fixing it is a bug fix. But fixing it will break user code - so you have a 2.061 that works for users and a 2.061.1 which breaks code). It makes more sense to me to only fix regressions that were introduced with the base release. So 2.061.1 would only fix regressions introduced in 2.061. (This can still be done by basing that fix on the latest applicable version and merging back into master / staging). Also the lowest applicable version for most dmd bugs is probably 2.01. So if we start this process now, we'll still be fixing bugs in 2.061 in 10 years, then merging into 2.062, 2.063.... Here "lowest _supported_ applicable version" makes more sense imho, where supported needs to be defined (e.g. 2 releases). This is not a big problem if we only talk about regressions, but I'd still prefer "lowest _supported_ applicable version" > 5. There is no problem developing bug_fixes on separate topic > branches. As we already do. > 6. There is no problem merging back to master. As long as there are no cherry picked commits into that branch. AFAIK we have already cherry picked commits from master into staging. Then merging staging back into master is not good - It will probably work but as you said cherry picking duplicates commits and we'll therefore merge identical changes with different ids. We should probably delete staging and start again as soon as the workflow is clear to everyone. > 7. Let me say this again. Merges are cheap and easy in git. So > are re-merges. Avoiding merges is an artifact of client-server > designs such as SVN and is NOT compatible with Git's conceptual > model. > > I suggest to read about how git works and how best to utilize its > features, and NOT apply common wisdom from CVS/SVN/RCS which are > based on a _completely different_ conceptual model. I don't have common wisdom from cvs/svn ;-) Merges are not that easy if you want to merge only a single commit or skip certain commits. Although you can tell merge to skip commits it's in no way easy. http://stackoverflow.com/a/729723/471401 It's probably best to not get into this situation. The workflow described on the wiki can indeed work well without cherry picking. But what was done till 2.061 was basing bug fixes on the master branch. If you want to get these into a release branch without features, etc cherry-picking is way easier than merging.