On 24 Feb 2014, at 11:30 PM, Thiago Macieira wrote: > Em seg 24 fev 2014, às 21:23:44, Oswald Buddenhagen escreveu: >> you can do the same with more branches. the one downside is that you >> need to keep a merge on top if you want to use both the changes based on >> an older and a newer branch at the same time. >> >>> Now, I can easily change branches, but it's a task I currently don't have. >>> My point is that there probably are other people out there who benefit >>> from having this branch too. >> >> most people developing for dev actually do it *on* dev. > > People should develop based on stable, if they don't need to features from > dev. That will keep them from going bald due to hair-tearing for a little > while longer. > > Why bother with the instability introduced by other people when working in > your corner?
Because if their changes impact mine, I'd rather know sooner than later. In general I like to keep up with what's going on in certain modules, even if it doesn't impact my changes. And ever since 5.0 was released, the instability hasn't been nearly as bad as it was before that. If it was stopping me from getting work done, I'd reconsider; but otherwise I'd feel uneasy to develop on stable and then push to dev. Likely you will get merge conflicts sometimes, so that the patch can't be applied to dev anyway. Maybe the reviewers will find it if they try to test the patch; otherwise you won't find it until you try to integrate, and then it will need another round of manual conflict resolution on the correct branch this time, and another review, right? > Regardless of how many patches you have, if it's more than 1, you should > either use git-gp or you should do the workflow that it does. I haven't tried it; does it do more than push to gerrit and add reviewers? > Don't rebase your patches if you don't need to rebase. Some people don't like the discontinuity between diffs in gerrit when a patch is rebased repeatedly, but again I prefer to make sure that the latest of my stuff works with the latest of everyone else's. It's more work to check out the old predecessor, cherry-pick the new version of the existing patch on top of that, and push, just to keep those people happy; and it's artificial because it doesn't make sense to develop it or test it that way, and it won't end up in the release that way. (For the reviewers, re-reading the latest patch in its entirety and making sure the whole thing still makes sense in present-day context wouldn't hurt anyway, if there is some confusion and the patch is small enough. It's only the larger ones where you need to compare revisions of one patch.) When testing, whether my patch or someone else's, I always rebase. So from my perspective the only issue is about the view from gerrit; therefore it would be nice if gerrit had a solution for it. Or does git-gpush take care of that too? Maybe it could keep a mapping of which patch is supposed to go on top of which predecessor somewhere, and do that temporary rebasing on top of a temporary branch each time before pushing. Or gerrit could do that internally, only when you are viewing diffs between diffs. I have a clunky workflow in cases when I have been working with a stack of patches, but they don't necessarily depend on each other: to push a subset of them, I make an "isolation" branch, then git rebase -i and remove all unrelated patches, push that, then go back to whatever branch I was on. But probably there's a better way? _______________________________________________ Releasing mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/releasing
