Hi guys, don't want to stop your discussion, but personally I see that mainly as a documentation issue. Surely having some convention about branch names (and sticking to it) would help, but even better would be to put the details about the branches on something that shows up very high in google "qt git branches" :) Right now there's
http://qt-project.org/wiki/Branches which is qt creator only. We should have the same for qt.git, or list both on the page. Regards Kai PS: Yet another example: http://gcc.gnu.org/svn.html, where all the gcc branches are described. ________________________________________ From: development-bounces+kai.koehne=digia....@qt-project.org [development-bounces+kai.koehne=digia....@qt-project.org] on behalf of Oswald Buddenhagen [oswald.buddenha...@digia.com] Sent: 23 April 2013 19:11 To: development@qt-project.org Subject: Re: [Development] Please warn of force pushes... On Tue, Apr 23, 2013 at 09:46:03AM -0700, Thiago Macieira wrote: > On terça-feira, 23 de abril de 2013 18.20.11, Oswald Buddenhagen wrote: > > > 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 > > Would you call me experienced with Git? > > Well, I have never successfully used git rebase --onto without reading the man > page first and paying attention to the ASCII Art graphs. > that's unfortunate. :P > Besides, that's unwieldy. I don't carry a handful of commits in my branches. I > carry somewhere from 60 to 120. So, no, moving target == off-limits for me. > this is an entirely constructed example. you are not going to have 100 changes on top of a wip branch which is too quickly moving to adhere to the mainline submission policies. and, ehm, you are the only person within qt-project who has 100 pending changes in a single branch. seriously. > > > 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. > > Yes, it is. Why do they need to use the mainline repositories if they are not > going to adhere to the policies that are in place? > > No, really, why do those branches need to be in the main repositories? > > I'll give one answer, out of past discussion, and just to prove that yes I am > trying to understand both sides: > > it is nice to be there because other people sometimes see the commits coming > in and will comment on them. > > > With that in mind, I change my proposal and I will say that rebasing branches > are acceptable in the mainline repositories, provided they are clearly marked. > It's minimal impact and it solves the problem of surprise by selecting the > people who may use that branch. > as far as i can see, the admin who created the winrt branch (not me) failed to comply with the wip/ policy. i'm sure adding more naming policies will improve that situation ... not. > > and if you did, you'd need to ban playground repos as well (where > > typically non-approvers can approve changes). > > By definition, a playground repository is not a mainline repository. > but it lives on our gerrit, so it's "official". i don't see a difference between a non-mainline branch of an "accepted" repository and the branches of a playground repository. there is no such thing as a mainline _repository_ - on the server, we don't clone: we branch. _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
