On Tue, Apr 23, 2013 at 08:16:24AM -0700, Thiago Macieira wrote: > On terça-feira, 23 de abril de 2013 11.18.33, Oswald Buddenhagen wrote: > > On Mon, Apr 22, 2013 at 10:19:05AM -0700, Thiago Macieira wrote: > > > These people need to be warned that the branch rebases. > > > > why would they? they can adapt once it happens. i mean, it's a bit of a > > surprise, but it doesn't change much in the end. > > Because the surprise is quite big. If you do a git pull --rebase or git pull, > it might blow up after dozens lines have scrolled out. People don't pay > attention to the output of the fetch part. > i don't see that as a problem. if it blows one can easily roll back with rebase --abort. in the worse case one needs to manually rebase out some leftovers.
> Though I have to grant that novice users are unlikely to be following those > branches in the first place. But then, we're left with somewhat knowledgeable > users following the branches, so they are more likely to have extra commits > and then have no clue on how to rebase their work on top of the rebased base. > > I, for one, will not touch any of the rebasing branches, not even to test > them. It's too much work to rebase on top of a moving base. > i call that making a mountain out of a molehill. $ git fetch $ git rebase --onto @{u} HEAD~4 > > > > > Ok, then add "rebasing" to the branch name somewhere. Preferably: > > > > > wip/rebasing/xxx > > > > > > > > sounds over-engineered to me. > > > > and unnecessarily restrictive, as the policy may change ad-hoc as things > > > > progress. > > > > > > Change the branch name when the policy changes. > > > > i really wouldn't want to do that. > > But you're not offering a better solution either. You're just dismissing the > problem completely: > indeed, my solution is dismissing this NON-problem. > > > In any case, why does this branch rebase? Can't they live with > > > merges? > > > > well, the wip/ branches often have rather lax review policies (often > > bypassing domain experts in the case of platform ports) and no CI. > > If they're bypassing the reviewers and bypassing the CI, why do they > need to be in the main Git repositories in Gerrit in the first place? > they are not bypassing review alltogether, they are just "taking shortcuts". > Especially if they're bypassing the CI, they could and should just use > a repository elsewhere. When the branch is ready, it will be submitted > as individual patches to be reviewed by the regular reviewers, maybe > starting the work branch. > it's unreasonable to ban everything that does not comply with the standard workflow for mainline branches. and if you did, you'd need to ban playground repos as well (where typically non-approvers can approve changes). _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development